What’s the password again?

Damn, I forgot the password.
– Me

In your company network, or home network, you have access to several computers, and you probably want to interact with some of them, start some tasks, check some logs, reboot them and so on.

Of course, you are already using ssh to do so.

If you are still typing a username and password each time you log in somewhere, stop it.

Passwords are obsolete

Stop losing your time, looking at your excel to get the password or such, and use the power of the public-key cryptography. Smart people did that for a reason.

The principle is simple :

• you have a (private) key in a file on your computer
• the other computer has your (public) key in a file
• those keys are strongly related

When you are going to connect to the other computer, both ssh and sshd (the daemon waiting for connections) will talk to each other and will check if they can make some kind of association using the keys each of them have. If they succeed, it means your are the one with the good private key (only your computer stores it, nothing else), it knows you, you are how you claim to be, and therefore you have access.

Can be used with GitHub, BitBucket, anything

Note that this approach does not only apply to the networks where you ssh, but to the whole Internet such as when you are using GitHub, BitBucket, or anything that has a login and password.

You are not doing pure ssh command-line into them but you are pushing data into them. Data that need to be authenticated. That’s why they offer the possibility to add some public keys for your account (through their UI) that will be in pair with the private key you have stored on your local computer.

Time to do some hacking

Here is my key

First, we need to generate those keys on our local computer :

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

By default, we won’t put any passphrase, even if that can be considered as a bad practice.

That will generate a private key in the file /root/.ssh/id_rsa :

-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA/gV3aLUTDenLFw7hkkfNcJT4pbnt7gQVcjga4Rik4+hIU6a6
...
-----END RSA PRIVATE KEY-----

Never share this, never ever.

And its related public key in /root/.ssh/id_rsa.pub :

ssh-rsa AAAAB3NzaC1yc2EAAAADA...slxyu9Ki8Hn6jWR root@computer

The keys are related to your user and hostname. You are going to copy that line to any server you want to access. It will use the user@hostname to find out if it has a public key from you.

A message can be encrypted using this public key, only by its private key.

Note that it’s popular to add some options to ssh-keygen, to generate a stronger key and set explicitly the user name in id_rsa.pub such as :

$ ssh-keygen -t rsa -b 4096 -C "email@example.com"

It’s dangerous to go alone, take this

Now, we are going to copy our public key to the server. That will make it be able to identify ourself and let us the access.

The default path used by sshd is .ssh/authorized_keys in the home folder of the user you want to connect with on the server :

root@local:~# ssh john@server

Path is : /home/john/.ssh/authorized_keys

You can create it manually if it doesn’t exist yet.

Its content is quite simple, one line per public key (several users could connect as john on the server) :

$ cat .ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADA...slxyu9Ki8Hn6jWR root@computer
ssh-rsa 2cvUZEP4ZuMtElv/Iu6M6...w8Qoa4A3b8a+YNl trainee@macos

As soon as you save the file, you’ll be able to connect from your local computer on the server, no question asked.

root@local:~# ssh john@server
john@server:~$

One-way only

This config is a one-way only. You can’t connect from the server to the local. If you’d like to do so, you must perform the same actions but from the other side (generate keys on the server and add the public key to the local computer).

But, do not considerer this. A user on a server should never be able to connect to another computer. You should always get exit to your local computer, then connect to the other server. Do not connect nodes between them, it can introduce security issues.

One computer to rule them all

Once you put your public key somewhere, never generate your keys set on your computer. Otherwise you’ll lose the ability to connect on the servers you set up, because the public key won’t “match” the private key. ssh-keygen will warn you if that’s the case, but better not to try. ;-)

.ssh/config

Even the username can be optional

Another great feature is to avoid to type the username you want to login with on the server.

Instead of :

root@local:~# ssh john@staging

It would be nice to do :

root@local:~# ssh staging

And have automatically “john” as user (because this is the one set up with the keys).

To do so, edit the file .ssh/config and add something like :

Host staging
    HostName staging.host.lan
    User john

You can add as many hosts as you want in this file. It’s simply some kind of mapping between a name you give “Host” and User@HostName.

Beyond hosts

This file is not only useful to declare Host mappings. It can contain way more configuration bits, such as :

Host *
    ServerAliveInterval 60

This is to avoid the famous “broken pipe” you’ll get if you are inactive in a ssh session. That will send keep alive packets to be sure the connection stays up.

Beyond ssh

The keys are not only used by ssh.

scp is also compatible (to copy files from/to another host):

$ scp -r staging:/tmp/logs .

It follows the same rule as ssh : using .ssh/config and the set of keys on both sides.

But it’s not enough

Note that for further security, your keys should have a passphrase (that we set to blank in our example), and that you should use ssh-agent to, again, avoid to type it when needed.

If you’re not me, come say hi on twitter : https://twitter.com/chtefid