Lab lesson · free

SSH explained – understand and practise in the terminal

SSH is the secure door to every server. Those who understand it work securely and conveniently at once. Here you learn how keys work instead of passwords – and practise the login on a real VM.

Key pair instead of password

An SSH key pair consists of a private (stays with you) and a public key (goes on the server). You generate it with ssh-keygen. Passwordless login is not only more convenient but also safer against brute force.

Connecting and known_hosts

You connect with ssh user@host. The first time you confirm the fingerprint – it lands in known_hosts and protects against man-in-the-middle attacks.

Hardening the SSH server

Disable password login, forbid root login, change the port: small changes in sshd_config with big impact. You go deeper into this in server hardening.

What the fingerprint on first connect means

On the first connection SSH shows a fingerprint and asks whether you accept it. That question is the single moment an attacker could wedge themselves in – afterwards ~/.ssh/known_hosts remembers the key and warns on any deviation. Confirming blindly with „yes“ is common and still the weakest point of the whole scheme.

Why the private key never leaves the device

The private key is not transmitted during login. The server sends a challenge, your machine answers it using the private key, and only the answer travels back. That is why a key beats a password: an intercepted login gives an attacker nothing that can be replayed.

The SSH agent: passphrase once instead of every time

A key without a passphrase is a file that grants access on its own – whoever copies it is in. With a passphrase you would type it on every connection. The ssh-agent solves that: it holds the decrypted key in memory for the session. One ssh-add, and afterwards you connect without typing; on logout the key is protected again.

Configuration instead of long commands

In ~/.ssh/config you record a name, user, port and key per target. ssh -i ~/.ssh/lab -p 2222 user@10.0.20.20 becomes ssh lab. That saves more than typing: keeping connection details in one place means a port change can only go wrong in one place.

What usually goes wrong

The costliest mistake is locking yourself out: disabling password login before key login demonstrably works. Hence the rule to keep a second session open until the new configuration is verified. Second classic: copying the private key to the server instead of the public one – that puts the secret exactly where it does not belong. Third: changing the port and forgetting the firewall rule.

Port forwarding: working through the tunnel

SSH carries not only a session but, on request, network connections too. With ssh -L 8080:localhost:80 lab you reach a web service that listens only locally on the target machine, via http://localhost:8080 on your own device. That is the clean way to use an admin interface without exposing it to the internet – and the reason a service bound to 127.0.0.1 stays conveniently usable. The forwarding ends with the SSH session; no open port is left behind.

Commands to try

Generate a key pair and copy it over

$ ssh-keygen -t ed25519 -C "lab-practice"$ ssh-copy-id user@targethost$ ssh user@targethost

ed25519 instead of RSA: shorter, faster and the standard today. ssh-copy-id appends the public key to ~/.ssh/authorized_keys on the target without overwriting the file.

Test the connection before changing the config

$ ssh -v user@targethost$ sudo sshd -t$ sudo systemctl reload ssh

sshd -t checks the config file for syntax errors. Only reload afterwards – a restart with a broken file locks you out unless you have a second session open.

Fix the permissions in .ssh

$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/authorized_keys$ ls -ld ~/.ssh

SSH ignores keys when the permissions are too open – and only says so in verbose mode. Over-permissive files are the most common reason a correct key is refused.

Use the agent and name the connection

$ eval "$(ssh-agent -s)"$ ssh-add ~/.ssh/id_ed25519$ printf 'Host lab\n  HostName 10.0.20.20\n  User learner\n' >> ~/.ssh/config$ ssh lab

After the entry in ~/.ssh/config the short name is enough. The file must belong to you alone – chmod 600 ~/.ssh/config, or SSH ignores it.

Common error messages

Permission denied (publickey).: Cause: The server accepts keys only and yours does not fit: wrong user, key missing from authorized_keys, or the permissions in .ssh are too open.; Fix: Watch with ssh -v which key is offered, and on the target set chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys.
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!: Cause: The server key differs from the one in known_hosts. Harmless after a reinstall – but an attack looks exactly the same.; Fix: First establish why the key changed. If the reinstall is known: ssh-keygen -R targethost and verify the new fingerprint on the next connect.
ssh: connect to host targethost port 22: Connection refused: Cause: Nothing is listening on that port – the service is not running, or it was moved to a different port.; Fix: Check sudo systemctl status ssh on the target and look up the port with sudo ss -tlnp | grep sshd. „Connection timed out“ instead of „refused“ points at the firewall.
Bad owner or permissions on /home/learner/.ssh/config: Cause: The config file is readable by others or owned by a different user. SSH then refuses it entirely.; Fix: chmod 600 ~/.ssh/config and chown $USER ~/.ssh/config.
sign_and_send_pubkey: signing failed: agent refused operation: Cause: The agent no longer holds the key – after a reboot, or because this is a different session from the one where ssh-add ran.; Fix: Check with ssh-add -l which keys are loaded and add it again with ssh-add.

In five steps

01Create a key pair with ssh-keygen -t ed25519 and set a passphrase.
02Copy the public key to the target with ssh-copy-id – never copy the private one.
03Test the key login while password login is still enabled.
04Only then set PasswordAuthentication no and PermitRootLogin no in /etc/ssh/sshd_config.
05Check with sudo sshd -t, reload – and keep a SECOND session open until the new one works.

What you practise

ssh-keygen, Schlüsselpaaressh user@host, known_hostssshd_config härtenknown_hosts & Fingerabdruck

Practise now in the Lab →

Continue learning

Get in Touch

Have a project?

Let's bring your idea to life together. We're happy to advise you with no obligation.

Get in Touch →