From Secure Shell to OpenSSH

Secure Shell (SSH) is a family of protocols and implementations for authenticated, encrypted network sessions. It replaced the unsafe assumption that a login stream could travel in clear text. Modern administrators normally use OpenSSH, the widely deployed open-source client and server, rather than treating “SSH” as a single immutable program or protocol version.

Use SSH-2 only. SSH-1 is historical material. Do not enable it, select it with a legacy compatibility option, or lower an algorithm policy to make an obsolete host work. Upgrade or isolate an old system instead.

A short history

Tatu Ylönen created the first Secure Shell after a 1995 password-sniffing incident. The early SSH-1 protocol established the basic idea—negotiate cryptography, authenticate the server, authenticate the user, and carry several logical sessions—but its design had weaknesses. SSH-1 was later revised to version 1.5, yet revision could not turn the original protocol family into a modern, extensible design.

SSH-2 was designed as a new protocol rather than as a minor SSH-1 update. Its architecture is specified by RFC 4251, within the RFC 4250–4254 core SSH-2 series: a transport layer provides confidentiality and integrity, a user-authentication layer proves the user’s identity, and a connection layer multiplexes channels. SSH-2’s negotiation and message framing avoid several SSH-1 design problems and provide room for contemporary key exchange and signature algorithms. SSH-1 and SSH-2 are not interchangeable.

The OpenSSH project began in the OpenBSD project in 1999 and became the normal SSH implementation on many Unix-like systems. OpenSSH has removed or disabled SSH-1 support in modern releases. A server’s ability to listen on TCP port 22 says nothing about whether it supports the current protocol or has a safe policy; inspect the installed OpenSSH version and configuration instead.

What “modern SSH” means

  • SSH-2 transport: the peers negotiate encryption, integrity protection, compression, and a key-exchange method before protected application data is sent.
  • Server host authentication: the client verifies a host key, usually against a locally trusted known_hosts entry. This prevents an active intermediary from silently impersonating a server after the first trust decision.
  • User authentication: after the server is identified, the client proves a user identity with a public key, keyboard-interactive method, certificate, or another policy-approved mechanism. A server host key is not a user login key.
  • Connection channels: one protected transport can carry an interactive shell, an exec request, port forwarding, X11 forwarding, or a subsystem such as SFTP. Channel separation lets a client authorize and close these uses independently.

SSH therefore does not mean “encrypt a password and send it.” It is a negotiated protocol with distinct trust decisions. A strong user key cannot compensate for accepting an unverified host key, and a verified host cannot authorize a user who is not allowed to log in.

Inspect the client without connecting

Use local inspection before changing a deployment. These commands do not log in to a host or reveal a private key:

ssh -V
ssh -Q protocol-version
ssh -Q key
ssh -G example.invalid | sed -n '1,80p'

ssh -V prints the client version to standard error. ssh -Q lists algorithms known by this build; an older OpenSSH may not recognize every query, so read that release’s manual rather than copying options from a newer system. ssh -G expands the effective client configuration for a host name and exits without opening a session. Use a non-routable documentation name when inspecting defaults, and do not paste private configuration or tokens into a public transcript.

At a maintenance window, inspect the server package and its effective configuration using the platform’s documented, privileged procedure. Do not infer security from a banner alone, and do not add obsolete algorithms merely because a compatibility guide mentions them.

Continue through the sequence

Continue with How SSH Establishes a Secure Connection to follow the SSH-2 exchange. Then review host-key verification before trusting a new machine.

References