Skip to main content
Back to module
Linux Administration · Automation and Access

SSH and keys

Reading1h 15mLesson 1 of 3 in this module

Log in to a Linux machine with SSH keys instead of passwords, and apply a few safe hardening settings.

Why it matters

SSH (Secure Shell) is how administrators reach almost every Linux server: cloud VMs, database hosts, network devices, build machines. It encrypts everything between you and the server. It is also one of the most attacked services on the internet: any server with SSH open to the world sees automated password-guessing attempts within minutes. Logging in with keys and turning off password logins removes that whole class of attack.

How SSH works, briefly

  • The SSH server (sshd, in the openssh-server package) listens on TCP port 22.
  • The client (ssh) connects: ssh alex@192.0.2.10.
  • On first connection the server proves its identity with a host key. Your client shows its fingerprint and asks whether to trust it, then remembers it in ~/.ssh/known_hosts. If the host key later changes, the client warns loudly: that can mean the server was rebuilt, or that someone is intercepting the connection. Find out which before continuing.
  • You then authenticate, with a password or with a key.

Key pairs

A key pair is two linked files:

  • The private key (~/.ssh/id_ed25519) stays on your computer. Never copy it to a server, email it, paste it into chat or commit it to Git.
  • The public key (~/.ssh/id_ed25519.pub) can be shared freely. Putting it in a server's ~/.ssh/authorized_keys means "whoever holds the matching private key may log in as this user".

When you connect, the server sends a challenge that only the private key can answer. The private key never leaves your machine.

Create a key

ssh-keygen -t ed25519 -C "alex laptop 2026"

Accept the default path and set a passphrase. The passphrase encrypts the private key file, so a stolen laptop does not mean stolen server access. ssh-agent remembers the unlocked key for your session so you do not type the passphrase every time:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Install the public key on the server

ssh-copy-id alex@192.0.2.10

This appends your public key to ~/.ssh/authorized_keys on the server and sets the right permissions. Without ssh-copy-id, append the .pub file's single line manually. SSH is strict about permissions and silently ignores keys if they are too open:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys ~/.ssh/id_ed25519

Now ssh alex@192.0.2.10 should log you in without asking for the account password (it may ask for the key's passphrase).

A client config file

Save typing with ~/.ssh/config on your own computer:

Host practice
    HostName 192.0.2.10
    User alex
    Port 22
    IdentityFile ~/.ssh/id_ed25519

Then ssh practice is enough. The same file works for scp and Git over SSH.

Hardening the server

Server settings are in /etc/ssh/sshd_config and in files under /etc/ssh/sshd_config.d/. For most settings sshd uses the first value it reads, and the .d files are read first in name order, so put your changes in a file with a low number, for example /etc/ssh/sshd_config.d/01-hardening.conf:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AllowUsers alex
  • PermitRootLogin no: log in as yourself and use sudo, so every action is tied to a person.
  • PasswordAuthentication no: password guessing becomes useless.
  • AllowUsers: only the named accounts may log in over SSH.

Apply changes without locking yourself out

This is the part that matters most. A mistake here can leave you unable to reach a remote server.

  1. Confirm key login works first, in a separate terminal.
  2. Keep your current session open while you change anything.
  3. Test the config: sudo sshd -t prints nothing when it is valid.
  4. Check the effective values: sudo sshd -T | grep -iE "passwordauth|permitroot".
  5. Restart: sudo systemctl restart ssh (the unit is sshd on the Red Hat family).
  6. Open a new terminal and log in again before closing the old session.

On a cloud VM, also know where the provider's web console is, so you can get in if SSH breaks. A firewall such as ufw (sudo ufw allow OpenSSH before sudo ufw enable) and a tool like fail2ban add further layers, but keys plus no passwords is the big win.

Copying files over SSH

scp report.txt practice:/tmp/
scp practice:/var/log/syslog ./syslog-copy
rsync -av ./site/ practice:~/site/      # copies only what changed

Common mistakes

  • Sharing or committing the private key. If it leaks, remove its public key from every authorized_keys and make a new pair.
  • No passphrase on the key.
  • Wrong permissions on ~/.ssh, so the server ignores the key and falls back to a password.
  • Disabling passwords before testing key login, or closing the only session before testing the new config.
  • Typing yes to a changed host key warning without checking why.

Recap

  • SSH encrypts remote logins; the server proves itself with a host key stored in known_hosts.
  • ssh-keygen -t ed25519 makes a key pair; the private key stays with you, the public key goes in authorized_keys.
  • Harden with PermitRootLogin no and PasswordAuthentication no, tested with sshd -t, while keeping a session open.
  • ~/.ssh/config, scp and rsync make daily work faster.

Try it

In the Do tab you will set up key login to your practice system and switch off password logins safely.

Also in this lesson: