SSH Config and Key Management¶
SSH is how you get into remote servers. Key-based authentication is safer than passwords and, once set up, faster too. The ~/.ssh/config file is what turns SSH from something you type long commands for into something that actually works the way you want.
The Short Answer¶
# Generate a key (use ed25519 — it's faster and more secure than RSA now)
ssh-keygen -t ed25519 -C "yourname@hostname"
# Copy the public key to a server
ssh-copy-id user@server-ip
# SSH using a specific key
ssh -i ~/.ssh/id_ed25519 user@server-ip
Key Generation¶
# ed25519 — preferred
ssh-keygen -t ed25519 -C "home-laptop"
# RSA 4096 — use this if the server is old and doesn't support ed25519
ssh-keygen -t rsa -b 4096 -C "home-laptop"
The -C comment is just a label — use something that tells you which machine the key came from. Comes in handy when you look at authorized_keys on a server and need to know what's what.
Keys land in ~/.ssh/:
- id_ed25519 — private key. Never share this.
- id_ed25519.pub — public key. This is what you put on servers.
Copying Your Key to a Server¶
# Easiest way
ssh-copy-id user@server-ip
# If the server is on a non-standard port
ssh-copy-id -p 2222 user@server-ip
# Manual way (if ssh-copy-id isn't available)
cat ~/.ssh/id_ed25519.pub | ssh user@server-ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
After copying, test that key auth works before doing anything else, especially before disabling password auth.
SSH Config File¶
~/.ssh/config lets you define aliases for servers so you can type ssh myserver instead of ssh -i ~/.ssh/id_ed25519 -p 2222 admin@192.168.1.50.
# ~/.ssh/config
# Home server
Host homelab
HostName 192.168.1.50
User admin
IdentityFile ~/.ssh/id_ed25519
Port 22
# Remote VPS
Host vps
HostName vps.yourdomain.com
User ubuntu
IdentityFile ~/.ssh/vps_key
Port 2222
# Jump host pattern — SSH through a bastion to reach internal servers
Host internal-server
HostName 10.0.0.50
User admin
ProxyJump bastion.yourdomain.com
# Default settings for all hosts
Host *
ServerAliveInterval 60
ServerAliveCountMax 3
IdentityFile ~/.ssh/id_ed25519
After saving, ssh homelab connects with all those settings automatically.
Managing Multiple Keys¶
One key per machine you connect from is reasonable. One key per server you connect to is overkill for personal use but correct for anything sensitive.
# List keys loaded in the SSH agent
ssh-add -l
# Add a key to the agent (so you don't type the passphrase every time)
ssh-add ~/.ssh/id_ed25519
# On macOS, persist the key in Keychain
ssh-add --apple-use-keychain ~/.ssh/id_ed25519
The SSH agent stores decrypted keys in memory for the session. You enter the passphrase once and the agent handles authentication for the rest of the session.
Server-Side: Authorized Keys¶
Public keys live in ~/.ssh/authorized_keys on the server. One key per line.
# Check permissions — wrong permissions break SSH key auth silently
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
If key auth isn't working and the config looks right, permissions are the first thing to check.
Gotchas & Notes¶
- Permissions must be right. SSH ignores
authorized_keysif the file or directory is world-writable.chmod 700 ~/.sshandchmod 600 ~/.ssh/authorized_keysare required. - ed25519 over RSA. ed25519 keys are shorter, faster, and currently considered more secure. Use them unless you have a compatibility reason not to.
- Add a passphrase to your private key. If your machine is compromised, an unprotected private key gives the attacker access to everything it's authorized on. A passphrase mitigates that.
ServerAliveIntervalin your config keeps connections from timing out on idle sessions. Saves you from the annoyance of reconnecting after stepping away.- Never put private keys in cloud storage, Git repos, or Docker images. It happens more than you'd think.
See Also¶
- [[linux-server-hardening-checklist]]
- [[managing-linux-services-systemd-ansible]]