How SSH Works: Key Exchange, Host Keys & Brute-Force Attacks (Animated)

SSH gives you an encrypted command line on a remote machine. It replaced Telnet, which sent everything, passwords included, in clear text. SSH encrypts the session, proves the server’s identity with a host key, and can log you in with a key pair instead of a password.

1. Version exchange: hello, i speak ssh-2.0

After the TCP handshake on port 22, both sides send a one-line banner in clear text.

1. BANNER (Your laptop → Linux server): The client announces its protocol and software version.
2. BANNER (Linux server → Your laptop): So does the server. This banner is what scanners like Nmap read to find outdated versions.

Wireshark filter:

ssh.protocol

2. Key exchange: agree a secret, verify the server

Both sides list their algorithms, then run a Diffie-Hellman exchange. The server signs it with its host key so the client knows it isn’t talking to an impostor.

1. KEXINIT (Your laptop → Linux server): A list of supported algorithms, strongest first.
2. KEX REPLY (Linux server → Your laptop): The client compares the fingerprint with the one saved in known_hosts. First time, it asks: “Are you sure you want to continue connecting?”
3. NEW KEYS (Your laptop → Linux server): From here on, Wireshark shows only encrypted packets.

Wireshark filter:

ssh.message_code == 20 || ssh.message_code == 31

3. Log in: prove who you are

Inside the encrypted channel the user authenticates. With public-key login the client signs a challenge with its private key; no password is ever sent.

1. USERAUTH (Your laptop → Linux server): The server checks the signature against ~/.ssh/authorized_keys.
2. SUCCESS (Linux server → Your laptop): A shell opens. Every keystroke and every line of output now travels encrypted.

Wireshark filter:

ssh.encrypted_packet

4. Brute force: attack: guessing passwords all day

Any SSH server on the internet is hit by bots within minutes. They try common usernames and passwords thousands of times.

1. USERAUTH (Attacker → Linux server): Each attempt is a full login. In the server’s log: “Failed password for root from 198.51.100.66”.
2. SUCCESS (Linux server → Attacker): One weak password is enough. The attacker now has a shell on the server.

Wireshark filter:

tcp.dstport == 22 && tcp.flags.syn == 1

5. Keys + fail2ban: defence: nothing to guess

Turn off password login so only key holders can connect, block root login, and ban addresses that fail repeatedly.

1. USERAUTH (Attacker → Linux server): The server doesn’t even accept passwords, and fail2ban firewalls the attacker’s IP.

/etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin no
MaxAuthTries 3

FAQ