"

43 System Hardening – SSH Public Key Authentication with Linux

Jacob Christensen; Isha Patel; and Arjun Nath

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

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

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:

Picture of network topology
Figure 1 – Network topology
  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.

Phase II – Configuring Public Key Authentication

To begin implementing a Public Key Authentication system, we first need to generate a public key pair. We’ll give the DMZ server the public key. This key will act as the authenticator of anyone who attempts to log in holding the private key. We provide the private key to the Kali machine, and later try to launch an SSH session from the Kali machine to the DMZ server

  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
      Picture of commands
      Figure 2 – Terminal Command Execution
    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*

       

      Picture of commands
      Figure 3 – Terminal Command Execution
  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.

       

      Picture of Commands
      Figure 4 – Terminal Command Execution
    2. On the server, verify that it was transferred successfully

      > cat ~/.ssh/authorized_keys

       

      Picture of Commands
      Figure 5 – Terminal Command Execution
  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

     

    Picture of commands
    Figure 6 – Public Key Authenticated SSH Session

    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.

Phase III – Further SSH Hardening

While we have successfully implemented this form of authentication over SSH, simply leaving it in place would be unwise from a security perspective. We can implement a few additional changes to the SSH service running on the DMZ to enhance the setup’s security.

  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
      Picture of SSHD configuration
      Figure 7 – SSHD configuration
  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

       

      Picture of Commands
      Figure 8 – Terminal Command Execution

      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

       

      Picture of Commands
      Figure 9 – Terminal Command Execution
End of Lab

Deliverables

4 Screenshots are needed to earn credit for this exercise:

  • 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

Homeworks

Assignment 1 – Add another public key to the server

  • Ensure/add a client Linux-based machine to your corps.local. network
  • Create a new public key (RSA) and copy it to the server
  • Ensure the key works for connecting the new VM to the network

Assignment 2 – Add an Elliptic Curve Digital Signature Algorithm key pair to the network

  • Ensure/add a client Linux-based machine to your corps.local. network
  • Create a new public key (ECDSA) and copy it to the server
  • Ensure the key works for connecting the new VM to the network

GRADING REQUIREMENTS: Same as Deliverables with appropriate encryption methods

Feedback email
Figure 00 – Contact us via prmaster@erau.edu

License

Icon for the Creative Commons Attribution-NonCommercial 4.0 International License

Mastering Enterprise Networks 2e Copyright © 2024 by Mathew J. Heath Van Horn is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License, except where otherwise noted.