SSH Authentication with Keys

Authenticating SSH with certificates is a secure and convenient alternative for passwords, especially for those who needs to deal with a lot of servers with or without automation and don’t want to save a clear password somewhere along code or provisioning scripts.

Authentication with keys work with simple steps:

• Create a public and private key pair
• Keep the private key on the device you want to access to the SSH servers
• Copy the public key to the remote SSH server you want to access

This article will cover how these simple steps can be performed on a standard Linux box and also some advanced points that can help automating these tasks.

Creating and Managing Key Pairs

The tool we will use to create an ssh key pair will be ssh-keygen. This tool can be used to creating and managing authentication keys.

Creating Key Pairs

If you want to create a default certificate, just run the command from your user as ssh-keygen. You will then be prompted for certificate location and if you want to provide a passphrase. Passphrase is optional but it keeps your private key secure in case of a physical access to your device. By default the resulted key file is stored to the current users .ssh directory. If you used default options you should find two files under this directory. .ssh/id_rsa is the private key while .ssh/id_rsa.pub is the public key.

To control the ssh-keygen without any interaction, we will use options.

# mkdir ~/.ssh/keys
# cd ~/.ssh/keys
# ssh-keygen -q -t rsa -b 2048 -N "secret" -C "secure access device key" -f ~/.ssh/keys/rsa_1

Note the options, -t to specify certificate type, -b denotes key size, -N gives passphrase, -C helps you leave a comment for the key, and -f specifies the output file location. The default RSA 2048 bit certificate is secure enough for today’s technology though feel free to try and use 4096 bit. You can also create DSA, ECDSA, or ed25519 keys although RSA is the most compatible one of these 4 choices.

The most important thing to remember here is that if you forget your passphrase there is no way to recover your private key!

Like the interactive command, you will find two files under .ssh/keys; rsa_1 as private key and rsa_1.pub as public key.

Managing Key Pairs

Here are some useful management features of ssh-keygen that might help you during the life-cycle of your key pair.

Changing the passhrase

# ssh-keygen -p -P "Secret" -N "New Secret" -f ~/.ssh/keys/rsa_1

Exporting your key pair to be used in other software

It can sometimes be convenient to use your existing key pair for other purposes such as PEM format.

# ssh-keygen -e -m PEM -f ~/.ssh/keys/rsa_1 > ~/.ssh/keys/rsa_1.pem

Regenerate public key

# ssh-keygen -y -f ~/.ssh/keys/rsa_1 > ~/.ssh/keys/rsa_1.copy.pub

Using Key Pairs

Letting Remote Server Know Your Authentication Key

First and foremost, in order to use a key to authenticate a remote ssh server, the public key should be known by the target ssh server. In order to do this, the public key is added to authorized keys file of the desired user on the remote server. For simplicity, root user will be considered in this article, but it is possible to do this for any user that can login via SSH.

Access to remote server as root or any user you want the key to access. Make a quick check on sshd config to see what is the name of the authorized keys format:

# cat /etc/ssh/sshd_config|grep -i authorizedkeysfile

Let’s assume it is the default authorized_keys. Copy your public key to this server via any method (vi, nano, scp, etc.) you want as ~/.ssh/keys/rsa_1.pub. Now this public key needs to be added to the authorized keys file:

# cat ~/.ssh/keys/rsa_1.pub >> ~/.ssh/authorized_keys
# chmod 0600 ~/.ssh/authorized_keys

Note the second line which makes certain of the required permissions of the authorized_keys file.

With this step, this user can now be logged in using this key.

ssh-copy-id can also be used, on the local device to automate the above step.

# ssh-copy-id -i ~/.ssh/keys/rsa_1.pub root@server1

Authenticating to Remote Server

Next step is using the key to access to the remote server. In order to use the key to login:

# ssh -i ~/.ssh/keys/rsa_1.pub root@server1

You can also use other tools to skip this process. Such as ssh-agent:

# ssh-add ~/.ssh/keys/rsa_1

You can also edit the .ssh/config file to manually specify which key to use when and also other useful settings. Here is a sample .ssh/config file:

Host server1
   IdentityFile /home/user/.ssh/keys/rsa_1
   User root
   ForwardAgent yes
   AddKeysToAgent yes
   ServerAliveInterval 60

Host server2
   IdentityFile /home/user/.ssh/keys/rsa_2
   User admin
   Port 41747
   ForwardAgent yes
   AddKeysToAgent yes
   ServerAliveInterval 60

This configuration file is a great help when you need to differentiate and/or automate the logging into these systems without any additional arguments. Now one can simply do:

# ssh server1
# ssh server2

The host options specified in .ssh/config will be considered when the hostname that is connected matches the section in the configuration.

Further More…

Now it is possible to use the public key safely, you can commit it, put it somewhere that it can be downloaded when you cannot copy/paste to a server. One great use is to putting your public key to authorized_keys automatically with your provisioning script so when you install a server, you don’t follow the same steps and server is ready for you to login.

There are other advanced use cases for ssh-keygen such as issuing multiple private keys using a CA certificate and putting only the CA certificate to authorized_keys file which allows multiple different private keys to access. But it is good for another article.