43 System Hardening – SSH Public Key Authentication with Linux

NOTE: This lab builds upon the labs in Chapters 40 and 41.

In the modern day, one of the most common forms of authentication we encounter are Single Sign-On (SSO) passwords. You may recognize this as a password you type to access a store’s website or the credentials you enter to log on to a video game service. While it is the most commonly used form of authentication, it is not the only option. In this chapter, we will be exploring a more secure alternative through asymmetric encryption. Asymmetric encryption utilizes two keys: a public key (which is typically freely available and has no cost to security if exposed) and a private key (which must never be shared under any circumstances). The basic idea is that anything encrypted with one key can only be decrypted with the other. In this chapter, we will be implementing Public Key Authentication to further harden our Linux servers on our network.

Learning Objectives

• Learn how to implement Public Key Authentication for remote server administration
• Learn how to harden SSH against common cyber attacks

Prerequisites

• Chapter 40 – Network Mapping – Zenmap basics
• Chapter 41 – Network Monitoring – Honeypots

Deliverables

• Screenshot of GNS3 Network
• Screenshot of cat ~/.ssh/authorized_keys command
• Screenshot of a successful connection to ssh with public key authentication
• Screenshot of Ubuntu Desktop being refused connection due to no public key

Resources

• Network Chuck – 5 Steps to Secure Linux (protect from hackers) – https://www.youtube.com/watch?v=ZhMw53Ud2tY&feature=youtu.be&themeRefresh=1

Contributors

• Kyle Wheaton, Cybersecurity Student, ERAU-Prescott
• Dante Rocca, Cybersecurity Student, ERAU-Prescott
• Jungsoo Noh, Cybersecurity Student, ERAU-Prescott

Phase I – Building the Network Topology

The following steps outline the process for creating a baseline network to complete this chapter. It makes assumptions about the learner’s knowledge from completing previous labs.

By the end of this lab, your network should look like the following:

1. Start GNS3
   1. Create a new project and name it

      NOTE: The lab takes heavy influence from the chapter Network Monitoring – Honeypots. It is recommended to save that file as a new project and make adjustments as necessary.

1. In the corp.local subnet, start the IT laptop (Kali) and login
2. Ensure that SSH is enabled and active

   > systemctl enable ssh.service

   > systemctl restart ssh.service

3. Generate a new RSA public/private key pair

   > ssh-keygen -t rsa -b 3072

   Command	Explanation
   ssh-keygen	Name of program
   -t rsa	Specifies the “T”ype of key to create (RSA key)
   -b 3072	Specifies the number of bits in the key generator (3072 bits)

   1. Press enter when prompted where to save the key to place it in its default location: ~/.ssh/id_rsa
   2. You may enter a password to further protect your private key, but you can also press enter again twice to skip this
      

      

   3. Verify that the both the private (id_rsa) and public (id_rsa[.]pub) have been generated by looking at the saved location

      > ls -l ~/.ssh/id_rsa*

       

      

4. In the corp.dmz subnet, start the primary server and login
   1. Enable The SSH service

      > systemctl enable ssh

      > systemctl start ssh

5. Transfer the public key to the DMZ server (server.corp.dmz), which will be authorized for remote logins
   1. On the Kali machine, securely move the key using SSH

      > ssh-copy-id username@10.0.0.4

      NOTE: Remember that your server’s username may vary.

       

      

   2. On the server, verify that it was transferred successfully

      > cat ~/.ssh/authorized_keys

       

      

6. Test to see if it worked by starting a new SSH session from the Kali box to the server

   > ssh username@10.0.0.4

    

   

   NOTE: We successfully logged into the machine without needing a password! However, if you decide to further secure your RSA keys with a passphrase during the ssh-keygen command, you will be prompted to enter that passphrase when using SSH. It should be noted that this is locally processed and not transmitted over the network.

1. Login to the DMZ primary server
2. Modify the configuration file for the server-side SSH daemon with the following changes

   > vi /etc/ssh/sshd_config

   1. Change AddressFamily from any to inet to only listen for IPv4 connections
   2. Set ListenAddress to 10.0.0.4
   3. Add an AllowUsers directive followed by the primary account’s username
   4. Change ClientAliveCountMax from 3 to 2 to reduce the amount of time before idle client sessions are disconnected
   5. Change ClientAliveInterval from 0 to 15 to set a timer on SSH Keep Alive messages
   6. Set PasswordAuthentication to no to disable passwords/passphrases
   7. Set PermitRootLogin to no to disable the root user from being accessed via SSH
   8. Change Port from 22 to any other nonstandard port number to obfuscate SSH services
   9. Set PubkeyAuthentication to yes to allow for public key authentication
   10. Use this image for configuration reference
       

       

3. Restart the SSH daemon

   > systemctl restart ssh

4. From the admin laptop, test the new SSH service
   1. Try to login to root on the DMZ server via SSH

      > ssh root@10.0.0.4 -p 434

       

      

      NOTE: This example changed the default port to 434, be sure to adjust this as necessary.

   2. Try to login into the primary user

      > ssh username@10.0.0.4 -p 434

       

      

End of Lab