How SSH Establishes a Secure Connection

An SSH-2 connection is a sequence of negotiated layers, not one encryption switch. The client and server first exchange protocol identification strings, then negotiate a transport, authenticate the server’s host key during key exchange, authenticate a user inside the protected transport, and finally open one or more channels. A failure at one layer should not be “fixed” by weakening a different layer.

The transport handshake

  1. Version exchange: each side sends an SSH-2 identification string. A current OpenSSH client rejects SSH-1 instead of silently converting a connection to the obsolete protocol.
  2. Algorithm negotiation: each side advertises ordered lists for key exchange, server host-key signature, encryption, integrity, and compression. The first mutually acceptable choice according to the negotiation rules becomes the session policy.
  3. Key exchange: a Diffie–Hellman, elliptic-curve, or modern curve-based exchange creates shared session secrets. The exchange transcript binds the result to the negotiated data and the server’s host-key signature.
  4. New keys: after both parties send the key-change message, subsequent packets use the negotiated encryption and integrity protection. SSH can rekey during a long session; rekeying does not replace the host key or ask the user to trust a new server automatically.

Current OpenSSH installations commonly prefer a Curve25519-family key exchange and authenticated encryption or an encrypt-then-MAC construction, but exact defaults vary by release, build, and policy. “Strong” is a property of the complete negotiated configuration, not of a single algorithm name copied into a command.

Host authentication is a separate trust decision

The server signs the exchange with a host private key. The client compares the corresponding public key to a trusted entry in ~/.ssh/known_hosts, a system-wide known-hosts file, or another configured trust source. On a first connection, the client may use trust on first use (TOFU): it shows a fingerprint and asks whether to record the key. TOFU is useful only when the first observation is made over a trustworthy path; it is not proof that the first key was genuine.

For a new or high-value host, obtain its fingerprint over an independent channel—such as a console, a controlled inventory system, or a previously authenticated administrator—and compare it before accepting. A DNS name, an IP address, a server banner, and a key obtained by an unauthenticated scan are not independent proof. The client must also reject an unexpected key change until an administrator explains and verifies it.

User authentication follows the transport

Once the host is authenticated and the transport is protected, the client requests user authentication. Public-key authentication proves possession of a private key without sending that private key to the server. The server checks the corresponding public key against the account’s authorization policy, commonly authorized_keys. Password and keyboard-interactive authentication are separate methods and may be disabled by the server. Host keys and user keys have different owners, files, rotation schedules, and recovery procedures.

# Inspect the locally expanded policy; this does not connect.
ssh -G example.invalid | grep -E '^(kexalgorithms|hostkeyalgorithms|pubkeyacceptedalgorithms|ciphers|macs|compression) '

# Ask this OpenSSH build which names it knows.
ssh -Q kex
ssh -Q cipher
ssh -Q mac

Some older builds do not support every ssh -Q query or configuration keyword. Treat an “unknown query” or “Bad configuration option” error as a version signal, consult the matching ssh_config(5) manual, and upgrade where possible. Do not solve a version mismatch by enabling SSH-1 or the legacy ssh-rsa signature scheme globally.

Channels share one protected transport

The SSH connection protocol multiplexes channels inside the transport. An interactive shell, a one-shot command, SFTP, local forwarding, remote forwarding, and agent forwarding are distinct channel requests with distinct permissions. Multiplexing reduces repeated handshakes, but it does not make every channel safe. A host that is trusted for shell administration may not be trusted to receive forwarded connections or an agent.

Use the narrowest request needed. Keep agent forwarding off unless a documented workflow requires it, avoid forwarding sensitive services through an untrusted account, and make the server’s forwarding policy explicit. A successful login proves only that this user and this host satisfied their respective policies; it does not authorize arbitrary forwarding.

Continue through the sequence

Next, verify SSH host keys and manage known_hosts. After host trust is established, create and protect user keys.

References