Bookmark this page

Guided Exercise: Implementing Recommended Security Practices

Use recommended security practices to configure and operate remote access methods and cryptographic algorithms.

Outcomes

  • Apply the legacy cryptographic policy to enable communication with legacy hosts.

  • Configure a system to use SSH key-based authentication.

  • Disable SSH password-based authentication.

As the student user on the workstation machine, use the lab command to prepare your environment for this exercise, and to ensure that all required resources are available.

[student@workstation ~]$ lab start securityrisk-recommend

Instructions

In this exercise, the serverb host acts as a legacy host where the current cryptographic algorithms are disabled.

  1. Configure the servera host to use the legacy cryptographic policy to enable communication with the serverb host.

    1. From workstation, log in to servera as the student user with the student password.

      [student@workstation ~]$ ssh student@servera
      [student@servera ~]$
    2. Verify that serverb is inaccessible due to legacy cryptographic protocols by attempting to log in with the student user.

      [student@servera ~]$ ssh student@serverb
      Unable to negotiate with 172.25.250.11 port 22: no matching cipher found. Their offer: aes128-cbc
    3. Apply the legacy cryptographic policy to servera by using the update-crypto-policies command. Use the student password when prompted. You do not need to reboot the servera host or to restart services because when you run ssh to remotely access serverb, the command uses the new cryptographic policy. Although other services might still use the previous cryptographic policy, it does not affect this test.

      [student@servera ~]$ sudo update-crypto-policies --set legacy
      [sudo] password for student:
      Setting system policy to LEGACY
      Note: System-wide crypto policies are applied on application start-up.
      It is recommended to restart the system for the change of policies
      to fully take place.
    4. Verify that serverb is now accessible by logging in with the student user and the student password. If prompted, answer yes to connect. Log out of serverb after verifying accessibility.

      [student@servera ~]$ ssh student@serverb
      The authenticity of host 'serverb (172.25.250.11)' can't be established.
      ED25519 key fingerprint is SHA256:OvIwK0RqObSrxkFEqzB1rLw5IvvJCBWxJmmx85TtVKg.
      This key is not known by any other names
      Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
      Warning: Permanently added 'serverb' (ED25519) to the list of known hosts.
      student@serverb's password: student
      [student@serverb ~]$ logout
      Connection to serverb closed.
      [student@servera ~]$
  2. Configure the serverb host to allow SSH key-based authentication. Ensure that the student user on servera can log in to serverb by using SSH key-based authentication.

    1. On servera as the student user, create an SSH key pair with no passphrase.

      [student@servera ~]$ ssh-keygen
      Generating public/private rsa key pair.
      Enter file in which to save the key (/home/student/.ssh/id_rsa): Enter
      Created directory '/home/student/.ssh'.
      Enter passphrase (empty for no passphrase): Enter
      Enter same passphrase again: Enter
      Your identification has been saved in /home/student/.ssh/id_rsa.
      Your public key has been saved in /home/student/.ssh/id_rsa.pub.
      The key fingerprint is:
      SHA256:8CttStESwlNmmGot+dXN9cR9x4Hw46gdRmVM5XFj+TQ student@servera.lab.example.com
      The key's randomart image is:
      +---[RSA 2048]----+
      |     o+    .+=oO+|
      |   .o+      =o=EX|
      |   ++ o. o o = o=|
      |  = .o.=. + o o .|
      | . o .o S  + .   |
      |    .  + .+ .    |
      |      o +. .     |
      |     . +         |
      |      .          |
      +----[SHA256]-----+
    2. On servera, use the ssh-copy-id command to copy the SSH public key to the student account on serverb.

      [student@servera ~]$ ssh-copy-id student@serverb
      /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/student/.ssh/id_rsa.pub"
      The authenticity of host 'serverb (172.25.250.11)' can't be established.
      ECDSA key fingerprint is SHA256:BMdnasLF5CBGg42Dx77nuXodXdI9dKoEBQGFK5O0HRI.
      ECDSA key fingerprint is MD5:9e:a8:ec:0c:86:d2:70:34:ef:5a:94:15:6d:48:73:db.
      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
      student@serverb's password: student
      
      Number of key(s) added: 1
      
      Now try logging into the machine, with:   "ssh 'student@serverb'"
      and check to make sure that only the key(s) you wanted were added.
    3. On servera, test key-based authentication by using the ssh command to connect to serverb and to remotely execute the hostname command. The ssh command should not prompt for a password. The results are returned to the terminal on servera.

      [student@servera ~]$ ssh serverb 'hostname'
      serverb
  3. Configure SSH on the serverb host to prevent password authentication.

    1. Confirm that the current configuration on serverb allows users to log in by using ssh password authentication. On servera, log in to serverb as the visitor user with the redhat password.

      [student@servera ~]$ ssh visitor@serverb
      visitor@serverb's password: redhat
      [visitor@serverb ~]$

      Log out of serverb.

      [visitor@serverb ~]$ logout
      Connection to serverb closed.
      [student@servera ~]$
    2. From servera, log in to serverb as the student user.

      [student@servera ~]$ ssh student@serverb
      ...output omitted...
      [student@serverb ~]$
    3. As the student user on serverb use the sudo -i command to change to the root user. If prompted, use the student password.

      [student@serverb ~]$ sudo -i
      [sudo] password for student: student
      [root@serverb ~]#
    4. As the root user, edit the /etc/ssh/sshd_config configuration file so that the PasswordAuthentication entry is set to no. When finished, save your changes and exit the text editor.

      [root@serverb ~]# vim /etc/ssh/sshd_config
      ...output omitted...
      PasswordAuthentication no
      ...output omitted...
    5. Reload the SSH service on serverb. When finished, log out of serverb.

      [root@serverb ~]# systemctl reload sshd
      [root@serverb ~]# logout
      [student@serverb ~]$ logout
      Connection to serverb closed.
      [student@servera ~]$
    6. On servera, verify that the visitor user cannot log in to serverb. Then, verify that the student user can log in by using the previously created SSH keys.

      [student@servera ~]$ ssh visitor@serverb
      Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
      [student@servera ~]$ ssh student@serverb
      ...output omitted...
      [student@serverb ~]$
    7. Log out of serverb and servera.

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

Finish

On the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish securityrisk-recommend

Revision: rh415-9.2-a821299