SSH (Secure Shell)

2025-10-31

The Developer's Magic Wand: An Everything Guide to SSH

Tags: SSH, DevOps, Security, Networking, Tutorial, SysAdmin

If you're in tech, you've typed it. It's the go-to command for... well, "going" somewhere else.

ssh your_username@some.server.ip

You hit enter, maybe type a password, and poof—your terminal prompt changes. You're no longer on your laptop. You're commanding a server hundreds of miles away. But what is this? A magic spell? A Star Trek transporter for your command line?

Close. It's SSH (Secure Shell), and it's one of the most important, powerful, and misunderstood tools in modern computing. If you've ever used Git, deployed a website, or managed a cloud server, you've been the beneficiary of this 30-year-old protocol.

The problem is, most of us just use it. We treat it like a magic wand without knowing how it works. When it breaks, or when we see that BIG SCARY "REMOTE HOST IDENTIFICATION HAS CHANGED" warning, we panic and ask Stack Overflow what to do.

Today, that ends. By the time you finish this, you won't just use SSH; you'll understand it.

What Problem Does SSH Solve?

To understand SSH, you have to know what came before it: Telnet.

In the old days, when you wanted to remotely connect to another computer, you used Telnet. The problem? Telnet was built in an era of trust. It sent everything in plain text. Your username, your password, every command you typed—all of it was visible to anyone "sniffing" the network.

This is, to put it mildly, bad.

SSH was created in 1995 to be the "Secure" Shell. Its job is to provide three non-negotiable guarantees for your connection:

  1. Encryption (Confidentiality): No one can eavesdrop on your session. Your password and the data you send are scrambled and unreadable to outsiders.
  2. Authentication (Legitimacy): It proves that the server you're connecting to is who it claims to be (preventing "man-in-the-middle" attacks) and that the user (you) is who you claim to be.
  3. Integrity: It ensures that the data you send and receive hasn't been tampered with or corrupted in transit.

The Core Concept: A Tale of Three Cryptographies

SSH isn't one single technology; it's a clever combination of three different cryptographic techniques, each used for a specific job.

1. Asymmetric Encryption (Public/Private Keys)

  • What it is: A system that uses a pair of keys: a public key (which you can share with anyone) and a private key (which you never, ever share).
  • How it works: Data encrypted with the public key can only be decrypted by the matching private key.
  • Analogy: The public key is an open padlock. You can give copies of this padlock to anyone. They can use it to lock a box, but only you, with the one-and-only private key, can open it.
  • SSH Use: Used during the initial handshake to prove identity and securely exchange the secret for the next step. It's slow, so it's not used for the whole session.

2. Symmetric Encryption (Shared Secret Key)

  • What it is: A system that uses a single, shared key to both encrypt and decrypt data.
  • How it works: You and the server agree on a secret password (the "session key"). You use this key to scramble your message, and the server uses the exact same key to unscramble it.
  • Analogy: A secret decoder ring. As long as both you and your friend have the same ring, you can pass coded messages back and forth. It's very fast, but the main challenge is: how do you safely give your friend the decoder ring in the first place?
  • SSH Use: Used to encrypt the entire session after the initial handshake. It's fast and efficient.

3. Hashing

  • What it is: A one-way function that takes any amount of data and produces a unique, fixed-length "fingerprint" called a hash.
  • How it works: If even one bit of the data changes, the resulting hash will be completely different. It's impossible to go from the hash back to the original data.
  • Analogy: A digital wax seal on a letter. When the letter arrives, you check if the seal is unbroken. SSH uses this (in a form called HMAC - Hash-based Message Authentication Code) to ensure every packet of data is exactly as it was when it was sent.
  • SSH Use: Used for data integrity.

So, to summarize: Asymmetric encryption starts the connection, Symmetric encryption protects the connection, and Hashing verifies the connection.

The "How": Deconstructing the SSH Handshake

This is the magic. When you type ssh user@host and hit enter, all of this happens in milliseconds.

The Goal: The client and server need to safely verify each other's identity and generate a temporary, shared symmetric session key to encrypt the rest of the conversation.

Here's the play-by-play:

  1. Client Connects: Your computer opens a TCP connection to the server, typically on port 22.
  2. Version Negotiation: The client and server send text banners to each other. "Hi, I'm SSH-2.0-OpenSSH_8.9." "Hi, I'm SSH-2.0-OpenSSH_8.2." They agree to use the newest protocol (SSH-2) they both support.
  3. Algorithm Negotiation: They exchange a list of all the symmetric ciphers (e.g., aes256-gcm), key exchange algorithms (e.g., diffie-hellman-group-exchange-sha256), and hashing algorithms (e.g., hmac-sha2-256) they support. They pick the first one they both have in common.
  4. Host Authentication (The known_hosts part!)
    • This is CRITICAL. The server needs to prove to you that it's the right server.
    • The server sends its public host key (a public/private key pair generated when SSH was installed on the server).
    • Your client checks its ~/.ssh/known_hosts file for this key.
    • If the key is NOT in the file: This is your first time connecting. SSH shows you the "authenticity of host can't be established" warning. When you type yes, you are saving this server's public key for next time.
    • If the key IS in the file and MATCHES: Perfect. The server is who it says it is.
    • If the key IS in the file and DOES NOT MATCH: 🚨 RED ALERT! 🚨 This is the "REMOTE HOST IDENTIFICATION HAS CHANGED" error. It means either the server was re-installed (innocent) or a hacker is performing a Man-in-the-Middle (MITM) attack by pretending to be your server (malicious). SSH aborts the connection to protect you.
  5. Session Key Generation (Diffie-Hellman Key Exchange)
    • Now that the server is trusted, both sides need to create that symmetric session key.
    • They use a brilliant algorithm called Diffie-Hellman.
    • In simple terms, they exchange some public numbers, do some private math, and both independently arrive at the exact same secret number.
    • This secret number becomes the session key. A snooper, seeing only the public numbers, cannot calculate the secret.
    • The tunnel is now 100% encrypted! Everything from this point on is scrambled using this one-time-use session key.

"Okay, I'm In." — No, You're Not. Now You Authenticate.

The tunnel is secure, but the server has no idea who you are. Now it's your turn to prove your identity. This happens inside the encrypted tunnel.

Method 1: Password Authentication (The Simple Way)

This is easy. The server just asks for your user's password. You type it, it gets sent through the encrypted tunnel, the server checks it, and lets you in. Secure, but clunky.

Method 2: Public Key Authentication (The Right Way)

This is the standard for all automated systems (like Git) and professional developers. It's the reverse of Host Authentication.

  1. Preparation (You do this once):

    • On your local machine, you run ssh-keygen.
    • This creates your own key pair: ~/.ssh/id_rsa (your PRIVATE key - guard this with your life!) and ~/.ssh/id_rsa.pub (your PUBLIC key - you can share this).
    • You copy the contents of your public key (id_rsa.pub) and paste it into a file on the server at ~/.ssh/authorized_keys. This file is just a list of all public keys that are allowed to log in as you.

  2. The Authentication Flow (Happens every time):

    • Server: "Okay, I see your public key id_rsa.pub is in my authorized_keys file. Prove you own the matching private key."
    • Server: "I'm generating a random, one-time-use message. I'm encrypting it with your public key. Here, catch."
    • Client (You): Your machine receives this scrambled message. The only thing in the world that can decrypt it is your private key (id_rsa).
    • Client (You): Your SSH client uses id_rsa to decrypt the message, revealing the original random text. It then hashes this text and sends the hash back to the server.
    • Server: "That's the exact hash for the message I sent. You must have the private key. Welcome."

You're in. And you never typed a password. This is how GitHub authenticates your git push commands.

The "Protocols": A (Brief) Look at SSH's Layers

The SSH protocol itself is layered, just like the internet. This is what makes it so flexible.

  • The Transport Layer (SSH-TRANS): This is the foundation. Its job is to handle the initial key exchange, server authentication, and set up the symmetric encryption. It provides the secure, encrypted pipe.
  • The Authentication Layer (SSH-AUTH): This layer runs on top of the transport layer. Its only job is to handle user authentication (the password or public key dance we just discussed).
  • The Connection Layer (SSH-CONN): This layer runs on top of the auth layer. It's what lets you have multiple channels inside your single SSH connection. Ever run a shell, forward a port, and transfer a file all at the same time? That's the connection layer managing "channels."

The "Uses": SSH is More Than a Shell

SSH is a secure pipe. You can put (almost) anything through it.

1. Secure File Transfer (SFTP & SCP)

  • SFTP (SSH File Transfer Protocol): A robust protocol that runs over SSH. It's what graphical clients like FileZilla and Cyberduck use. It's a full-fledged file management system (list, delete, move, etc.).
  • SCP (Secure Copy): A simple command-line tool for quickly copying a file. It's just cp (copy) over SSH. scp /local/path/file.txt user@host:/remote/path/

2. The Superpower: Port Forwarding (Tunneling) 🚇

This is the coolest thing SSH can do. It lets you "forward" network traffic from one place to another through your secure tunnel.

  • Local Port Forwarding (-L)

    • Use Case: Your company database is on a server (db.internal) but is firewalled from the internet. You can only access it from your "bastion" (jump) server (jump.company.com).
    • Command: ssh -L 8080:db.internal:5432 user@jump.company.com
    • What it does: It opens a port 8080 on your laptop. When you connect to localhost:8080, SSH securely tunnels that traffic to jump.company.com, which then forwards it to db.internal:5432. You can now point your local database tool at localhost:8080 and securely access the remote database!

  • Remote Port Forwarding (-R)

    • Use Case: You are building a web app on your laptop (localhost:3000) and want to show it to a colleague. But your laptop is behind a firewall.
    • Command: ssh -R 9090:localhost:3000 user@your-public-server.com
    • What it does: It opens a port 9090 on the remote server. When anyone visits your-public-server.com:9090, SSH securely tunnels that traffic backwards to your laptop's localhost:3000. You just safely exposed your local dev server to the internet.

3. The Pro Tip: Your ~/.ssh/config File

Tired of remembering IPs, usernames, and which key to use? The SSH config file is your best friend.

Instead of this: ssh -i ~/.ssh/my_aws_key.pem -p 2222 ec2-user@12.34.56.78

You just add this to ~/.ssh/config:

Host my-aws-server
    HostName 12.34.56.78
    User ec2-user
    Port 2222
    IdentityFile ~/.ssh/my_aws_key.pem

And now, all you ever have to type is: ssh my-aws-server

Conclusion

SSH is the unsung hero of the developer world. It's a masterpiece of practical cryptography—a layered, flexible, and robust protocol that turned the insecure, plain-text internet of the 90s into a platform where we can securely manage billions of dollars of infrastructure.

It's not magic. It's just really, really good engineering.

← Back to blog