SSH Keys Made Easy

By | May 18, 2018

Let’s talk about what makes an SSH key pair work, making them secure, and how to actually use them, in plain English!

What is an SSH Keypair?

An SSH Keypair is a set of two keys that correspond to each other. There is a Private Key that you need to use to authenticate against the public key – do not reveal this key! The Public Key is added to the user’s ~/.ssh/authorized_keys file, and is public – you can add that key anywhere! If a “bad guy” gets the public key, it just allows you to log in to their system without entering a password.

When you try to connect to another system with SSH (either through another *nix device, or over PuTTY, or really any other way to initiate the connection), SSH is set by default to prefer checking for keys before passwords. Because keys are typically longer than passwords, they are the preferred route to take, especially if logging in directly as root.

The server you are connecting to receives an encrypted message, encrypted by your private key, and attempts to decrypt it with all the public keys it has access to. If it can decrypt it, it uses that key. In no way is your private key revealed to the server you connect to.

How do I generate the keypair?

This is going to vary, depending on where you are connecting from. If you are wanting to generate it on a Linux terminal, or Bash on Windows, you’ll need an OpenSSH key; if you’re using PuTTY, you’ll need a PuTTY key.

Using OpenSSH

If you are logged in to the terminal you want to initiate your SSH connection from, you can try to run ssh-keygen -b 2048 -t rsa, and press Enter. It will ask you what path to use – accept the default if it’s your first keypair you’re creating. Then, it will ask for a passphrase (and confirmation) to lock the key. It will then generate the keypair in the directory you specified (default is ~/.ssh/id_rsa{,.pub}). Keep the private key file private; you can share the .pub key with any servers you wish to log in to.

Creating a second keypair (id_rsa was already taken for my production machines). Obviously, accept the default file name when you create your first key pair.

Creating a second keypair (id_rsa was already taken for my production machines). Obviously, accept the default file name when you create your first key pair.

If you assigned a password, you’ll need that password whenever you attempt to use the key. Since OpenSSH is built in to many Linux-based systems, you can simply start using ssh [email protected] to connect with your private key!

Whoops, no you can’t! We need to copy the contents of the id_rsa.pub file to the remote server! Hopefully, you have access to the remote server with a password still, and can log in! Once you do, create the file ~/.ssh/authorized_keys (you may need to create the .ssh directory as well). Simply copy and paste the contents of your public key into this file, and save it. Ensure it has Read & Execute for User only – chmod 600 authorized_keys should do it for you.

Using PuTTYgen

If you’re using Windows, and not using Linux on Windows Subsystem (LWS), you will likely be using PuTTY to connect. If you installed the entire PuTTY suite, you will have PuTTYGen installed. It should be in the same folder as your PuTTY.exe file.

Once it loads, click on Generate. It will ask you to move your mouse around to generate randomness – it may take a minute or so. Fill in a “Key comment” to identify the key; choose a passphrase for when the Private Key loads. This is to ensure the key can not be used without your knowledge if stolen. You can copy the “Public key for pasting into OpenSSH authorized_keys file:” text into the ~/.ssh/authorized_keys file on your target server, and that’s all the work on the server! You can then hit the “Save private key” button to save a .PPK file for use with PuTTY.

An example SSH key generated from randomness (don't worry, that key won't get you in anywhere)

An example SSH key generated from randomness (don’t worry, that key won’t get you in anywhere)

If you want to use the same key from multiple systems, you can also export as an OpenSSH key under the Conversions menu. You can then pop that generated private key into your ~/.ssh/id_rsa file, and have the same abilities, including the password.

Passwords?

Yes, I mentioned that this is stronger than most regular password authentication methods by themselves. So we turn this into a 2-factor authentication method by adding a Passphrase to the key. By doing so, the key will only unlock when the passphrase has been entered correctly!

Make your properties window match this, but replace the parameter with your .PPK file

Make your properties window match this, but replace the parameter with your .PPK file

If you are using PuTTY, you will use Pageant to load the private key, and automatically authenticate on PuTTY sessions. To load the key at your computer’s startup, navigate to C:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup, and create a new shortcut. Choose the target as your pageant.exe program, and give it whatever name you want. Then edit the Properties, and¬† add (in quotation marks) the path to your .PPK file. After you create the shortcut, double-click it to verify it works. If you put in a passphrase, it should prompt you before unlocking the key.

Great, why though?

You can use keypairs for more than just authentication – including permitting or restricting what a user can do as well! By adding in commands in your ~/.ssh/authorized_keys file, you can dictate what each key can be used for! On the server, you can run man authorized_keys to view all the options available (i.e. using certificates, assigning environmental variables, where the key is allowed to access the server from, etc).

Any other concerns?

Well, now you can disable root logon through SSH with passwords. You should disable this, as root exists on virtually all SSH servers, and will be constantly tried over and over again!

Edit your /etc/ssh/sshd_config file (as root), and ensure PermitRootLogin is set to no or without-password. For example, I have my setting as “PermitRootLogin without-password” – only keys can login as root. Save the file, and restart the SSH Service.

This does not guarantee that root will not be accessible, even if set as no. If a bad guy gets on your server, even as a regular user, it is possible for them to wreak havoc. This also does not prevent regular users form using su or sudo to elevate, if permitted. Let this be just one extra tool in your tool kit for securing your servers!