Using SSH Keys

AWS LogoSSH keys provide a more secure way of logging into a your server using SSH rather than using a password alone. A password could be cracked using a brute force attack or a dictionary attack. SSH keys on the other hand are very long and complex and will provide much better security.

Generating an SSH key pair  (public and a private key) provides a these long keys. It works by placing the public key on the server you want log into. You can then log in using a client machine that has the private key. This has the advantage of letting you log in with being prompted for a password. This is very useful for issuing commands or copying files remotely. You can increase security even more by protecting the private key with a passphrase (more on that later).

You do need to keep your private key(s) secure, just like the keys to your house or car they will let whoever has them inside. To carry the analogy further you also need to back them up because if you loose them they cannot be recreated.

These instructions are written for Linux, BSD and Mac users. Windows users might need to install a package like PuTTY to get this functionality.

Step One: Create the RSA Key Pair

The first step is to create the key pair on your client machine.

on the client machine (there is a good chance that this will just be your computer):

ssh-keygen -t rsa

Step Two: Store the Keys and Passphrase

Once you have entered the Gen Key command, you will get a few more questions:

Enter file in which to save the key (/home/ubuntu/.ssh/id_rsa):

Just press enter here if you want to save the keys to the default location.

Enter passphrase (empty for no passphrase):

It’s up to you whether you want to use a passphrase. The advantages of the passphrase is that if your key get compromised then the attacker will then need that passphrase every time the key is used. The downside is that you will have to use that passphrase every time the key is used, negating the convenience of the no password login.

The entire key generation process looks like this:

ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/ubuntu/.ssh/id_rsa): /Users/ubuntu/Desktop/test
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /Users/ubuntu/Desktop/test.
Your public key has been saved in /Users/ubuntu/Desktop/test.pub.
The key fingerprint is:
SHA256:WGWxTx8yyCakYCUgjZkQLSKVnCESitUOB2k6SKCn97k ubuntu@test.local
The key's randomart image is:
+---[RSA 2048]----+
|@@*O+.. . +. |
|%=X.oo o + o |
|O+.+ . o = + . |
|+o . o o o + . |
|... . S . . |
| . . . |
| o |
| . |
| E |
+----[SHA256]-----+

Step Three: Copy the Public Key

Once the key pair is generated, you’ll need to copy it over to the server you want to use it on. There are two ways of doing this. Firstly you can use the ssh-copy-id command. However this command is not supported on all platforms including the Mac sadly. To copy the public key over use the following command. Remember to substitute the IP address for your server.

ssh-copy-id user@10.20.30.40

Alternatively, you can use SSH to copy over the key using the old password authentication method (hopefully for the last time). The location of the keys you want to use is assumed to be the default location this case.

cat ~/.ssh/id_rsa.pub | ssh user@123.45.56.78 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

No matter which command you chose if it’s the first time you’ve ever logged in from your client machine, you’ll see something like this:

ssh ubuntu@10.20.30.40
The authenticity of host '10.20.30.40 (10.20.30.40)' can't be established.
ECDSA key fingerprint is SHA256:iv+pax2DfE45fHF42VB09shCK3XYqR/DAgF0amHDAXlf5vObw.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.20.30.40' (ECDSA) to the list of known hosts.
ubuntu@10.20.30.40's password: 
Last login: Wed Sep 28 07:15:10 2016 from 10.20.30.10

Now you can go log into ubuntu@10.20.30.40 without a password  (unless you set a passphrase).

Permission Issues

Sometimes you might encounter problems with permission issues with the .ssh or authorized_keys on the target machine. You will see something like the following in the sshd log.

Jan 11 21:25:00 xxyy sshd[1310]: Authentication refused: bad ownership or modes for file /home/xxyy/.ssh/authorized_keys

To fix this you’ll need to set the following permissions.

# authorized_keys to 600 and the .ssh directory to 700
chmod 700 .ssh
cd .ssh
chmod 600 authorized_keys

 

Optional Step Four: Change your password

You should not need your user password any longer to log into the machine any longer. But you might want to if you access the machine from somewhere without the private key. It’s probably a good time to change your password anyway to something nice and long and cryptic since you won’t be needing to type it every time you want login.  Use the standard password management program to change your password on the server.

passwd

Optional Step Five: Disable password login

If you’re sure you don’t want to use passwords anymore then you can disable password login for your user. Make sure that your SSH key pair login works of course before doing this otherwise you might get left stranded. Once you’re logged into to your server

Firstly edit the SSH config file:

sudo nano /etc/ssh/sshd_config

If you want to do this for the root user then find the line that includes PermitRootLogin and modify it to ensure that users can only connect with their SSH key like this.

PermitRootLogin without-password

If you want a systemwide change that allows no use of password then you can do the following. Edit the file and set the values to no like this. Be careful with this as you might be ‘burning your bridges’ if you end up loosing your private key for some reason.

ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

Put the changes into effect:

reload ssh