Understanding through Analogy - SSH

Hey everyone! As software engineers, we live in our terminal, and a huge part of the day involves connecting to remote servers—whether it's for deploying code, managing a database, or just poking around on a cloud instance. The technology that makes all of this possible and, more importantly, secure, is SSH.

As someone who uses SSH almost daily, I often found myself wondering: “How does it actually work?”, “What exactly are these keys I’m generating?”, and “Why am I sharing them?”

To get a better handle on it, I came up with a simple analogy that I've shared with countless peers and junior developers since. If you've always wanted to have a mental model of what’s happening under the hood when you type ssh user@hostname, this one's for you.

The goal of this article is to build a simple mental model for understanding SSH. We won't be doing a technical deep-dive into the protocol itself, but rather focusing on the core concepts. This way, the next time you hear "SSH," you'll have a clear picture of what's happening and the key components involved.

---

The Bank, The Lock, and The Key 🏦

Imagine you have a high-security bank vault where you store your most valuable asset—let's say, your life's savings in gold. This bank is the resource server (or just server) you want to access.

You (The User) <---- ( The Secure Tunnel: SSH ) ----> The Bank (The Server)

Now, this bank has a peculiar rule: it provides you with a place to keep your belongings, but doesn't provide its own locks. To secure your vault, you must bring your own lock and give it to them.

This lock you provide is your public key.

You hand this lock to the bank manager, who places it on your vault door. The great thing about this lock is that anyone can see it. You could even make copies of the lock and give them to multiple banks where you have vaults. It's "public" information because all it can do is lock the vault. It can't open it.

So, how do you get your gold?

When you need to access your vault, the bank requires proof that you are the legitimate owner of the lock on the door. This is where your private key comes into play. Since you created the lock, only you, have the unique, secret key that can open that specific lock.

You show up, present your private key, the lock clicks open, and the bank grants you access. You never give your key to the bank; you simply use it to prove your identity.

This is the core principle of SSH security. It creates a trust relationship based on this lock-and-key mechanism, ensuring that no one can get into your server without your specific private key.

---

Connecting the Analogy to Technology

Let's swap out the allegorical terms for the real ones:

• The Bank: This is the remote server you want to connect to (e.g., a GitHub repo, an AWS EC2 instance, your company's production server).

• The Lock: This is your public key. It's stored on the server and is used to encrypt challenges sent to you.

• The Key: This is your private key. It's stored securely on your local machine and is used to decrypt the server's challenge, proving your identity.

---

How the Secure Connection Happens

Underneath the hood, SSH (secure-shell protocol) works in a few distinct steps, all built on top of TCP/IP, which is the basic communication language of the internet. Think of it as a set of steps that lets computers exchange information reliably.

The SSH process is layered, with each layer handling a specific job:

1. The Transport Layer (Setting up the Secure Tunnel): First, the machine and the server establish a secure, encrypted channel. This layer handles the initial "handshake," where both sides agree on encryption standards and the server proves its identity to you.

2. The User Authentication Layer (Proving You're You): Once the tunnel is secure, it's your turn to prove who you are to the server. This is where the lock and key analogy fits in. The server uses your public key to issue a challenge that only your private key can solve, confirming your identity without ever exposing your private key. (The details of how this works deserve a full blog post of their own).

3. The Connection Layer (Getting to Work): After you're authenticated, this layer takes over. It lets you run multiple activities—like a command-line shell, file transfers (SFTP), or other connections—all through that single, secure tunnel.

---

Creating Your Keys with ssh-keygen

So, how do you create this digital lock and key pair? You use a simple command-line tool called ssh-keygen. When you run ssh-keygen in your terminal, it generates two files, typically in a hidden .ssh directory in your home folder:

1. id_rsa or <keyname> : This is your private key. Treat it like your house keys or your passwords. It should never, ever leave your machine or be shared with anyone.

2. id_rsa.pub or <keyname>.pub: This is your public key. This is the "lock" you can safely share. You'll copy the contents of this file and give it to any server you want to access. On most servers, you'll place it in a file at ~/.ssh/authorized_keys.

The ssh-keygen command has other flag values like:

• -f : Specifying a file for the key (useful for giving a custom name)

• -t : Specify the encryption (rsa, ed25519 etc.)

• -C : Comment (add additional tags/comments to the key). Generally used for emails.

A sample template command that will be used multiple times can look something like (Assuming the example of an SSH key for Github):

ssh-keygen -t ed25519 -f ~/.ssh/personal-github -C test@email.com

Managing Multiple Keys with ssh-add

What if you have multiple keys? For instance, you might use one key pair for your personal projects on GitHub and a different one for your work environment. This is where ssh-add becomes incredibly useful.

The ssh-add command adds your private key's identity to the SSH authentication agent. This agent keeps track of your keys and automatically provides the correct one when you try to connect to a server. This saves you from having to manually specify which key to use for which host. You can configure this in your ~/.ssh/config file to create seamless connections to different environments.

---

Conclusion

By understanding this simple analogy of a lock you provide to the bank and the secret key you keep for yourself, you can better appreciate and understand this ubiquitous protocol.

I hope this little story helps demystify SSH for you and you have a mental model whenever you use it.