41 System Hardening – SSH Public Key Authentication with Linux

Jacob Christensen; Isha Patel; and Arjun Nath

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



  • 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



  • 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 are to create a baseline network for completing this chapter. It makes assumptions about learner 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: LAB_24

      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 with the public key. This key will act as the authenticator of anyone who attempts to log in holding the private key. We give the private key to the Kali machine, and later attempt 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

    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

      > 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@

      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@

    Picture of commands
    Figure 6 – Public Key Authenticated SSH Session

    NOTE: We successfully logged into the machine without needing a password! However, if you decided 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 there would be unwise for security. We can implement a few other changes to the SSH service running on the DMZ to make the setup more secure.

  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
    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@ -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@ -p 434

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


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


Assignment 1 – Add two more public keys to the ssh server

  • Add two public keys to the server from two of the Ubuntu desktops
  • Show them successfully connecting afterwards


Icon for the Creative Commons Attribution 4.0 International License

Mastering Enterprise Networks Copyright © 2024 by Jacob Christensen; Isha Patel; and Arjun Nath is licensed under a Creative Commons Attribution 4.0 International License, except where otherwise noted.

Share This Book