It’s something you already use in real life. SSH uses the concepts of public key and private key. Will explain these below.

Here is the public key you use in real life:

Ok, it’s a lock. But in the context of SSH, the public key serves a similar purpose. It’s a “lock for your server”.

We might have a tendency to think these locks are private… but actually, they’re quite public! Anyone passing by our doors can access them. Anyone could insert their own keys and see if they work.

And the private key is much easier to understand:

You carry it around in your pocket. So it’s definitely private. Well, as long as you keep it in your pocket. If someone steals it from you, they can access your lock (public key). Something that can happen with a private SSH key as well. As it’s just a file on your computer. If someone steals your file… they can access your server. Unless that file is encrypted with a password.

So, back to SSH, you have the same pair: a public key (lock) and a private key. Here are the typical steps you go through to secure a server with SSH keys:

1. On your own computer, you generate an SSH key pair. This contains two parts: the private key and the public key.
2. You copy the public key to a remote server. It’s basically like installing a lock on that server. A lock that can only be unlocked by the corresponding private key.
3. You disable password logins.
4. Now you’re the only one that can log in through SSH. Since you have the private key on your computer that matches the public key (lock) you put on the server. With your private key you basically “unlock” the SSH session.

Pretty cool, right?

But why can’t we just use passwords? A couple of advantages:

• With the private key on our computer, we don’t need to type a password to log in. We just point our SSH client (program that logs in to the server) to the private key it has to use. Which means now we can also automate stuff. We can set up programs to automatically log in through SSH, backup some things to our computer, then log out.
• Private keys are incredibly complex. There’s no way someone can “guess” our private key, like it can happen with passwords. (Although, there will be a way to do this when quantum computers get stronger. But by then, we will use other algorithms which will be “quantum resistant”.)
• Another interesting use case. Imagine you have an username on your server. For example, the username “developers”. And you want to allow 5 people in your team to log in and update your website. Now how do you let all of them log in? Normally, what you can do is set a password for the “developers” user. Now you have to share this password with 5 people. Rather inconvenient. And what if one person leaves the team? How do you make sure they can’t log in anymore? You have to change the password for the “developers” username. Now 4 people have to start using a different password. But with SSH keys this is much more elegant. Each developer can generate their own private/public keys. And then you add 5 public keys, for each developer, to the server; to allow logins to the “developers” user. Each developer uses their personal private key to log in. So they don’t have to share anything with each other. And when you want to disallow logins for someone for security reasons, you just remove the public key of that person from your server.

And public/private key pairs have many other interesting use cases as well, for encryption, decryption, and cryptographic signatures (digital proof the owner of the private key did something).

Even websites are trying to migrate away from passwords, to something called passkeys. Which work in a similar way to the key pairs we discussed here.

I hope SSH keys are easier to understand now. Use them. You’ll see in practice that they’re a bit more convenient than passwords.