Many sites enable access to SSH through their firewalls, but this exposes them to password probing. This is usually an automated process of trying to authenticate with commonly-used username/password pairs. SSH supports public-key authentication and it greatly reduces the risk of remote exploits due to weak credentials. Let’s further explore why you would consider this approach, and how to implement it.
Before diving into the implementation details, let’s consider the advantages and disadvantages of using public-key authentication.
- You must possess the private key that matches the public key stored on the server you wish to log into. Without the key, password probing can never succeed, since a remote attacker should never have your private key. If you believe your key has been compromised, generate a new one!
- Through the use of an SSH authentication agent, you load your key and enter the corresponding passphrase once. Thereafter, the agent handles passing the information to the requesting server. In effect, this means that once you’ve loaded your key, you do not need your passphrase (and depending on your configuration, not even your username) to login. This makes authentication both safer and faster!
- [Unless you are so foolish as to generate a key-pair for the root account,] You cannot login remotely as root. But then you shouldn’t be doing this anyway — login normally, and then use sudo for all activities that require privileges.
- Users have to generate key pairs, and someone has to put the public keys in place on the appropriate servers. However, this can be scripted!
The setup involves several steps, but not all of them have to be repeated for each server. The steps indicate how often they must be performed.
- User must generate a key-pair (1X).
- User (or an administrator) must place the public key on the appropriate server (1 X each server).
- The administrator enables public-key authentication for the SSH daemon (1 X each server).
- (Optional) User sets up an SSH authentication agent (1X).
Create the key pair
You can use one of the two methods below for generating the public-private key pair.
- Generate the key pair on a system with ssh.
- Use the command
ssh-keygen -t rsato generate a 2048-bit RSA key.
- Use the command
- The puttygen tool on Windows as part of the puTTY package.
- Launch puttygen.
- Select the SSH-2 RSA radio button in the parameters section, and enter 2048 for the number of bits in the generated key.
- Click on the ‘Generate’ button.
- After generating the key, using the ‘Conversions’ menu and select ‘Export OpenSSH key’ and save the private key to a file, e.g. ‘id_rsa’, and cut/paste the public key to another file, e.g. ‘id_rsa.pub’.
Place the keys in the correct locations
If you used PuttyGen to create the keys, and want to use Pageant as your SSH authentication agent, you do not need the exported private key. In any case, copy the public key to the server and append it to your
authorized_keys file. For example, if your username is ‘jdoe’, then this file is something like
/home/jdoe/.ssh/authorized_keys (your system may place user home directories in a slightly different location). Each key in this file is on one line, even though it may appear to be several lines long due to wrapping.
Configure sshd on the server
On your server, you need to modify the
sshd_config file, typically located in the
/etc/ssh directory. Make sure you find the three lines shown below, and confirm or change each setting (yes/no) to match:
When you are ready to test, stay logged in on the server in case you’ve made a mistake somewhere, in which case you’ll have to be at the console to fix it. Restart the sshd daemon (e.g.
/etc/init.d/ssh restart), and then try logging in from a client. If you want to test using an SSH authentication agent, follow the steps below beforehand.
SSH Authentication Agents
I mentioned the use of SSH authentication agents above. There are two that I’ve used — you may have your own preference:
On Windows, pageant is part of the puTTY package. When you launch it, it creates an icon in the system tray. Open this, and select the Load key button. Navigate to the location of your private key, e.g. identity.ppk, and open it. You will be prompted for the passphrase, and when you successfully enter it, the key is loaded for use.
On Mac OSX, try SSH Agent. It’s use should be self-explanatory.
Public-key authentication provides a safe means of authenticating that, after the initial setup, can also provide usability improvements due to faster logins. You should also note that other application that take advantage of SSH can use this too. For example, you can use an SFTP client (e.g. FileZilla or CyberDuck) seamlessly. Just check to make sure that your sshd_config file has the line below:
Subsystem sftp /usr/lib/openssh/sftp-server
This is a typical default setting, so it is likely already there. Now you have terminal and file-transfer capabilities that are secure, easy to use, and safe from simple attack probes!