How SSH Works and Secures Connections

What SSH Does

Secure Shell (SSH) provides encrypted remote access to servers and network devices. It replaces older, unencrypted protocols like Telnet and rlogin, wrapping all communication in strong cryptography. SSH is the standard tool for managing Linux servers, network equipment, cloud instances, and virtually any Unix-like system.

SSH operates on TCP port 22 by default. It provides a secure command-line shell, but it also supports file transfer (SCP, SFTP), port forwarding (tunneling), and X11 forwarding (remote graphical applications). The protocol handles key exchange, authentication, and encrypted data transfer in a single, well-defined framework.

From Telnet to SSH

Before SSH, remote server access used Telnet. Telnet transmits everything in cleartext - login credentials, commands, output, everything. Anyone on the network path between the client and server can capture the entire session, including the username and password.

Tatu Ylonen, a researcher at Helsinki University of Technology, created SSH in 1995 after a password-sniffing attack on his university network. SSH1 was followed by SSH2 (a complete protocol redesign with stronger cryptography), which was standardized by the IETF as RFC 4251 through RFC 4254.

OpenSSH, maintained by the OpenBSD project, is the dominant SSH implementation. It runs on virtually every Linux distribution, macOS, and (since 2018) Windows 10. When people say "SSH," they almost always mean OpenSSH.

Key Exchange

When an SSH connection starts, the client and server must agree on encryption keys without transmitting them over the network. This is done through a key exchange algorithm, typically Diffie-Hellman or its elliptic curve variant (ECDH).

graph TD
    subgraph "SSH Connection Setup"
        C1[Client connects to port 22] --> P1[Protocol version exchange]
        P1 --> K1[Key exchange - Diffie-Hellman]
        K1 --> K2[Shared secret established]
        K2 --> K3[Session keys derived]
        K3 --> SA[Server authentication - host key]
        SA --> CA[Client authentication - password or key]
        CA --> ENC[Encrypted session begins]
        ENC --> SHELL[Interactive shell or command]
    end

SSH establishes encryption through key exchange before any authentication data is transmitted

The Diffie-Hellman exchange works by having each side generate a random number, perform mathematical operations, and exchange the results. Both sides can then compute the same shared secret independently, but an observer who captures the exchanged values cannot derive the shared secret (assuming the discrete logarithm problem is hard, which it is for properly chosen parameters).

From this shared secret, both sides derive symmetric encryption keys (for AES or ChaCha20), integrity keys (for HMAC-SHA2 or Poly1305), and initialization vectors. All subsequent communication uses these symmetric keys, which are computationally efficient compared to asymmetric cryptography.

Server Authentication

After key exchange, the client needs to verify that it is talking to the correct server and not an impersonator performing a man-in-the-middle attack. SSH uses host keys for this purpose.

Every SSH server has one or more host key pairs (typically RSA, ECDSA, and Ed25519). The server proves its identity by signing data with its private key during the key exchange. The client verifies this signature using the server's public key.

The first time a client connects to a server, it has no record of the server's public key. SSH displays the key's fingerprint and asks the user to verify it manually. If the user accepts, the key is stored in the known_hosts file. On subsequent connections, SSH compares the server's key against the stored key and warns if it has changed.

This "trust on first use" (TOFU) model is a known weakness. If an attacker performs a man-in-the-middle attack during the first connection, the client will store the attacker's key. For high-security environments, host key fingerprints should be distributed through a separate, trusted channel (like DNS SSHFP records or configuration management).

Client Authentication

SSH supports multiple client authentication methods. The two most common are password authentication and public key authentication.

Password authentication sends the user's password to the server (encrypted within the SSH tunnel). The server checks it against its local password database or PAM (Pluggable Authentication Modules). Password authentication is simple but vulnerable to brute force attacks and password guessing.

Public key authentication uses an asymmetric key pair. The user generates a key pair (e.g., Ed25519 or RSA) and places the public key in the server's authorized_keys file. During authentication, the client proves possession of the private key by signing a challenge from the server. The private key never leaves the client machine and is never transmitted over the network.

graph TD
    subgraph "Password Authentication"
        PA1[Client sends username] --> PA2[Server requests password]
        PA2 --> PA3[Client sends password in encrypted tunnel]
        PA3 --> PA4[Server checks against password database]
        PA4 --> PA5[Vulnerable to brute force]
    end
    subgraph "Public Key Authentication"
        PK1[Client offers public key] --> PK2[Server checks authorized_keys]
        PK2 --> PK3[Server sends challenge]
        PK3 --> PK4[Client signs with private key]
        PK4 --> PK5[Server verifies signature]
        PK5 --> PK6[Private key never transmitted]
    end

Public key authentication is stronger - the private key never crosses the network

Public key authentication is significantly more secure. There is no password to brute force. An attacker would need to obtain the private key file from the client machine (and crack its passphrase, if one was set). For this reason, security best practice is to disable password authentication entirely and require public key authentication.

The Encrypted Channel

Once authentication succeeds, all data flowing through the SSH connection is encrypted with the session keys derived during key exchange. The encryption uses symmetric ciphers - typically AES-256-CTR, AES-256-GCM, or ChaCha20-Poly1305.

Each packet is individually encrypted and authenticated. The integrity check (MAC or AEAD authentication tag) ensures that packets cannot be modified in transit without detection. An attacker who can observe or intercept SSH traffic sees only encrypted bytes - the commands, output, transferred files, and tunneled data are all opaque.

Session keys are rekeyed periodically (typically after 1GB of data or 1 hour) to limit the impact of any single key compromise.

SSH Tunneling

SSH tunneling (port forwarding) allows you to route other protocols through the encrypted SSH connection. This is useful for accessing services that are only available on a remote network or for encrypting protocols that do not have their own encryption.

Local port forwarding (ssh -L 8080:dbserver:5432 user@jumphost) listens on a local port and forwards traffic through the SSH connection to a remote destination. This lets you access a database server that is only reachable from the jump host, with all traffic encrypted through the SSH tunnel.

Remote port forwarding (ssh -R 8080:localhost:80 user@server) listens on a port on the remote server and forwards traffic back to the client. This can expose a local service through a remote server.

Dynamic port forwarding (ssh -D 1080 user@server) creates a SOCKS proxy. Applications configured to use the SOCKS proxy route all their traffic through the SSH tunnel. This effectively creates a VPN-like connection through SSH.

Common Security Failures

Despite SSH's strong cryptographic design, real-world deployments often have security problems.

Password authentication enabled. Leaving password authentication active invites brute force attacks. Automated tools continuously probe SSH servers with common credentials. If any account has a weak password, it will eventually be compromised.

Shared private keys. When teams share a single private key among multiple people, there is no accountability (you cannot tell who used the key) and revoking access requires generating a new key and distributing it to everyone else.

No key rotation. SSH keys that are generated once and never rotated accumulate risk over time. Departing employees, compromised workstations, and key exposure through backups all create risks that grow without rotation.

Root login enabled. Allowing direct root login over SSH means an attacker only needs one credential to gain full system control. Requiring users to log in with individual accounts and escalate via sudo provides accountability and an additional authentication barrier.

No fail2ban or rate limiting. Without something to block repeated failed login attempts, brute force attacks can run indefinitely. fail2ban monitors SSH logs and temporarily blocks IP addresses that generate too many authentication failures.

Hardening SSH

A hardened SSH configuration includes several key settings in sshd_config:

• PasswordAuthentication no - Disable password authentication entirely
• PermitRootLogin no - Prevent direct root login
• PubkeyAuthentication yes - Require public key authentication
• MaxAuthTries 3 - Limit authentication attempts per connection
• AllowUsers specificuser - Restrict SSH access to specific accounts
• Protocol 2 - Ensure only SSH protocol version 2 is used

Install and configure fail2ban to block brute force attempts. Use Ed25519 keys (preferred over RSA for new deployments) with strong passphrases. Distribute host key fingerprints through DNS SSHFP records or configuration management to prevent TOFU attacks.

SSH is the lifeline for remote server management. Understanding how it works - from key exchange through authentication to the encrypted channel - helps you configure it securely and recognize when something is wrong. Tools like the BLEShark Nano complement this knowledge by giving you visibility into the wireless devices on your network that may be running SSH and other services.