SSH

Technical Definition

SSH is a client–server protocol suite, most commonly implemented by OpenSSH, that establishes an encrypted, authenticated channel between two hosts, typically over TCP port 22. The protocol is layered: a transport layer negotiates server host-key verification, session encryption and integrity checking; a user authentication layer supports methods such as password, public-key, host-based and keyboard-interactive authentication; and a connection layer multiplexes the encrypted transport into logical channels used for interactive shell sessions, remote command execution, file transfer (via SFTP or SCP run over SSH) and arbitrary TCP port forwarding.

The specific mechanics of SSH — including cipher negotiation, key exchange and message framing — are described across the Internet Engineering Task Force’s RFC Series, the authoritative publication channel for this class of specification. Practitioners should confirm the exact RFC and version their implementation follows before relying on version-specific behaviour, since implementations and defaults evolve.

Operational Relevance

SSH underpins day-to-day remote administration of servers, network devices and containers. It is the transport most configuration-management and orchestration tools (for example, Ansible or rsync invoked with an SSH transport) use to reach managed hosts, and it is the standard mechanism for secure interactive troubleshooting, log inspection and emergency access when a graphical or web-based management plane is unavailable. Git also commonly uses SSH as a transport for authenticated repository access.

Because SSH sessions frequently carry privileged access, the security of the SSH configuration — key management, permitted authentication methods, and exposure of the listening service — is itself an operational control, not an afterthought.

Architecture Relationship

SSH sits above TCP and below the tools that rely on it. It does not replace TLS; the two protocols solve an overlapping but distinct problem (SSH is designed around interactive remote access and tunnelling with its own key-exchange and authentication model, while TLS is designed around securing arbitrary application protocols, most visibly HTTP). In a typical estate, SSH access is often concentrated through a bastion or jump host, integrated with a central key or certificate authority for issuing short-lived credentials, and constrained by host-based firewalling and identity-aware access controls rather than being exposed directly on every host.

Example

A minimal interactive connection from a workstation to a remote host follows this pattern:

ssh user@remote-host

Before relying on any SSH-based workflow, confirm the installed implementation and version in a non-production or isolated environment, and confirm the permissions of the account being used, since behaviour and defaults can differ between implementations and releases.

Misunderstanding

A common misunderstanding is that SSH exists only to provide an interactive command-line shell. In practice, the same encrypted channel is routinely used for file transfer, port forwarding and tunnelling other protocols, and for non-interactive command execution triggered by automation. A second, related misunderstanding is treating SSH and TLS/SSL as interchangeable “encryption for remote access” technologies; they are separate protocols with different authentication models, and neither is a drop-in substitute for the other.

Related Terms

• SFTP (SSH File Transfer Protocol)
• SCP (Secure Copy Protocol)
• OpenSSH (a widely deployed implementation of the SSH protocol)
• Public Key Infrastructure
• Bastion Host
• Port Forwarding / Tunnelling

Further Reading

For the authoritative specification lineage behind SSH, consult the RFC Series published by the RFC Editor, which is the primary reference point for the protocol’s transport, authentication and connection layers.

• RFC Editor — RFC Series