SSH the boring way

general / published / guide #30 / ≈ 3 min read

SSH (Secure Shell) is how you log into another computer over the network. It's the most-used remote-access tool on the planet — every Linux server, every Raspberry Pi, every VPS expects you to use it. This guide is the no-magic walkthrough: how to set it up so it just works, every day, with a key instead of a password.

The cast of characters

  • Client — your laptop, the one you type on.
  • Server — the remote machine you're logging into.
  • Key pair — two files that go together: a private key (kept secret on the client) and a public key (copied to the server).

The server lets you in if it sees the public key in its authorized_keys list and you can prove you have the matching private key. No password needed.

Step 1: Make a key pair (once, ever, per laptop)

ssh-keygen -t ed25519 -C "your-email-or-anything"

The flags:

  • -t ed25519 — pick the modern key type. (RSA still works; ed25519 is shorter and faster.)
  • -C — a comment baked into the key. People typically use their email. Just so you can tell keys apart later.

Press Enter to accept the default filename (~/.ssh/id_ed25519). When asked for a passphrase, pick one — that way, if your laptop is stolen, the thief still can't use your key.

Two files appear:

  • ~/.ssh/id_ed25519 — your private key. Treat it like a password. Never share, never commit to git.
  • ~/.ssh/id_ed25519.pub — your public key. Fine to share, fine to paste anywhere.

Step 2: Copy the public key to a server

The friendly tool:

ssh-copy-id you@server.example.com

It logs in once with your password, appends your public key to ~/.ssh/authorized_keys on the server, and gets out. Next time you SSH there it'll use the key.

If ssh-copy-id isn't available (rare), do it by hand:

cat ~/.ssh/id_ed25519.pub | ssh you@server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Step 3: Log in

ssh you@server.example.com

You'll be prompted for the key's passphrase (not the server password). If everything's set up right, you get a shell on the remote machine.

Step 4: Stop typing the passphrase a hundred times — use ssh-agent

ssh-agent holds your unlocked key in memory for the rest of your login session. Most desktop distros run it automatically; if not:

eval "$(ssh-agent)"
ssh-add ~/.ssh/id_ed25519
# enter passphrase ONCE
# every ssh for the rest of the session uses it silently

Step 5: ~/.ssh/config — the secret weapon

Stop typing usernames, hostnames, and ports. Make a file at ~/.ssh/config:

Host home
    HostName 192.168.1.50
    User alice
    Port 22

Host work
    HostName bastion.company.example
    User alice.smith
    Port 2222
    IdentityFile ~/.ssh/id_work

Host *
    ServerAliveInterval 60
    AddKeysToAgent yes

Now ssh home connects you to alice@192.168.1.50, and ssh work uses the right username, port, and key automatically. The Host * block applies to everything: ServerAliveInterval 60 keeps idle connections from dropping over flaky networks.

Step 6: Make the server safer

Now that key login works, harden the server. Edit /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Find or add these lines:

PasswordAuthentication no
PermitRootLogin no

That turns off password logins entirely — only people with a valid key get in. Reload SSH:

sudo systemctl reload sshd

Important: open a second ssh session before logging out of the first. If you broke something, you still have a way in.

Bonus: copying files

scp file.txt you@server:/tmp/                # upload one file
scp -r mydir you@server:/tmp/                # whole directory
scp you@server:/var/log/syslog .             # download

rsync -av mydir/ you@server:/tmp/mydir/      # the better choice — see rsync guide

Bonus: tunnels

Reach a database on a remote server as if it were running on your laptop:

ssh -L 5432:localhost:5432 you@dbserver

Now localhost:5432 on your laptop forwards to localhost:5432 on dbserver. Close the SSH session and the tunnel closes too.

Troubleshooting checklist

  • "Permission denied (publickey)" — server didn't accept your key. Run with ssh -v to see which keys it tried. Verify the public key is in ~/.ssh/authorized_keys on the server.
  • "Connection refused" — sshd isn't running on the server (or the firewall is blocking port 22).
  • "Connection timed out" — wrong IP, or network problem.
  • Permissions on .ssh — must be 700 on the directory and 600 on key files. Looser permissions cause the server to silently refuse the key.

← back to index