Tullup Blog

What is SSH and how do I actually use it

Thor Odinson··8 min read·fundamentals, infrastructure, security

If you've followed a developer tutorial in the last twenty years, you've seen the letters SSH. Most guides drop it in like everyone already knows what it is. They don't. SSH is one of those tools whose ubiquity has made it invisible — used by everyone, explained by almost no one. So here's the explanation that should have come before the first command they told you to run.

What SSH actually is

SSH stands for Secure Shell. The shell part is the same shell you type into when you open Terminal or PowerShell — a program that takes lines of text from you and runs them. The secure part means SSH wraps that shell with strong, modern encryption so that everything you type and everything the computer says back is unreadable to anyone watching the wire between you.

The practical use case: you have a computer in front of you (your laptop), and there is another computer somewhere else (a cloud server, a Raspberry Pi at home, a router, a teammate's machine). SSH is the bridge. After you connect, your terminal window is no longer talking to your laptop — it's talking to the other machine. Commands you type run there. Output you see comes from there.

This is unglamorous and it is everywhere. Anyone who runs production infrastructure uses SSH every week. Anyone who runs a personal server uses it every day. AWS, Google Cloud, Linode, DigitalOcean — every cloud provider expects you to use SSH to manage your virtual machines. The skill compounds.

Why a keypair beats a password

For decades, the way to log into a remote computer was the same as logging into your own: type a username, type a password. That model has aged badly. Passwords get stolen, guessed, or brute-forced. Once an attacker has the password, they're you. Worse, you typically have one password reused across many machines, so a single leak compromises everything.

SSH replaces this with public-key cryptography, and it's worth understanding the model in one paragraph because it explains a lot of what you'll see when you run the commands.

You generate two files on your laptop: a private key and a public key. They are mathematically related, but you can't derive the private key from the public key. You keep the private key on your laptop forever — it never leaves, you never email it, you never paste it into a chat. The public key is meant to be shared; you copy it to every server you want to log into. When you try to connect, the server sends your laptop a math puzzle that only the private key can solve. Your laptop solves it locally and sends back the proof. The server checks the proof using its copy of the public key.

The server has no idea what your private key actually is. The wire between you and the server never carries your private key. Even if every byte of the connection was intercepted, the attacker would have only a proof of identity that was generated for that exact session and that exact challenge — useless for anything else.

That's why a stolen password is a disaster but a stolen public key is harmless. The public key is meant to be public.

The three commands you actually run

Here's the practical flow. You'll use these three commands more than any others in your SSH life.

Generate the keypair

ssh-keygen -t ed25519 -C "you@example.com"

ssh-keygen makes the pair. The flags:

  • -t ed25519 picks the algorithm. Ed25519 is modern, fast, and short. Don't use the old rsa default unless you have a specific compatibility reason.
  • -C "you@example.com" is just a comment baked into the public key so when it shows up in a server's authorized list, you can tell which key is which. Use anything memorable — your email, your handle, your laptop's name.

It will ask where to save the file (~/.ssh/id_ed25519 is the default; fine to accept) and whether to set a passphrase (recommended — it encrypts the private key on disk, so a stolen laptop doesn't equal a stolen key).

You now have two files:

  • ~/.ssh/id_ed25519 — the private key. Never share.
  • ~/.ssh/id_ed25519.pub — the public key. Safe to share.

Get the public key onto the server

You need to add your public key to a file on the server called ~/.ssh/authorized_keys. There are three ways to do this:

  1. ssh-copy-id if it's installed: ssh-copy-id user@host. It will prompt for the server's existing password one time, then copy the key for you. Easiest path when the server still has password auth enabled.
  2. Manual copy if password auth is off: log into the server through whatever console the cloud provider gives you (AWS Session Manager, the EC2 Instance Connect web shell, etc.), open ~/.ssh/authorized_keys in a text editor, and paste the contents of your public key on a new line.
  3. At provision time: every cloud provider lets you supply a public key when you create a new VM. AWS calls it a "key pair." Google Cloud calls it "SSH keys." If you do this at provision time, your key is already authorized before the machine even boots.

Connect

ssh -i ~/.ssh/id_ed25519 ec2-user@52.34.118.92

The flags:

  • -i ~/.ssh/id_ed25519 tells SSH which private key to offer. If you only have one key in the default location, you can usually omit -i entirely.
  • ec2-user@52.34.118.92 is user @ host. The user is whatever account exists on the remote machine (AWS Amazon Linux defaults to ec2-user; Ubuntu defaults to ubuntu; your home server might be pi or root or whatever-you-named-it). The host is the server's IP or hostname.

If everything is set up correctly, you'll see a banner, and your prompt will change to reflect that you're now on the remote machine. Type pwd and you'll see the home directory on that machine, not your laptop's. Type exit and you're back to your laptop.

The AWS EC2 reality

Most readers will be connecting to an EC2 instance, so it's worth covering the AWS-specific shape of all this:

  • AWS gives you a .pem file, not the id_ed25519 style file ssh-keygen makes. The .pem is just the same thing — a private key — in a different envelope. SSH handles it natively if you use -i.
  • .pem files have to be chmod 400. AWS gives you the file via the browser, your computer's default permissions are too open, and SSH refuses to use a private key with loose permissions. chmod 400 ~/.ssh/tullup-ec2.pem fixes it.
  • The server's IP is its Elastic IP, not the random one AWS gives a fresh instance. The random IP changes every time the instance stops and starts. An Elastic IP, once allocated and attached, stays the same.
  • Port 22 has to be open in the security group. This is the most common reason an SSH connection just hangs — the network ACL silently drops the packets. Open port 22 only from your current public IP, not 0.0.0.0/0. Treat SSH as a credential, not a public service.

Three things that trip people up

  • File permissions. SSH is strict about who can read your private key. If you see Permissions … are too open and a refusal to connect, run chmod 600 ~/.ssh/id_ed25519 (or chmod 400 for read-only).
  • known_hosts churn. The first time you connect to a server, SSH prints a fingerprint and asks if you want to trust it. Your "yes" pins that fingerprint in ~/.ssh/known_hosts. If the server is ever rebuilt — same IP, new host key — SSH will refuse to connect because the fingerprint changed. That's the warning DOING ITS JOB. If you confirmed the rebuild yourself, remove the old line with ssh-keygen -R 52.34.118.92 and reconnect.
  • Agent forwarding. If you SSH into one server and then need to SSH from there to another server using your laptop's key, you don't copy your private key to the first server. You enable agent forwarding (-A) and your laptop's keychain is exposed only for that hop, only for the time you're connected. Convenient and far safer than scattering private keys across servers.

What this enables

Once SSH is muscle memory, a lot of cloud work stops being intimidating.

You stop being afraid to launch an EC2. You can always log in, look around, fix the thing, and move on. Logs aren't a black box — tail -f /var/log/... shows you exactly what's happening right now. A misbehaving container? docker exec -it ... drops you into a shell inside it. Disk filling up? df -h and du -sh * in five seconds. The remote machine stops being a magic box and becomes another computer you happen to be standing in front of.

There's also a comfort that comes from knowing the connection is secure end-to-end. The keypair model is one of the few security primitives in everyday computing that's actually solid: no rotating tokens, no SMS codes that can be SIM-swapped, no shared secret that can be phished. You hold the math, the server holds the math, and the wire holds neither.

That's the whole thing. The next time a tutorial tells you to "just SSH in," you know what's actually happening.

← Back to all posts