SSH: Secure Shell

What is SSH?

SSH (Secure Shell) is a cryptographic network protocol that provides encrypted communication between two computers. It is the standard method for remotely administering servers, transferring files, and creating encrypted tunnels over untrusted networks.

Tatu Ylonen created the original SSH protocol in 1995 at the University of Helsinki, motivated by a password-sniffing attack on the university network. Before SSH, administrators relied on Telnet and rlogin, both of which transmitted credentials and data in plaintext. SSH solved this by encrypting the entire session from the very first key exchange.

The current version, SSH-2, is defined in RFC 4253 and is the only version considered secure today. SSH-1 had cryptographic weaknesses and should never be used. OpenSSH, the most widely deployed SSH implementation, disabled SSH-1 support entirely in version 7.6 (2017).

SSH is used for far more than remote terminals. It supports secure file transfer through SCP and SFTP, port forwarding, SOCKS proxying, X11 forwarding, and serves as the transport layer for Git. Nearly every Linux and macOS system ships with an SSH client built in, and Windows has included OpenSSH since Windows 10.

How SSH Establishes a Secure Connection

When you run ssh user@server, a carefully orchestrated sequence of steps takes place to establish an encrypted channel before any user credentials are transmitted. Every SSH connection follows this process.

Step 1: TCP Connection

The client opens a TCP connection to port 22 on the remote server. This is a standard three-way TCP handshake with no encryption yet.

Step 2: Protocol Version Exchange

Both sides send their SSH protocol version string (for example, SSH-2.0-OpenSSH_9.6). This identifies the software and confirms both sides support SSH-2. If the versions are incompatible, the connection is dropped.

Step 3: Key Exchange (Diffie-Hellman)

The client and server perform a Diffie-Hellman key exchange (or a variant like Curve25519) to generate a shared secret. This is the core cryptographic step. Neither side ever sends the shared secret over the wire. Instead, each side contributes a public value, and both independently compute the same shared secret from the combination.

Step 4: Host Key Verification

The server sends its host key (a public key unique to the server) to prove its identity. The client checks this key against its known_hosts file. If the key is new, the client prompts the user to accept it. If the key has changed unexpectedly, SSH displays a warning because this could indicate a man-in-the-middle attack.

Step 5: Encrypted Channel Established

Using the shared secret from the key exchange, both sides derive symmetric encryption keys for the session. From this point forward, all traffic is encrypted. Only now does user authentication begin.

Step 6: User Authentication

The server challenges the client to prove the user's identity. This typically uses public key authentication or a password, both transmitted through the already-encrypted channel. Once authentication succeeds, the interactive session or command begins.

SSH Protocol Architecture

SSH is not a single monolithic protocol. It is composed of three layered sub-protocols, each handling a distinct responsibility. This separation keeps the design modular and allows each layer to be updated independently.

Transport Layer Protocol (RFC 4253)

The transport layer handles encryption, data integrity, and optional compression. It runs directly over TCP and is responsible for the initial key exchange, server authentication, and re-keying during long-lived sessions. Supported ciphers include AES-256-GCM, ChaCha20-Poly1305, and AES-256-CTR.

User Authentication Protocol (RFC 4252)

The authentication layer runs on top of the encrypted transport. It supports multiple methods: password, public key, keyboard-interactive (for 2FA/MFA), and certificate-based authentication. The server advertises which methods it accepts, and the client tries them in order of preference.

Connection Protocol (RFC 4254)

The connection layer multiplexes the single encrypted tunnel into multiple logical channels. Each channel can carry a different stream: an interactive shell session, a port-forwarding connection, an SFTP transfer, or an X11 display. Channels have independent flow control, so a large file transfer will not block your terminal session.

SSH Authentication Methods

SSH supports several authentication methods. Choosing the right one depends on your security requirements and infrastructure scale.

For most production environments, public key authentication is the minimum recommendation. Password authentication should be disabled on any server exposed to the internet, as it is a common target for automated brute-force attacks. Certificate-based authentication scales best for organizations managing hundreds or thousands of servers, since it eliminates the need to distribute individual public keys.

SSH Tunneling and Port Forwarding

One of SSH's most powerful features is its ability to forward network traffic through the encrypted connection. This lets you securely access services that are not directly reachable or encrypt traffic for protocols that lack their own encryption.

Local Port Forwarding (-L)

Local forwarding binds a port on your local machine and tunnels traffic to a destination through the SSH server. This is useful for accessing a remote database or web application that only listens on the server's localhost.

ssh -L 5432:localhost:5432 user@server

This command forwards your local port 5432 to port 5432 on the remote server. You can then connect to localhost:5432 on your machine and reach the remote PostgreSQL instance.

Remote Port Forwarding (-R)

Remote forwarding works in the opposite direction. It opens a port on the SSH server and forwards incoming connections back to your local machine (or another host reachable from your machine). This is commonly used to expose a local development server to the internet.

ssh -R 8080:localhost:3000 user@server

Anyone connecting to port 8080 on the server will be tunneled to port 3000 on your local machine.

Dynamic Port Forwarding (-D, SOCKS Proxy)

Dynamic forwarding creates a local SOCKS proxy that routes all traffic through the SSH server. This is useful for encrypting web browsing on untrusted networks or bypassing network restrictions.

ssh -D 1080 user@server

Configure your browser or application to use localhost:1080 as a SOCKS5 proxy, and all traffic will flow through the encrypted SSH tunnel.

Common SSH Use Cases

• Remote server administration: the primary use case for SSH, providing encrypted terminal access to Linux and Unix servers
• Git over SSH: GitHub, GitLab, and Bitbucket all support Git operations over SSH, authenticated with your SSH key pair
• SCP/SFTP file transfer: securely copy files between machines using scp or sftp, both built on the SSH protocol
• Tunneling and port forwarding: encrypt traffic for any protocol by routing it through an SSH tunnel
• Jump hosts and bastion servers: SSH supports ProxyJump (ssh -J) to chain connections through intermediate hosts, keeping internal servers off the public internet
• CI/CD pipelines: deployment scripts use SSH to connect to production servers, run commands, and transfer build artifacts
• Database access through tunnels: developers use local port forwarding to reach databases behind firewalls without exposing the database port to the internet

SSH vs Telnet

SSH was designed as a secure replacement for Telnet. The two protocols serve the same basic purpose (remote terminal access), but their security characteristics are fundamentally different.

There is no legitimate reason to use Telnet for server administration today. Telnet is still found in some legacy industrial and networking equipment, but any new deployment should use SSH exclusively.

Frequently Asked Questions About SSH

What is the difference between SSH-1 and SSH-2?

SSH-1 and SSH-2 are completely different protocols (not just version increments). SSH-1 has known cryptographic vulnerabilities, including susceptibility to insertion attacks, and is no longer supported by modern implementations. SSH-2 (RFC 4253) features stronger key exchange algorithms, better integrity checking, and a modular architecture with separate sub-protocols. Always use SSH-2.

How does SSH public key authentication work?

You generate a key pair: a private key (kept secret on your machine) and a public key (placed on the server in ~/.ssh/authorized_keys). During authentication, the server sends a challenge encrypted with your public key. Your SSH client signs the challenge with your private key, and the server verifies the signature. Your private key never leaves your machine and is never transmitted over the network.

What is an SSH host key and why does it matter?

A host key is a cryptographic key pair that uniquely identifies an SSH server. When you connect for the first time, your client stores the server's public host key in ~/.ssh/known_hosts. On subsequent connections, your client verifies the server presents the same key. If the key changes unexpectedly, SSH warns you because this could indicate a man-in-the-middle attack or that the server has been replaced.

Can SSH be used for file transfer?

Yes. SSH supports two file transfer methods. SCP (Secure Copy Protocol) is a simple command-line tool for copying files between hosts. SFTP (SSH File Transfer Protocol) is a more feature-rich protocol that supports directory listings, file resumption, and random access. Both run over the SSH encrypted channel and require no additional ports or services.

What port does SSH use?

SSH uses TCP port 22 by default. This can be changed in the server configuration (/etc/ssh/sshd_config) using the Port directive. Some administrators change the port to reduce noise from automated brute-force scanners, though this is security through obscurity and should not replace proper authentication hardening.

Is SSH the same as SSL/TLS?

No. SSH and SSL/TLS are both cryptographic protocols that provide encrypted communication, but they are completely separate protocols designed for different purposes. SSL/TLS secures web traffic (HTTPS), email, and other protocols by providing a general-purpose encryption layer. SSH is specifically designed for remote access, file transfer, and tunneling. They use different handshake mechanisms, different certificate models, and different authentication approaches. SSH uses its own host key and authorized_keys system, while TLS relies on Certificate Authorities.

Related Protocols

• TCP: the transport layer protocol that SSH runs on top of
• HTTPS: another protocol that uses encryption (TLS) to secure communication
• SMTP: email transfer protocol that can use SSH tunneling for secure relay
• HTTP: the plaintext web protocol, similar to how Telnet relates to SSH