SSH architecture - how Secure Shell actually works

SSH (Secure Shell) is the standard tool for remote access on Linux. It provides a confidential, integrity-protected channel between two hosts, with mutual authentication. This lesson is about how SSH actually works - the protocol layers, the cryptography, and the channel model.

SSH is not TLS, and it is not built on X.509. It has its own key format, its own certificate format, and its own trust model based on known_hosts rather than a CA bundle. Nothing in this part depends on the PKI material in Part LXXI; read that part for the web/TLS side, but do not expect the concepts to map across one-for-one. They deliberately do not.

The protocol layers

SSH has three layers:

1. Transport layer (SSH-TRANS): provides the encrypted channel. Handles key exchange, server authentication, and symmetric encryption.
2. User authentication layer (SSH-USERAUTH): authenticates the client to the server. Methods: password, publickey, keyboard-interactive (for MFA), hostbased.
3. Connection layer (SSH-CONNECT): multiplexes multiple channels (sessions, port forwards, X11, SFTP) over one transport.

Client                                              Server
  |--- SSH-TRANS key exchange (Diffie-Hellman) ---|
  |--- Server host key verification (known_hosts) -|
  |--- Encrypted transport established ------------|

  |--- SSH-USERAUTH publickey/password ----------|
  |--- User authenticated -----------------------|

  |--- SSH-CONNECT open channel (session) ------|
  |--- Commands, port forwards, etc. -----------|

Host authentication

The server proves its identity with a host key - a public/private keypair generated when sshd is installed. The public key fingerprint is stored in ~/.ssh/known_hosts on the client after the first connection.

If the fingerprint changes (server reinstall, MITM attempt), the client refuses to connect:

@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!    @
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Verify the change is legitimate (server reinstall), update known_hosts, and continue.

User authentication

The client proves its identity. Common methods:

• password: the user types a password. Sent over the encrypted channel but vulnerable to weak passwords and brute force.
• publickey: the client proves possession of a private key whose public half is in ~/.ssh/authorized_keys on the server. Recommended.
• keyboard-interactive: a generic mechanism for challenge-response. Used for one-time passwords, MFA, PAM.
• hostbased: the client proves it is on a trusted host. Rare; less secure than publickey.

The server’s sshd_config AuthenticationMethods lists the allowed methods and order.

Channels

After authentication, the SSH connection layer opens one or more channels:

• session: a shell or command.
• direct-tcpip: client-side port forwarding (local port to remote target).
• forwarded-tcpip: server-side port forwarding (remote port to client target).
• x11: X11 forwarding.
• auth-agent: agent forwarding (ssh-agent).

Multiple channels share one transport - one SSH connection can carry shell sessions, port forwards, and SFTP simultaneously.

SSH versions

OpenSSH supports SSH-2 only. The server’s sshd_config Protocol directive defaults to 2.

Encryption

SSH-2 negotiates the cipher suite on each connection. Modern preferences:

Disable weak algorithms in sshd_config:

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-ctr

Host key algorithms

Host keys come in several algorithms:

Use Ed25519 or RSA (>= 2048 bit). Ed25519 is preferred.

Key exchange

SSH-2 uses Diffie-Hellman key exchange. Modern preferences:

Disable weak groups:

KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512

Knowledge check