SSH: Securing Remote Access

SSH-1, the original Secure Shell protocol, contained a fundamental design flaw that allowed an active attacker to insert arbitrary data into an encrypted session without being detected. SSH-2, a complete protocol redesign published in 2006 as RFC 4251-4254, addressed these weaknesses with separate transport, authentication, and connection layer protocols, and with stronger integrity checking using HMAC. SSH-1 is deprecated and no modern server should enable it.

The SSH transport layer protocol handles the initial key exchange and establishes an encrypted, integrity-protected channel. It negotiates algorithms for key exchange (typically ECDH), host authentication (typically Ed25519 or RSA), symmetric encryption (typically AES-256-CTR or ChaCha20-Poly1305), and MAC (typically HMAC-SHA2-256). Every subsequent packet is both encrypted and integrity-checked using the negotiated algorithms.

Once the transport layer is secured, the user authentication layer negotiates how the user proves their identity to the server. Three common methods are password (user types a password, which is sent encrypted over the transport layer), public key (user proves possession of a private key corresponding to an authorised public key on the server), and GSSAPI (Kerberos single sign-on integration for enterprise environments).

The SSH connection layer multiplexes multiple logical channels over the single encrypted transport connection. A typical SSH session has one channel for the interactive shell. Additional channels support port forwarding, X11 forwarding, and SFTP file transfer, all sharing the same authenticated and encrypted connection. Channel requests allow the client to request a pseudo-terminal, set environment variables, or execute a specific command.

On first connecting to an SSH server, the client receives the server's host key and must decide whether to trust it. The default policy is Trust On First Use (TOFU): the user is prompted to verify the key fingerprint (typically shown as a hash like SHA256:...) and if accepted, it is stored in the known_hosts file. On subsequent connections, the stored key is compared against what the server presents, and a mismatch triggers a stern warning about potential man-in-the-middle attacks.

The known_hosts file, stored at ~/.ssh/known_hosts, maintains a database of server host keys indexed by hostname and IP address. Each entry links a server's address to its public key. If a server's key changes, perhaps because the server was reinstalled or because an attacker is impersonating it, SSH refuses to connect and displays a warning. Administrators use certificate-based host authentication to avoid TOFU trust decisions at scale.

Public key authentication stores the user's public key in ~/.ssh/authorized_keys on the server. When the user connects, the server sends a challenge encrypted with the public key; only the holder of the matching private key can respond correctly, proving identity without transmitting the private key or a password. This is more secure than passwords because private keys are never sent over the network and cannot be phished.

Three families of SSH key algorithms are in common use. RSA keys of 3072 or 4096 bits are compatible with all servers. ECDSA using the NIST P-256 curve is faster than RSA with equivalent security but P-256's security parameters have attracted scrutiny. Ed25519, based on the Edwards-curve Digital Signature Algorithm, is the modern recommendation: fast, small 256-bit keys, strong security properties, and no special-case parameter concerns.

Tatu Ylönen, a Finnish researcher at Helsinki University of Technology, developed SSH in 1995 after a password-sniffing attack on his university network exposed hundreds of credentials. He chose port 22 because it was between telnet (23) and ftp (21). SSH replaced both insecure protocols. Ylönen founded SSH Communications Security and later released SSH-2 as an open standard through the IETF. OpenSSH, the dominant free implementation, was created by the OpenBSD project in 1999.

SSH agent is a background process that holds decrypted private keys in memory, allowing single sign-on to multiple servers without re-entering the passphrase. Agent forwarding (-A flag) extends this by forwarding the agent connection to remote servers, enabling one-hop access to internal servers. However, agent forwarding is a security risk: a compromised remote server can use the forwarded agent to authenticate as you to other servers. Use ProxyJump instead of agent forwarding.

Secure SSH configuration includes disabling root login (PermitRootLogin no), disabling password authentication (PasswordAuthentication no) in favour of public key only, using Ed25519 host keys, enabling only SSH-2 protocol, configuring idle session timeouts, restricting allowed users with AllowUsers or AllowGroups, and changing the default port as an obscurity measure to reduce automated scan noise. Fail2ban or similar tools block IPs with repeated failed attempts.

Why is SSH public key authentication considered more secure than password authentication?

SSH-2 replaced the flawed SSH-1 with separate transport, authentication, and connection layers. The transport layer negotiates encryption and integrity. User authentication supports passwords, public keys, and GSSAPI. Host key verification uses TOFU and known_hosts. Ed25519 is the recommended key algorithm. Agent forwarding is a security risk; use ProxyJump instead. Hardening includes disabling root login and password authentication.