Passwords are always a mess to be managed.

Why not switching to a different approach using cryptographic keys to connect to your machines? Public key authentication is a good, alternative method to log into your servers!

SPOILER ALERT:

There are different types of public-key authentication. In this post I will refer to SSH keys. GPG keys will be discussed in a future article.

Passwords are boring

I am not a fan of passwords at all... They are not for me! I use a good password manager, I remember my passwords (where I still need to use one), but the main complains come from my family and friends that have always to create longer, stronger, more complex passwords for any account they have to use.

Pros:

• Password are convenient. It can be easy to remember a password if you have a good memory and a good way to build them.
• There is no adoption barrier, everyone knows how to log in using username and password.
• Administrator can increase the security by enforcing the policy on password strenght.
• If you are able to create strong password, you can be safe from common brute force attacks.

Cons:

• The most popular password of 2019 was still "123456". If this is your password somewhere, go and change it. Immediately. I am not joking.
• To remember password we favor easily remembered and crackable ones.
• To save neural storage we reuse password across apps and websites.
• A weak point of user and password will be always sent to the server, and this is prone to hacking. Attackers love to clone popular websites to stole user credentials. If you mistakenly connect to one of those fake websites is easy to be misled.
• Web services could store password in clear text on their DB. Sysadmins and intruders could see your password any time.
• Password policies are always different from account to account: some sites require minimum 8 characters, some 12, some requires a symbol, some an uppercase letter, a number maybe, more numbers... ARGH!
• Administrators can enforce you to change the password every X days for your security, losing any convience in remembering your password and favoring bad creation patterns, due to lazyness.

Public key authentication is smarter

Keys are generated in pairs of public and private key. Each key pair is unique and you must have both of them in order to authenticate. Important to notice: in this case, can be considered safe to reuse a single key-pair on multiple systems.

Public key authentication looks something like this:

1. Generate a key pair.
2. Share your public key with the server.
3. Show the server you have the corresponding private key upon authentication.
4. Proving correspondence.
5. You're in!

There are pros and cons also with public key authentication usage.

Pros:

• A lot more difficult to hack than a simple password: keys can be generated with different lenghts, usually between 1024 bits and 4096 bits, so it is very complex to brute-force them.
• Keys are generated by the machine, so not easy-to-guess like a human generated password.
• The private key remains secret and is never shared by any means to the server. If an attacker tries to steal your credentials during the authentication process, he will never get your private key.
• You can add a passphrase to the private key.

Cons:

• The private key must be kept in a safe place.
• Private key must be stored on the device where you initiate the connection, so you must be able to take it safely with you if you change your device.
• If an attacker gets access to you private key, he will be able to access all the server where your public key is stored.
• Key generation takes a bit of work to be set up.
• Central management of SSH keys is not easy.

Key pair generation

Even if I put it in the cons of public keys, it is not that difficult!

We will generate a test key pair for demonstartion purposes:

$ ssh-keygen -o -a 100 -t ed25519 -f ~/.ssh/id_ed25519 -C "fabio@zambroid.ch"

Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in ~/.ssh/id_ed25519
Your public key has been saved in ~/.ssh/id_ed25519
The key fingerprint is:
SHA256:ZgqgHCRCIoonQKmRdPOtxTvDpcHtL8FCs/4RT7D6F/I fabio@zambroid.ch
The key's randomart image is:
+--[ED25519 256]--+
|X*.o             |
|%.. o + .        |
|=oo  . O +       |
|o+..  = X o      |
|..  .. OS* .     |
|     ..+=.*.     |
|      .o ooo.    |
|        o oE     |
|         o.      |
+----[SHA256]-----+

At this point you have your keys stored in your home in .ssh directory (which is the default directory for ssh clients on Linux, in this case we specified a filepath explicitly via -f flag).

The .ssh folder will have the following content now:

$ ls -la ~/.ssh/
total 28
drwxr-xr-x  2 fabio fabio 4096 17 aug 14.02 .
drwx------ 42 fabio fabio 4096  28 sep 19.33 ..
-rwx------  1 fabio fabio  464  28 sep 12.13 id_ed25519
-rwx------  1 fabio fabio   99  28 sep 12.13 id_ed25519.pub

Pay attention to the permissions: public and private key must be readable/writable/executable only from the user (700).

Looking into our private key we will see something similar to this:

-----BEGIN OPENSSH PRIVATE KEY-----
random characters...
-----END OPENSSH PRIVATE KEY-----

The public key, instead, is the one you can share, and will look similar to this:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBB1uvH/HM2Dnw0sbW+oIEfJXVy3/WLPk0b2sUTbxvBT fabio@zambroid.ch

Wait, what is -t ed25519?

Ed25519 is cryptographic alghorytm introduced with OpenSSH 6.5. It is based on elliptic curve cryptography to offer a better security with faster performance (compared to DSA or ECDSA).

RSA is the most used key pair generation algorithm (also because it is the default one on Linux machines), but compared to Ed25519 it is slower and it is considered less safe for keys smaller than 2048-bit length.

As you will notice, Ed25519 public key is compact, and the key-pair generation is fast.

SSH connection with public-key

Easier done than explained :)

1. Connect on the destination server with your legacy password.
2. In your user home directory go in the .ssh folder and create a file called authorized_keys.
3. Paste your public key in it (one per row, if many).

At this point disconnect from the machine, and connect to the client via ssh user@hostname command. If you put a passphrase on the key you will be prompted to input it, otherwise you will be logged in without any more interactions.

Conclusion

If you want to improve your server security and avoid to manage hundreds of passwords for all the systems you deal with - then you must switch to public-key authentication methods.

Use a longer key to increase the security, put a passhprase on it, and remember to store it safely and back it up!