SSH Keys and Hardening

Introduction

Passwords for remote logins can be guessed or leaked. SSH keys are far stronger, and once set up, more convenient. Servers exposed to the internet are attacked constantly, so basic hardening matters. Only practise on machines you own or are authorised to manage.

The simple explanation

An SSH key pair has a private key you keep secret and a public key you give to servers. The server can check you hold the private key without it ever being sent.

Create a key pair

ssh-keygen -t ed25519 -C "sam@laptop"

This creates two files in ~/.ssh/:

• id_ed25519 is the private key. Never share it. Protect it with a strong passphrase when asked.
• id_ed25519.pub is the public key. This is safe to share.

Install your public key on a server

ssh-copy-id [email protected]

This adds your public key to ~/.ssh/authorized_keys on the server. Now ssh [email protected] logs you in using the key.

Permissions matter. SSH refuses keys that others can read: your private key should be chmod 600, and the ~/.ssh folder chmod 700.

A config file

Save typing with ~/.ssh/config:

Host web
    HostName server.example.com
    User alice
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Now ssh web is all you need. The same names work for scp and rsync.

Copy files

scp report.txt web:/home/alice/
rsync -avz --progress ./site/ web:/var/www/site/

rsync copies only what changed, which is far faster for repeated transfers. The trailing slashes matter, so test with --dry-run first.

Basic server hardening

1. Keep software updated: sudo apt update && sudo apt upgrade, or enable automatic security updates.
2. Use keys, not passwords. After confirming your key works, in /etc/ssh/sshd_config set PasswordAuthentication no and PermitRootLogin no, then reload SSH. Keep a second session open while testing so you do not lock yourself out.
3. Use a firewall. With ufw on Ubuntu:

sudo ufw allow OpenSSH
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

Allow only what you need, and allow SSH before enabling the firewall. 4. Least privilege. Normal user accounts with sudo, and services running as their own users. 5. Watch logs such as /var/log/auth.log for repeated failed logins. Tools like fail2ban can block them. 6. Back up and test restoring.

Agent forwarding and secrets

Use ssh-agent to hold a decrypted key for your session, so you type the passphrase once. Never copy your private key onto servers, and never commit keys to Git.

Try it yourself

On a practice virtual machine you control, create a key pair, install it, log in with it, create an SSH config entry, and then disable password login. Verify you can still log in with a second terminal before closing the first.

Summary

• SSH keys beat passwords: keep the private key secret and share only the public key.
• A config file and rsync make remote work quicker.
• Harden servers with updates, key-only logins, a firewall, least privilege and logging.