Red Hat System Administration I

From workstation, open an SSH session to serverb as student.

[student@workstation ~]$ ssh student@serverb
...output omitted...
[student@serverb ~]$ 

Use the su command to switch to operator2 on serverb. Use redhat as the password of operator2.

[student@serverb ~]$ su - operator2
Password: redhat
[operator2@serverb ~]$ 

Use the ssh-keygen command to generate SSH keys. Do not enter any passphrase for the keys.

[operator2@serverb ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/operator2/.ssh/id_rsa): Enter
Created directory '/home/operator2/.ssh'.
Enter passphrase (empty for no passphrase): Enter
Enter same passphrase again: Enter
Your identification has been saved in /home/operator2/.ssh/id_rsa.
Your public key has been saved in /home/operator2/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:JainiQdnRosC+xXhOqsJQQLzBNUldb+jJbyrCZQBERI operator1@serverb.lab.example.com
The key's randomart image is:
+---[RSA 2048]----+
|E+*+ooo .        |
|.= o.o o .       |
|o.. = . . o      |
|+. + * . o .     |
|+ = X . S +      |
| + @ +   = .     |
|. + =   o        |
|.o . . . .       |
|o     o..        |
+----[SHA256]-----+

Use the ssh-copy-id command to send the public key of the SSH key pair to operator2 on servera. Use redhat as the password of operator2 on servera.

[operator2@serverb ~]$ ssh-copy-id operator2@servera
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/operator1/.ssh/id_rsa.pub"
The authenticity of host 'servera (172.25.250.10)' can't be established.
ECDSA key fingerprint is SHA256:ERTdjooOIrIwVSZQnqD5or+JbXfidg0udb3DXBuHWzA.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
operator2@servera's password: redhat
Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'operator2@servera'"
and check to make sure that only the key(s) you wanted were added.

Confirm that you can successfully log in to servera as operator2 using the SSH keys.

1. Open an SSH session to servera as operator2.

   [operator2@serverb ~]$ ssh operator2@servera
   ...output omitted...
   [operator2@servera ~]$ 

   Notice that the preceding ssh command used SSH keys for authentication.

2. Log out of servera.

   [operator2@servera ~]$ exit
   logout
   Connection to servera closed.

Confirm that you can successfully log in to servera as root using redhat as the password.

1. Open an SSH session to servera as root using redhat as the password.

   [operator2@serverb ~]$ ssh root@servera
   root@servera's password: redhat
   ...output omitted...
   [root@servera ~]# 

   Notice that the preceding ssh command used the password of the superuser for authentication because SSH keys do not exist for the superuser.

2. Log out of servera.

   [root@servera ~]# exit
   logout
   Connection to servera closed.
   [operator2@serverb ~]$ 

Confirm that you can successfully log in to servera as operator3 using redhat as the password.

1. Open an SSH session to servera as operator3 using redhat as the password.

   [operator2@serverb ~]$ ssh operator3@servera
   operator3@servera's password: redhat
   ...output omitted...
   [operator3@servera ~]$ 

   Notice that the preceding ssh command used the password of operator3 for authentication because SSH keys do not exist for operator3.

2. Log out of servera.

   [operator3@servera ~]$ exit
   logout
   Connection to servera closed.
   [operator2@serverb ~]$ 

Configure sshd on servera to prevent users logging in as root. Use redhat as the password of the superuser when required.

1. Open an SSH session to servera as operator2 using the SSH keys.

   [operator2@serverb ~]$ ssh operator2@servera
   ...output omitted...
   [operator2@servera ~]$ 

2. On servera, switch to root. Use redhat as the password of the root user.

   [operator2@servera ~]$ su -
   Password: redhat
   [root@servera ~]# 

3. Set PermitRootLogin to no in /etc/ssh/sshd_config and reload sshd. You may use vim /etc/ssh/sshd_config to edit the configuration file of sshd.

   ...output omitted...
   PermitRootLogin no
   ...output omitted...
   [root@servera ~]# systemctl reload sshd

4. Open another terminal on workstation and open an SSH session to serverb as operator2. From serverb, try logging in to servera as root. This should fail because you disabled root user login over SSH in the preceding step.

   Note

   For your convenience, password-less login is already configured between workstation and serverb in the classroom environment.

   [student@workstation ~]$ ssh operator2@serverb
   ...output omitted...
   [operator2@serverb ~]$ ssh root@servera
   root@servera's password: redhat
   Permission denied, please try again.
   root@servera's password: redhat
   Permission denied, please try again.
   root@servera's password: redhat
   root@servera: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

   By default, the ssh command attempts to authenticate using key-based authentication first and then, if that fails, password-based authentication.

Configure sshd on servera to allow users to authenticate using SSH keys only, rather than their passwords.

1. Return to the first terminal that has the root user's shell active on servera. Set PasswordAuthentication to no in /etc/ssh/sshd_config and reload sshd. You may use vim /etc/ssh/sshd_config to edit the configuration file of sshd.

   ...output omitted...
   PasswordAuthentication no
   ...output omitted...
   [root@servera ~]# systemctl reload sshd

2. Go to the second terminal that has operator2 user's shell active on serverb and try logging in to servera as operator3. This should fail because SSH keys are not configured for operator3, and the sshd service on servera does not allow the use of passwords for authentication.

   [operator2@serverb ~]$ ssh operator3@servera
   operator3@servera: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

   Note

   For more granularity, you may use the explicit -o PubkeyAuthentication=no and -o PasswordAuthentication=yes options with the ssh command. This allows you to override the ssh command's defaults and confidently determine that the preceding command fails based on the settings you adjusted in /etc/ssh/sshd_config in the preceding step.

3. Return to the first terminal that has the root user's shell active on servera. Verify that PubkeyAuthentication is enabled in /etc/ssh/sshd_config. You may use vim /etc/ssh/sshd_config to view the configuration file of sshd.

   ...output omitted...
   #PubkeyAuthentication yes
   ...output omitted...

   Notice that the PubkeyAuthentication line is commented. Any commented line in this file uses the default value. Commented lines indicate the default values of a parameter. The public key authentication of SSH is active by default, as the commented line indicates.

4. Return to the second terminal that has operator2 user's shell active on serverb and try logging in to servera as operator2. This should succeed because the SSH keys are configured for operator2 to log in to servera from serverb.

   [operator2@serverb ~]$ ssh operator2@servera
   ...output omitted...
   [operator2@servera ~]$ 

5. From the second terminal, exit the operator2 user's shell on both servera and serverb.

   [operator2@servera ~]$ exit
   logout
   Connection to servera closed.
   [operator2@serverb ~]$ exit
   logout
   Connection to serverb closed.
   [student@workstation ~]$ 

6. Close the second terminal on workstation.

   [student@workstation ~]$ exit

7. From the first terminal, exit the root user's shell on servera.

   [root@servera ~]# exit
   logout

8. From the first terminal, exit the operator2 user's shell on both servera and serverb.

   [operator2@servera ~]$ exit
   logout
   Connection to servera closed.
   [operator2@serverb ~]$ exit
   logout
   [student@serverb ~]$ 

9. Log out of serverb and return to the student user's shell on workstation.

   [student@serverb ~]$ exit
   logout
   Connection to serverb closed.
   [student@workstation ~]$