Understanding SSH: Ports, Workflow, and Key Authentication Explained

SSH Overview

SSH (Secure Shell) is a network security protocol that provides encrypted and authenticated remote login, command execution, and file transfer (e.g., SFTP, SCP). It replaces clear‑text protocols such as Telnet and FTP.

Default Port Numbers

The standard listening port for SSH services is 22 . When SSH is used as the transport for NETCONF, the port may be 22 or 830 . The port can be changed in the server configuration; after a change all existing connections are terminated and the daemon starts listening on the new port.

SSH Connection Workflow

1. Connection Establishment

The SSH server listens on the configured TCP port. A client initiates a TCP connection to that port, establishing a reliable transport channel.

2. Version Negotiation

Both sides exchange protocol version strings. SSH supports the legacy SSH‑1.x protocol and the current SSH‑2.0 protocol. After negotiation, the higher‑capability version (normally SSH‑2.0) is used.

3. Algorithm Negotiation

Each side advertises the cryptographic algorithms it supports, including:

Key‑exchange algorithms (e.g., diffie‑hellman‑group14‑sha1, ecdh‑sha2‑nistp256)

Symmetric encryption algorithms (e.g., aes256‑ctr, chacha20‑poly1305)

Public‑key (host‑key) algorithms (e.g., rsa‑sha2‑256, ecdsa‑sha2‑nistp256)

Message‑authentication code (HMAC) algorithms (e.g., hmac‑sha2‑256)

The client and server agree on one algorithm from each category, which will be used for the session.

4. Key Exchange

Using the selected key‑exchange algorithm, the client and server compute a shared secret. From this secret they derive a session key (symmetric) and a session ID . The session key encrypts all subsequent traffic; the session ID is used for authentication and channel binding.

5. User Authentication

After the encrypted channel is established, the client authenticates to the server. SSH supports several authentication methods:

Password – client sends username and password (encrypted within the channel).

Public‑key – client proves possession of a private key that matches a public key stored in the server’s authorized_keys file.

Password‑public‑key – both password and key are required.

Any – either password or key is sufficient.

6. Session Request

Once authentication succeeds, the client requests a specific service (e.g., a shell, command execution, or a subsystem such as SFTP). The server creates the requested channel.

7. Session Interaction

Data is exchanged over the encrypted channel using the negotiated symmetric cipher and HMAC. Multiple logical channels (shell, exec, port‑forwarding, etc.) can coexist within a single SSH connection.

Common SSH Clients

PuTTY is a free, open‑source SSH client for Windows. It provides a graphical interface for configuring host, port, authentication method, and optional tunneling.

OpenSSH is the reference implementation of the SSH protocol. It is bundled with most Unix‑like operating systems and is available as an optional feature in Windows 10 and later. Typical commands include:

ssh user@host            # start an interactive session

scp file.txt user@host:/path/   # copy a file securely

sftp user@host               # start an SFTP session

SSH Keys and Cryptography

Symmetric and Asymmetric Encryption

SSH combines two cryptographic primitives:

Symmetric encryption – a single shared key (the session key) encrypts and decrypts bulk data. This provides high performance for large data streams.

Asymmetric encryption – a public/private key pair is used during key exchange and for user authentication. The public key can be distributed openly; only the holder of the matching private key can decrypt data encrypted with the public key.

The following diagrams illustrate the two encryption types used in an SSH connection:

Key‑Based Authentication Flow

Key authentication eliminates the need for passwords. The typical flow is:

The client generates a public/private key pair (e.g., ssh-keygen -t rsa -b 4096) and copies the public key to the server’s ~/.ssh/authorized_keys file.

The client initiates a login request. The server looks up the client’s public key and encrypts a random challenge with it.

The client decrypts the challenge using its private key and returns the plaintext response.

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

The diagram below visualises this process: