Time is a fluid concept these days, but approximately 25 years or one week ago, I wrote about SSH and what is it good for.1 The bottom line is that SSH itself is very simple, and there’s not a lot of exciting dramatization that can be produced around its actual use unless you’re really into weird incantations like “ss -pant | grep ‘ESTAB’”. And let’s face it, no one is. You do have to enjoy the fact that we can shove the word “pant” into a perfectly valid Unix command though.
However, there is something directly related to SSH that we should talk about, primarily because it will give me an excuse to write exactly 255 posts about it, and that is the topic of SSH keys.
When you think of a key, you probably think of something that unlocks something else, and that’s exactly what SSH keys are used for. Although SSH keys are cryptographic, they do not exist for the purpose of encrypting your SSH session. I think this is a source of confusion for some people, because if they’re familiar with public key cryptography, they’re used to it being used to encrypt and decrypt messages (as well as sign them, but that’s another topic).
SSH keys are used for authentication. They’re used to prove to the server or host that you are connecting to that you are who you say you are. If it sounds like a slightly different form of password, you’re not wrong.
SSH keys are a form of public key cryptography, also known as asymmetric cryptography. These names are apt because SSH keys are a key pair with a public key and a private key (hence the public key nomenclature). The public key is used to encrypt information, and the private key is used to decrypt information (hence the asymmetric label).
I realize that I just got done saying that SSH keys are used for authentication, not for encrypting an SSH session, and then I immediately turned around and said they ARE used for encrypting and decrypting information.
Both are true. Here’s how it works:
SSH key authentication overview
- The server has a copy of your public key.
- You have your private key, carefully guarded on your computer or iPad or papyrus scroll or whatever.
- When you SSH to the server, it looks to see if there’s an SSH key associated with the identity you are logging in as.
- If so, it uses that public key to encrypt a secret message that it sends back to you.
- Your computer looks for an SSH key associated with the identity you are logging in as.
- If your computer has the matching key, it uses the private key to decrypt the secret message.
- Your computer sends the decrypted message back to the server as proof that it holds the private key matching the public key that the server encrypted it with.
- The server sees the decrypted message, verifies that it matches, and assumes that you’re who you claim to be based on the fact that you have the private key that matches your public key.
It sounds a little convoluted, so let’s take all that out of bullet point format and restate it in a simple paragraph:
The server encrypts a message using your public key and you decrypt it using your private key.
It’s really that simple. The fact that you can decrypt something encrypted with your public key proves to the server’s satisfaction that you are you, because you are in possession of your own private key.
Yes, it’s possible that someone got your private key due to some 1337 hacking skills on their part or terrible key management on yours, but the server can’t know this and if you’ve managed your keys properly, it’s a good assumption that you really are you. So that’s how it works.
There’s an element of trust involved – the server trusts that you’ve taken good care of your private key. This is really no different than every account on the internet you log into assuming that you have a good password and have taken care of that too, with one key2 difference: your private key is in a text file stored on your device, and you need to guard it carefully. We’ll talk about the details of how to do that another day.
Once all that crazy authentication is done and you’ve justified your existence to your extremely judgmental server, the real SSH fun can begin. The actual SSH session itself is encrypted using symmetric keys (the same key on both sides) and you can clickety-clack out your Unix-y world domination commands in peace.3
Next time: SSH key generation and setup. You won’t want to miss it. We’re going to type out some actual Unix commands, just like Mr Robot except without all the psychological anguish and drug addiction.