Red Hat System Administration I

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

[student@servera ~]$ su - production1
Password: redhat
[production1@servera ~]$ 

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

[production1@servera ~]$ ssh-copy-id production1@serverb
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/production1/.ssh/id_rsa.pub"
The authenticity of host 'serverb (172.25.250.11)' 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
production1@serverb's password: redhat
Number of key(s) added: 1

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

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

1. Use the su - command to switch to root on serverb.

   [production1@serverb ~]$ su -
   Password: redhat
   [root@serverb ~]# 

2. 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@serverb ~]# systemctl reload sshd.service

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

   Note

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

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

   The preceding ssh command returned after three failed attempts to log in to servera as root. By default, the ssh command prefers to use SSH keys for authentication but if it does not find the necessary keys of the user, it requests the user's password for authentication.

1. Return to the first terminal that has the root user's shell active on serverb. 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@serverb ~]# systemctl reload sshd

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

   [production1@servera ~]$ ssh production2@serverb
   production2@serverb: 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 establish whether the preceding command actually 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 serverb. 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 production1 user's shell active on servera and try logging in to serverb as production1. This should succeed because SSH keys are configured for production1 to log in to serverb from servera.

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

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

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

6. Close the second terminal on workstation.

   [student@workstation ~]$ exit

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

   [root@serverb ~]# exit
   logout

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

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

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

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