Understanding SSH: Ports, Authentication, and Encryption Explained

SSH Overview

Secure Shell (SSH) is a cryptographic network protocol that provides encrypted, authenticated remote login, command execution, and file transfer. It replaces insecure protocols such as Telnet and FTP by encrypting all traffic and verifying the identity of both client and server.

Default Port Numbers

The standard SSH service (including remote shells, SFTP, and SCP) listens on TCP port 22 . When SSH is used as the transport for NETCONF, the service may listen on port 22 or 830 . Administrators can change the listening port; after a change all existing connections are terminated and the daemon starts listening on the new port.

Connection Establishment

The SSH server opens a TCP socket on the configured port and waits for incoming connection requests. When a client initiates a TCP three‑way handshake, a reliable channel is created between the two endpoints.

Version Negotiation

During the initial handshake the client and server exchange version strings, e.g. SSH-2.0-OpenSSH_8.9. Modern implementations always negotiate the SSH‑2.0 protocol, which supports a richer set of key‑exchange, authentication, and encryption algorithms. Legacy SSH‑1.x is deprecated and rarely used.

Algorithm Negotiation

Both sides send ordered lists of supported algorithms. They negotiate four categories:

Key‑exchange (KEX) algorithm – e.g. curve25519‑[email protected], diffie‑hellman‑group14‑sha1.

Server‑host key algorithm – e.g. rsa‑sha2‑256, ecdsa‑sha2‑nistp256.

Encryption algorithm – e.g. aes256-ctr, [email protected].

Message authentication code (MAC) – e.g. hmac-sha2-256, [email protected].

The first mutually supported entry in each list is selected for the session.

Key Exchange and Session Key Derivation

Using the agreed KEX algorithm, the client and server perform a Diffie‑Hellman‑like exchange to compute a shared secret. From this secret both sides derive:

A session ID that uniquely identifies the connection for later authentication steps.

A session key that encrypts all subsequent traffic with the chosen symmetric cipher.

The session key is never transmitted in clear; it is generated independently on both sides from the shared secret.

User Authentication

After the encrypted channel is established, the client must prove its identity. SSH defines several authentication methods; the server advertises which are allowed.

Password authentication : the client sends the username and password encrypted with the session key. The server validates the credentials against local or external databases.

Public‑key authentication : the client proves possession of a private key that matches a public key stored in ~/.ssh/authorized_keys on the server.

Keyboard‑interactive / challenge‑response : a flexible method that can combine password prompts, one‑time passwords, or other factors.

Combined methods (e.g., password,publickey): the server may require multiple factors before granting access.

Session Request and Interaction

Once authentication succeeds, the client sends a service request (e.g., ssh‑connection) followed by a channel open request for a specific subsystem such as a shell, sftp, or exec. The server acknowledges, and both sides exchange data over the encrypted channel, enabling secure command execution, file transfer, or port forwarding.

Common SSH Clients

PuTTY is a widely used free SSH client for Windows. It supports password, public‑key, and keyboard‑interactive authentication and can be configured to use any of the algorithms negotiated by the server.

OpenSSH is the reference open‑source implementation. It ships with most Unix‑like operating systems and, since Windows 10, is available as an optional feature that can be installed via Settings → Apps → Optional Features.

Encryption Model: Symmetric + Asymmetric

SSH combines two cryptographic primitives:

Asymmetric (public‑key) cryptography is used during the key‑exchange phase and for public‑key authentication. It allows the client and server to establish a shared secret without transmitting it.

Symmetric encryption (e.g., AES‑CTR, ChaCha20) encrypts the bulk data after the session key is derived, providing high performance for large data streams.

The following diagram (original source) illustrates the two‑stage encryption process:

Public‑Key Authentication Flow

The client generates a id_rsa (or ed25519) key pair and copies the public key to ~/.ssh/authorized_keys on the server.

During login the server selects the stored public key, encrypts a random challenge (or signs a hash) and sends it to the client.

The client decrypts or signs the challenge with its private key and returns the result.

The server verifies the response; if it matches, authentication succeeds.