SSH

After this lesson, you will be able to: Use SSH professionally: key-based auth, the ~/.ssh/config file, port forwarding, SCP, and the hardening every server needs.

SSH is the front door to every server you'll ever manage. This lesson takes you from 'I copy-paste ssh commands' to 'I run a hardened SSH setup'.

Prerequisites:Shell Scripting

Key-based auth (passwords are obsolete)

Generate once, copy to each server, never type a password again.

tsx

# Generate a modern Ed25519 key (smaller, faster, more secure than RSA)
ssh-keygen -t ed25519 -C '[email protected]'
# Press Enter to accept default location (~/.ssh/id_ed25519)
# Enter a passphrase (use one, it encrypts the key at rest)

# Copy to a server
ssh-copy-id alex@server.example.com
# Now you can: ssh alex@server.example.com  (no password)

~/.ssh/config: the file that ends typing long commands

Create or edit ~/.ssh/config (mode 600). Every host you SSH to should have an entry.

tsx

# ~/.ssh/config
Host prod
  HostName prod.example.com
  User alex
  IdentityFile ~/.ssh/id_ed25519
  ServerAliveInterval 60

Host staging
  HostName 10.0.5.42
  User deploy
  Port 2222
  IdentityFile ~/.ssh/id_ed25519_staging

# Jump through a bastion to reach internal hosts
Host internal-db
  HostName 10.0.1.50
  User dba
  ProxyJump prod

# Now: `ssh prod` instead of `ssh -i ~/.ssh/id_ed25519 [email protected]`

SCP and rsync for file transfer

Both copy files over SSH; rsync wins for almost everything.

tsx

# scp (simple, but no resume on failure)
scp file.txt prod:~/file.txt
scp -r local-dir/ prod:/srv/myapp/
scp prod:/var/log/app.log .

# rsync (the right tool)
rsync -avzP file.txt prod:~/                # -a archive, -v verbose, -z compress, -P progress
rsync -avzP --delete local-dir/ prod:/srv/myapp/  # --delete syncs deletions too
rsync -e 'ssh -p 2222' ...                  # custom SSH port

Port forwarding (the underused superpower)

Tunnel a remote port to your laptop for safe debugging.

tsx

# Local port forwarding: reach a service running on prod from your laptop
ssh -L 5432:localhost:5432 prod
# Now `psql -h localhost` on your laptop talks to prod's Postgres

# Remote port forwarding (rare): expose YOUR laptop's port on the remote
ssh -R 8080:localhost:8080 prod

# Dynamic (SOCKS proxy)
ssh -D 1080 prod
# Configure your browser to use SOCKS5 at localhost:1080; all traffic exits via prod

Hardening sshd_config (must-do for any prod server)

Edit `/etc/ssh/sshd_config`. After saving: `sudo systemctl restart sshd`. `PermitRootLogin no`, never allow root SSH; admins log in as themselves and `sudo`. `PasswordAuthentication no`, keys only. Passwords are guessable. `PubkeyAuthentication yes`, explicit. `AllowUsers alex deploy`, whitelist users who can SSH. `Port 2222` (optional), non-default port reduces noise from script kiddies (NOT real security). Install `fail2ban` to auto-ban IPs that brute-force.

Common mistakes only experienced engineers avoid

Keys without a passphrase. If your laptop is stolen, every server is compromised. Leaving `PasswordAuthentication yes` after enabling keys. The password fallback IS the attack surface. SSH'ing as root. Use a regular user + sudo. Forgetting to restart sshd after config changes. Test the new config in a SECOND terminal before closing the first (so you don't lock yourself out). Putting private keys on shared servers. Never. Move them with extreme care.

Quick Check

You're about to disable password auth on a production server. What's the ONE thing you do first?

Pick the safety habit.

Backup the serverVerify you can already SSH in via key in a SECOND terminal, KEEP that terminal open during the changeDisable network accessReboot

←Environment and Configuration

Back to Linux and the Command Line

Package Management→