Many novice users to Linux are surprised to learn that the most secure method to connect to another server with SSH is using keys.
We computer users have been conditioned to use passwords for everything.
It’s surprising to learn that there are methods other than passwords, but there is something better: cryptographic keys.
In this tutorial we will learn what SSH keys are and why they are better than passwords. You will learn how to set them up on your computer and how to use them to login with SSH without a password.
Table of Contents
- What are SSH keys?
- What are Encryption Algorithms?
- Generating SSH keys – RSA 4096 bits
- Generating SSH keys – ed25519
- Setting up Passwordless SSH Login
- Login Using Your SSH Keys
- Passwordless SSH Login In The SSH Config File
What are SSH keys?
Public key cryptography refers to a cryptographic system that uses key pairs.
The pair is represented with two files, one is designated as the public key file and another as the private key file.
These key pairs are generated by utilities like openssh using cryptographic algorithms. Which algorithms to use depends on user choice.
The effectiveness of the keys are based on how private and secure we keep the private key file.
The public key file can be distributed to any other computer or server or even fall into the hands of the open public internet and the security of our keys will not be compromised.
The system consists of distributing the public key to a server, the server using this key to open an SSH connection only if the computer login in has the private key pair of that public key.
This communication is encrypted and even if the internet connection is insecure, no one outside these computers can decrypt this communication.
The main security comes in the way the key pairs initiate a connection.
As opposed to using passwords where the initial login happens in an insecure manner of transmitting the password to the server, using key pairs initiates the connection in encrypted form.
Making cryptographic keys like SSH keys much better than passwords.
What are Encryption Algorithms?
The first step to using SSH keys is to generate one key pair.
First of all we have to decide which algorithm to use to generate our keys. There are a few to choose from.
There are RSA, DSA, ECDSA, and EdDSA. All of these algorithms are used for asymmetric encryption, but the way they go about working is different.
- RSA is the gold standard of cryptographic algorithms. Originally developed in the late 1970s, it uses integer factorization, an algorithm based on the difficulty of factoring large numbers. Over the years RSA key bit lengths have grown in size making it still viable to use today.
- DSA, the Digital Signature Algorithm was developed by the US government. It follows a similar schema to RSA but goes about working with Discrete Logarithm Problem, an algorithm based on the difficulty of computing discrete logarithms.
- ECDSA is a new modern Digital Signature Algorithm developed by the US government based on DSA. The algorithm is based on using elliptic curves.
- EdDSA is another algorithm using elliptic curves based on DSA but using an implementation much more secure than ECDSA. It uses the Twisted Edwards Curve and the Curve25519. Together they make the public key signature algorithm known as Ed25519.
ECDSA, while updated and modern, still shares some of the insecurities of DSA if not properly used by a novice user.
These two algorithms shouldn’t be used today.
RSA can be used but a key size of at least 2048 bits is recommended and 4096 bits is better.
If your aim is to have the most compatibility, choosing RSA is the way to go.
Ed25519 is the most popular key encryption algorithm today used by most DevOps. Overall ed25519 is the fastest performing algorithm.
If you’re working with modern servers and newer Linux distributions, compatibility will not be an issue and thus choosing ed25519 for its speed is the way to go.
Generating SSH keys – RSA 4096 bits
Deciding on which SSH key pair algorithm to use boils down to RSA and ed25519.
RSA is the most widely implemented and supported algorithm used by most clients.
ssh-keygen -t rsa -b 4096
Here we are using a utility that is part of openssh named
ssh-keygen, we invoke it to generate a key pair for us.
-t option we tell it which algorithm to use. In our example we chose the RSA algorithm.
-b option we specify the number of bits in the key to create. In our example we chose a 4096 bits key.
After inputting the command it asks us for the name of the key. We can give it any name but if we leave empty like we did it gives it the default name.
Then it asks us for a passphrase.
The passphrase itself works as a password to be inputted every time we are going to use our keys to login to a server. If we don’t give it a password, we can still use the key fine and securely, but if someone were to access our computer without authorization they can get access to all of our servers and connections.
There are people that chose to work without a passphrase but it is recommended to use one.
If we list the files in our system user .ssh directory where all of our SSH files are placed in, we see two files were created.
There is a file named id_rsa and another one named id_rsa.pub.
The Public Key (.pub File)
The id_rsa.pub file contains the public key of our key pair. If we print the content of this file we can see its format.
The content starts with ssh-rsa that indicates that it’s a RSA key following a long string of characters that make up the public key.
At the end it follows the system user and system hostname of the computer that generated the keys. The last part, the user and hostname, is just for identification purposes and can be altered without affecting the key function.
Checking the SSH Key Fingerprint
The SSH key fingerprint can be checked with the following command.
ssh-keygen -l -f ./id_rsa.pub
Make sure to input the
-l option to indicate that we want to show the fingerprint of the key file and not generate a new one.
It will print the bit size of the key, followed by the key fingerprint, the system user and hostname and type of algorithm used.
This is how we check what type of keys we have on our system.
The Private Key
The other file created was the id_rsa file.
This here is the most important file that you must guard.
If someone were to access this file they would get access to all the connections it can login to.
For the purpose of demonstration I will show you how a private key looks but this should never be done.
It shows a file with a long string of characters created with the RSA algorithm.
-----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAACmFlczI1Ni1jdHIAAAAGYmNyeXB0AAAAGAAAABBScuqX1a euFTqDqC34sHwWAAAAEAAAAAEAAAIXAAAAB3NzaC1yc2EAAAADAQABAAACAQDf4lXBSopk r3qclD09t6HlEB7n7dxDyBQkpoLtJxVL1+BT0CiZ+J3uzarZT6rQXU5Dq/aPSp4D7YrFK9 9+GnrQMp67MQnFUjLiZ3T4pXkhBzUsBC0uiFfMwf9i/diBoTUKtXgYsKjb9KOLzw97cGFi sRv8Z9BLVfB60og5hjSM2ih4eioG1Yrxpxyb7dFywPWpnYr/zg1Gqlo1MaBrb0MrUCSyrD 9XPRBanQaafw0WshmAK0svNR8l8cmsX21gjE4rjzzImQeUe1P/wPt0poABV3JTNa+dal6+ TtByyYqyIh81aOK17A66SHHKBfpJu1A/JU5CM//lMJAW+RYKVI4fDaPezR/aIsq4u8ujVe xasfEV0RkyV9KJFmziSAedXo5D1UXZ6lgumODUJdCjiSxKBe8Brl6zq19DmA4v4+6P3FLM w/17lNcqf5+JxLhSqArqEc2NakTmvqcLgZ8KysSNAXwDOilOB3q1VZfIaEupXb8uF1qbi0 rjLHqyZFYjCYw4emcZWYO7UkDLdKuGeXrA1BFI/xHL/8xEI1gbUXTUwijXxzCFf8BPnlm+ Qu5Jyj6YFCuDA/8ufyONVO5vfAW8V9qgTWaif/6S+6ShH6wFrPEjy0R9q+D5gG79j5NcUK BEsmn8xtzsibmNQtmeaGsGIlK3bJrecS/rr+F0ilW+EwAAB0CcxkWaYUJkOBDKgId4UWWW v2jhlymC/mpijyoy2jbxcW2GYIqEr8+YDrEB3FzGNFq5nOlgkqYELM5Vdeg1NxoDF5amOu 2kF15Bu0mUSjtXJyYmpTk8yUVJp601OzLWhhT6GDIx/PGD/DqwpMyqJV1hDSv8ENrnHbtf sUXRA1qIzNv5Dct2AnEM2h0jTAEH4NSFYz8f5+w65fNkfUQh2GA6Ka/tjvhrE9/81I4HNh x3b/g3yse82tYDvvzjPqL+3qASjuwkTl24vL92RzEga2GoJ6YvgCWYyPCfgK5nswKIMi6Y hgIjV0+6VkvBgl/vF4jIv+RppoRTBt5zkzSfETw3gbTfMYUpnYksrqzjPZY2+mdvB0wq+T CBmA4ToST0bVv7WP+OzhHf72ZfNsgBhUh6qK4CZl9iyrwuuGIObW78yV4GqrEoD0lRijkZ kDZAlx0X3wfj7Ex20QgMAd1sFMDCfpdJeuNnOBd9lXHkLkNTnycHRPBz0oU29Kuj1tx+Cl EfDNAL/Y7+ZU0HOBbsUoPABOG7K2hlryzeyyVpey8B9Z1WX04vBXmL6nZOsydxHgcYgnpp xuGfjEWe0I9iDYZGbFT2ulM0ZeF1Q6fa57jEioSyFwOTvTHIMcZUVss7T5k+PetAQDKxRU bsnAdnN8zl5LcXl0gCI1pwNxlQDcDLDL0eIX13KvtmpHe/IbwxoW8rKBWU3KFlT9zxgVwb AZfNRkKp17pUNCipSya6eaUUrLES3AsSwLAdtgK30U0i73mzWyw8i+TNYFarJctun2ccf4 RcOmqlroa2fkVbH0iHlHXLoa0h18yQhYI7NBUPKSQULi0bRyUpMtnxwoceTP8rvEIyM5W7 XAOPnEkTplpK48HzszkCi+IdNqkDb2r7QhUKm3XeLlGuOBCQuhr2ovB/Z59kJ5821n2L9G GFp2kMIF1uir8D81SxrAmwshT0sdYZ+m0z5QLu9IHRcLwUdZxKjScp3xUEtudrJePwKDWi YysUJWjssSuowvvNI5KmBJjT9Mjx73ZOyOH1sKESGxM7ZBytp+JNpCm3VlUzKGy+0gxE5x S7N7nstM4dcI4tasTC1z5v2tOBgrQXKHoInYRPWPTahVKqumC3i9DMalWDIxS4R9IOEpEf wrf0wDSG/gRZ23R+rZOyW3McmV4OA6dDQu/o4TfIEuv9xUYWG0mOPni6GSm5pEV0ijyaH4 lPDjhIiW73zBDe28hALiXcHbrFBjLal7OWjMkPkYHxSsd7UVhbUANVbs2AEXcPcTPNAyrP La9nxEOPik++gHEgM/Hhnld42BaI8h0RsNmdwLH86EtkhbewKUvV5jiYtFIFylFLAzYwCt FvCcVmZoh5fWWJ/6IuM7forWUVC7g1KKbw6RCBLd3zvMy8ZB1tE569EzoY3BpawkzuvMyw G8w+BycCkXujSDAzliZnPxHvL6g8MJFcqm9VAPKsiFIkkm/kziUDlF6c+UaEEYkTgQt8AD ZMloc1iooq9XgR8hKWILJaqAdTt+s9HHfvCScwOLjuJo6I8Zp1NjcUd8EShkKrgvNu7iLW bS5eV2xztKzBH3i5MbJvSCe1Q57rawgk14AKw5Be6/eCzL6NLNmEUZICkCE2SbMN7lXpSg AddNi+C5+c76/2CpAQEhYWdnq7p5Js/N2VrzT7ZIcsloVb/ATiY/gugVSXC8wTS8R8NjFg sG+IV11rhcYX/LQAxv55xZVfzi3jdzJZPZC6u1w1b4bNFY5kyXWplJxE4BfpKkQKrdVfiY xqW477AGW9JH7OtDky5984x8ESVB8pvREDPDvdaVxtnmbl5KwVxUUcnGseNWw9a05sI9bq M0C4oMqMIrP4sk5bayG8i2tH0ZHi9rULrKNuXT1RKBaXM8aOSKL83lcuAokU/FkEg1nHAF oIy/VAhrK1dQbjcMWueGmT3LkCeeGvJeW4XFe8eTWt9ZhdcEswKREnVeImO2Vz9+rS1FVK WBTX/3k2qGx7lVarcxaW+z4Sj6Qln3WqCsYooFkxZqPzE4jn+x0Q5PXBZ4HCLZMPUD7vdf 5K4u0P7T0w4fDj2CAUd6s/IdKiGx5AeeKJYmV+Tiqub6D6Q2o1hKSEEQVFNT/t5JNzXNYs LIfWzx0MY2vsPf3mU7rguJz7Q8JEQksDkBw04CQApusPvGhgthUnf2qEL7qH3//rCFrrKM 5XNAv2djMeWhgHMzhJz1dujZPNqFATSXLD3C3+t/idj310HiKERCLyQJn4MOJ/15KMrE4p ek0AwLvZnA0OahqCw+L8CF1+vNFuW7OZ9NcbBCwhj5PZLvf/GKYCmBqQdOmY0RzMbva/2H IOPIUPyv4e/A4j6g50jH1Vno4UwmXaQVJVK0ie4CR+RjcgEUWqMUWrju4CD2fFjIfGkj5v J2/DgbUcyQp14tuVccvLsaiBBjy8eJF1kw8FS/KK5oppAz2eOohWMZHX2edNlNL7HkP8Jy C3hQ== -----END OPENSSH PRIVATE KEY-----
I will stress one more time that you must never publicly share your private key.
The public key is fine to spread around on servers and if it were to leak publicly online there wouldn’t be a problem.
But if your private key gets leaked online it is considered unsafe, and it’s time to generate a new one and update all of the servers as fast as possible.
Generating SSH keys – ed25519
Talking about generating keys, let’s create another one.
This time let’s create an ed25519 key. For most part this is the most recommended key algorithm to use nowadays.
Unless you have specific needs to access legacy systems where openssh hasn’t been updated in a long time, using the ed25519 algorithm is the way to go.
ssh-keygen -t ed25519
Again the process is identical like when we created our RSA key:
- It asks us for a key name, we left it empty to use the default one, which will be id_rsa for the private key, and id_rsa.pub for the public key.
- It asks us for a passphrase and we give it one.
In the above demonstration by listing we can see the two new files created in our .ssh directory, id_ed25519 and id_ed25519.pub. With the ssh-keygen utility we can verify its fingerprint and the type of key it is.
Quick Note on RSA 4096 vs. Ed25519
Furthermore we discover something interesting about the ed25519 keys.
By printing the content of the ed25519.pub public key file we notice that the key size is a lot smaller. Compare below the two public keys.
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINokoj43W40RhLRIhYJqM350sUI8LA6ElCmb9V+BPJ3d [email protected]
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDf4lXBSopkr3qclD09t6HlEB7n7dxDyBQkpoLtJxVL1+BT0CiZ+J3uzarZT6rQXU5Dq/aPSp4D7YrFK99+GnrQMp67MQnFUjLiZ3T4pXkhBzUsBC0uiFfMwf9i/diBoTUKtXgYsKjb9KOLzw97cGFisRv8Z9BLVfB60og5hjSM2ih4eioG1Yrxpxyb7dFywPWpnYr/zg1Gqlo1MaBrb0MrUCSyrD9XPRBanQaafw0WshmAK0svNR8l8cmsX21gjE4rjzzImQeUe1P/wPt0poABV3JTNa+dal6+TtByyYqyIh81aOK17A66SHHKBfpJu1A/JU5CM//lMJAW+RYKVI4fDaPezR/aIsq4u8ujVexasfEV0RkyV9KJFmziSAedXo5D1UXZ6lgumODUJdCjiSxKBe8Brl6zq19DmA4v4+6P3FLMw/17lNcqf5+JxLhSqArqEc2NakTmvqcLgZ8KysSNAXwDOilOB3q1VZfIaEupXb8uF1qbi0rjLHqyZFYjCYw4emcZWYO7UkDLdKuGeXrA1BFI/xHL/8xEI1gbUXTUwijXxzCFf8BPnlm+Qu5Jyj6YFCuDA/8ufyONVO5vfAW8V9qgTWaif/6S+6ShH6wFrPEjy0R9q+D5gG79j5NcUKBEsmn8xtzsibmNQtmeaGsGIlK3bJrecS/rr+F0ilW+Ew== [email protected]
The ed25519 public key is a lot smaller.
And we saw before how big the RSA private key was, compared with the size of the ed25519 private key.
-----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAACmFlczI1Ni1jdHIAAAAGYmNyeXB0AAAAGAAAABCt58afYM JKRWUwL7fdrlI6AAAAEAAAAAEAAAAzAAAAC3NzaC1lZDI1NTE5AAAAINokoj43W40RhLRI hYJqM350sUI8LA6ElCmb9V+BPJ3dAAAAkDI/41TSWGfbcd+KIpGZ4P6zxOAdXQxQYnVqdF SBVMJL2ODAssd4pY7AvihYLqc+D+IXusH/dFNtm2eX33bd8STIK8p6Vlm/ktmplxL67gxt jrR9dcer/q2I4NCW7dZZxx4/Xefj90dMEmEQmEBpLZybs3G+pFeFkgz6Oz5IJc846+FwzA CQeDewz/r/dWE5ww== -----END OPENSSH PRIVATE KEY-----
The ed25519 keys can be much shorter and give you the same security level because the mathematical problem they are based on is much more complex.
Setting up Passwordless SSH Login
Now that we have two sets of SSH keys, using two different algorithms, we can start using them on our servers. The next thing to do is to copy the public key (id_rsa.pub, or whatever you named your .pub key) to the server.
While that may seem smart it’s not really recommended. As long as you have proper security hygiene with your keys, one or two pairs is enough.
With another openssh utility named ssh-copy-id we’ll copy our public key to the root system user at the server 18.104.22.168.
ssh-copy-idis a command for copying your public key to a remote server. It is a helper command used to copy the local user’s public key to a remote server’s authorized_keys file.
It will append your public key to the remote server’s ~/.ssh/authorized_keys file. authorized_keys is a file in the .ssh directory of the user’s home directory on the server that lists the public keys that can be used for logging into the user’s account.
ssh-copy-id [email protected]
It asked us what was the password of the root user so the utility could login and install the public key on the root system user’s authorized_keys file on the server.
If we wanted to copy only one of the keys we specify which one with the
-i option providing the location of the public key file of the key pair we want to add.
ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]
Login Using Your SSH Keys
Now that our public keys are copied to the server we can connect to them using a simple ssh login.
This time we are logging in to our server with the root user but this time it’s not asking us for the server user’s password.
It simply let us through because both machines, the server and our computer established a cryptographic symmetric connection.
And like that we login to SSH passwordless.
It’s important to note that we also set up a passphrase for our SSH keys, but we weren’t asked to enter it.
The default behavior when connecting with keys is for the ssh utility to ask us for the passphrase of the key on every use.
While our example didn’t ask us for it, that is because there are lots of utilities throughout all the Linux distributions that can handle the ssh keys login passphrase for us.
There are too many distributions and utilities that handle this behavior that it’s too many to go one by one.
Some people are against using this type of utilities but in general it’s considered a good balance to secure the key with a passphrase and unlock it automatically when login into our computers.
That way if the computer gets lost or stolen the keys won’t be compromised as long as the computer user is set up with a password.
Passwordless SSH Login In The SSH Config File
There’s an even easier way for us to login to our servers using our passphrase unlocked keys.
If we add our server connection info in an stanza with this format in the SSH config file:
Host larrycurlymoe HostName 22.214.171.124 Port 22 User root IdentityFile ~/.ssh/id_rsa
We can direct
ssh to use this connection information by invoking the connection with the Host portion.
See how easy it was to login to our server? Simply invoking it with the Host nickname we gave it in the config file let us login automatically.
This setup we saw in the last demonstration is beautiful because we are using a highly secure method to connect to our servers in an easy convenient manner.
We are using the cryptographic keys to establish an encrypted connection.
We are using a passphrase to secure our keys on our machine. The passphrase is unlocked when we login to our computer’s user. And we are using the SSH config file to nickname our connections to make our admin life easier.
This method is the highly secure way most of the professional system administrators login and manage their server fleet.
While at the enterprise level there are even more secure and audited methods, the way demonstrated here in this tutorial can be considered good enough for production use. So start using SSH keys and start forgetting about passwords.