Keys, SSH and not typing passwords

SSH Keys

When you login to a remote computer it will each time ask for a password, something that can become tedious. For that reason we can use keys, small pieces of information (essentially strings) on each computer that are used for each computer to identify the other and acknowledge that they are who they say they are.

You need to create two keys for this. One key will be stored on the server - the computer you try to connect to. The other key will be stored on your computer.

The first key, the one that the server holds, is called the private key and there is only one. The other key that we hold is called public since there can be many copies of this key to many other computers. The two keys are heavily dependent on each other. If one changes, then the other won't work.

But let's how all this looks in practice..

 

From the machine you are trying to connect from


ssh-keygen -t rsa -b 4096


This creates a key based on algorithm RSA with length 4096 (default is 2048). The longer the key, the harder to break but on the downside it takes a bit more time to authenticate (more CPU usage).

Generating public/private rsa key pair.
Enter file in which to save the key (/home/a/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/a/.ssh/id_rsa.
Your public key has been saved in /home/a/.ssh/id_rsa.pub.

That should generate two keys:

1. ~/.ssh/id_rsa - a private key that is unique to the machine and if lost, security is breached


2. ~/.ssh/id_rsa.pub - a public key, that can be visible to anyone, without any security impact

The passphrase is similar to a password and is added to the key for extra security. In case your private key gets stolen, you should have a little time to change all keys on the systems.

 

At the server you are trying to connect to

In order to connect from the machine where we created the keys, to a remote server we need to configure the server and let it know that he can trust the x machine with public key y. From the previous example that key is the id_rsa.pub

On the server machine we need to append that id_rsa.pub, since it's public, there is no problem if we send it with an email or even the insecure telnet. Once we have the id_rsa.pub string on the server, we append it to ~/.ssh/authorized_keys


cat PATHTOKEY/id_rsa.pub >> ~/.ssh/authorized_keys


You can even add it manually with a text editor if you happen to have the public key as a string (from an email for example).

Now you can add that to more than one servers since it's a public key. The id_rsa should stay secure on your machine while the id_rsa.pub can be stributed to the machines you are trying to connect to.

 

The droplet way (digitalocean)

Now there are some graphical ways to do so without dwelling inside your machine but I think it's easier to do it manually now that we got an idea of how it works with ssh keys. The easiest way to add a key is with this command

cat ~/.ssh/id_rsa.pub | ssh root@xxx.xxx.xxx.xxx "cat >> ~/.ssh/authorized_keys"

where xxx.xxx.xxx.xxx is the IP of your droplet. Once that is succesfull, you would be able and ssh to your droplet without any password asked.

 

Troubleshooting

Known_hosts error

Trying to ssh to your droplet gives:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
b9:75:ff:10:fa:42:f1:b7:6f:d2:1f:8e:f4:f7:1a:cd.
Please contact your system administrator.
Add correct host key in /home/a/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/a/.ssh/known_hosts:6
remove with: ssh-keygen -f "/home/a/.ssh/known_hosts" -R 178.62.200.200
ECDSA host key for 178.62.200.200 has changed and you have requested strict checking.
Host key verification failed.

The reason we get this message is that we erased the droplet and created a total new. However our computer has stored the key of the older droplet. A fast fix is to simply erase all known_hosts:

rm ~/.ssh/known_hosts

 

Droplet password doesn't work

Check first if you got an email with a new password. If not, reset your password for the specific droplet following digitalocean's guidelines.