What is SSH (Secure Shell)?
Updated: 3 days ago
SSH, or Secure Shell, is a cryptographic network protocol used for secure remote login and other secure network services across an untrusted network. It creates an encrypted, integrity-protected connection between an SSH client and an SSH server, authenticates the server, and then authenticates the user before opening one or more logical channels for commands, shells, file transfer or tunnelling.
The most important distinction is that SSH protects the connection in transit. It does not make the remote computer itself secure. A compromised server, stolen private key, weak account policy or incorrectly verified host key can still undermine the security of an SSH session.
How does SSH work?
SSH normally runs over a reliable transport such as TCP. The protocol architecture separates the job into transport, user authentication and connection layers. The transport layer establishes confidentiality, integrity and server authentication; the user authentication layer verifies the client-side user; and the connection layer multiplexes the protected session into logical channels.
The SSH client opens a network connection to the SSH server. TCP port 22 is the conventional default, although a server can listen on another port.
Client and server identify compatible protocol algorithms and perform key exchange to establish session keys.
The client verifies the server host key against a trusted key, certificate or previously recorded host key. This step is important because blindly accepting a changed host key can expose the user to a man-in-the-middle attack.
The user authenticates to the server using an allowed method, commonly a public key or password. Server policy can require more than one authentication method.
After authentication, SSH can create channels for an interactive shell, command execution, subsystems such as SFTP, or TCP port forwarding.
What is SSH used for?
Remote administration: securely log in to Linux servers, virtual machines, NAS devices, routers, firewalls and other systems that provide an SSH service.
Remote command execution: run individual commands or scripts without opening a full interactive shell.
Secure file transfer: use SFTP, which operates as an SSH subsystem, or SCP implementations that use SSH transport.
Port forwarding: carry TCP connections through the encrypted SSH connection using local, remote or dynamic forwarding.
Automation: authenticate non-interactive jobs with carefully controlled keys and restricted permissions.
Development and operations: access source repositories, build systems, cloud instances and remote development environments.
SSH client, SSH server and sshd
An SSH connection has two endpoints. The client is the program that initiates the connection. The server accepts SSH connections and enforces authentication and access policy. On Unix-like systems using OpenSSH, the server daemon is commonly called sshd.
SSH is an application-layer protocol. Your broadband connection, router, IP addressing and routing still have to deliver packets between the endpoints. SSH then protects the session carried across that network path.
Does SSH always use port 22?
Port 22 is the registered and conventional TCP port for SSH, but it is not mandatory. An administrator can configure an SSH server to listen on another port. Changing the port can reduce some automated background scanning against port 22, but it is not a substitute for strong authentication, patching, firewall policy and access control.
If an SSH server is behind a home or office router using NAT, inbound access may also depend on port forwarding, firewall policy and whether the broadband connection provides a directly reachable address.
SSH authentication: passwords, keys and host keys
SSH uses two different ideas that are easy to confuse: the server proves its identity to the client with a host key, while the user separately proves their identity to the server. A host key warning is therefore not the same thing as a failed username or password.
Password authentication: the user supplies account credentials through the protected SSH connection. Its security still depends on password strength, server policy and resistance to credential attacks.
Public key authentication: the user proves possession of a private key while the server holds the corresponding authorised public key. The private key should remain protected on the client.
Host key verification: the client checks the server identity. A new or unexpectedly changed host key should be investigated rather than automatically accepted.
Multi-factor or multi-method authentication: SSH server policy can require more than one authentication method for selected users or connections.
SSH uses encryption to protect session traffic, but SSH is a separate protocol from TLS. Both can provide encrypted network communication, but their protocol structures, trust models and common applications differ.
SSH keys: what actually happens?
With public key authentication, the public key can be stored on the server without revealing the private key. During authentication, the client demonstrates possession of the corresponding private key by producing cryptographic proof tied to the SSH session. The private key itself does not need to be transmitted to the server.
A passphrase can protect a private key file at rest. An SSH agent can hold unlocked key material for convenience, but agent forwarding should be enabled only when it is genuinely required because forwarding extends where authentication capability can be used.
SSH vs Telnet
SSH and Telnet can both provide terminal-style remote access, but they should not be treated as equivalent security technologies. SSH was designed to provide confidentiality, integrity and authentication over an insecure network. Traditional Telnet does not provide comparable cryptographic protection for the session.
SSH vs VPN
A VPN normally creates a protected network path for a device, site or selected traffic. SSH normally protects specific SSH sessions and any channels deliberately carried inside them. SSH port forwarding can tunnel individual TCP connections, but that does not automatically make SSH a full replacement for a VPN.
SSH port forwarding and tunnelling
Local forwarding: a local listening port sends selected traffic through SSH to a destination reachable from the server side.
Remote forwarding: a listening port on the remote side sends selected traffic back through SSH towards the client side.
Dynamic forwarding: the SSH client can provide a SOCKS-style proxy so applications can send selected connections through the SSH session.
Port forwarding is powerful because it can carry traffic that would otherwise be inaccessible, but that also means administrators should control which forwarding features users are allowed to create. SSH tunnels can interact with firewall and segmentation policy in ways that deserve deliberate configuration.
SSH over UK home broadband
SSH itself does not depend on a particular UK access technology. It can work across FTTP, FTTC, cable, fixed wireless or mobile broadband as long as the required IP path is available. The practical issue for inbound access is reachability, not whether the access line is fibre.
A home connection using CGNAT may not provide a unique, directly reachable public IPv4 address for conventional inbound IPv4 port forwarding. A static IP address can make the destination address predictable, but static addressing is not itself a security feature.
IPv6 can provide globally routable addressing without IPv4 NAT, but inbound SSH still depends on firewall rules, server configuration and the exact ISP, product and network setup.
Techie Broadband calculation: how much bandwidth does an SSH terminal need?
Interactive SSH command-line work usually transfers very little data compared with a broadband speed test or large file download. As a theoretical example, if a terminal session averaged 20 kilobits per second continuously for one hour, the transferred volume would be 20,000 bits/s × 3,600 s ÷ 8 = 9,000,000 bytes, or about 9 MB using decimal units.
That is an illustrative calculation, not a measured universal SSH usage figure. Real traffic varies with terminal output, keepalives, encryption overhead, file transfers, forwarded connections and the applications being carried. An SFTP transfer through SSH can use substantial bandwidth, while an idle shell may use almost none.
What affects SSH responsiveness?
Latency: every interactive round trip takes time, so a distant server can feel less responsive even when bandwidth is plentiful.
Packet loss: lost packets can trigger TCP retransmissions and pauses.
Server load: a busy or overloaded remote machine can respond slowly even when the network is healthy.
Client and server cryptographic processing: normally negligible for terminal use, but potentially relevant to very high throughput encrypted transfers on constrained hardware.
The narrowest network link: WiFi, Ethernet, broadband, an intermediate route or the remote network can constrain large SFTP or SCP transfers.
More broadband bandwidth does not automatically make an interactive SSH shell feel faster. For command-line work, latency and packet loss can matter more than headline Mbps.
How to make SSH access safer
Keep the SSH server and operating system patched and supported.
Prefer well-managed public key authentication for administrative access where appropriate.
Protect private keys and use passphrases where the operational model supports them.
Verify host keys instead of automatically accepting unexpected changes.
Disable unused accounts and remove obsolete authorised keys.
Apply least privilege rather than giving every SSH user unrestricted administrative access.
Use firewall rules, network segmentation or a VPN where appropriate to limit who can reach the SSH service.
Review authentication logs and investigate repeated failures or unexpected successful logins.
Disable unnecessary forwarding, agent forwarding and other features when they are not required.
A firewall can restrict which addresses or networks can reach an SSH service. Port scanning can reveal that a reachable TCP port is accepting connections, which is another reason not to rely on a non-standard port as the primary security control.
Troubleshooting an SSH connection
Confirm the remote hostname or IP address and make sure you are connecting to the intended system.
Check basic IP connectivity to the destination where appropriate, remembering that blocked ICMP does not by itself prove SSH is unavailable.
Confirm the SSH server is running and listening on the expected address and TCP port.
Check the client command, username and selected identity key.
Check local, server and network firewall rules.
If connecting through IPv4 NAT, confirm any required port-forwarding rule points to the correct internal address and port.
If the connection reaches the server but authentication fails, inspect the server authentication logs and authorised-key or account configuration.
If a host key has unexpectedly changed, stop and verify why before accepting the new key.
Common SSH misconceptions
SSH is not the same as HTTPS or TLS.
SSH does not make a compromised server trustworthy.
Port 22 is the default, not a requirement.
Moving SSH to another port is not strong authentication.
A static IP address is convenient for reachability but does not secure SSH.
Public key authentication does not mean the private key is uploaded to the server.
An SSH tunnel protects traffic while it is carried inside SSH; it does not automatically secure what happens beyond the tunnel endpoints.
Frequently asked questions
What does SSH stand for?
SSH stands for Secure Shell. It is a protocol for secure remote login and other secure network services over an insecure network.
Is SSH encrypted?
Yes. The SSH transport layer provides confidentiality and integrity protection for the session after key exchange, using negotiated cryptographic algorithms.
What port does SSH use?
TCP port 22 is the conventional default for SSH. Administrators can configure a server to listen on another port.
Is SSH the same as SFTP?
No. SSH is the secure protocol and connection architecture. SFTP is a file-transfer protocol commonly provided as an SSH subsystem and carried inside an SSH connection.
Do I need a static IP address for SSH?
No. SSH does not require a static IP address. A predictable address can make inbound access easier to manage, but reachability depends on DNS or addressing, NAT, firewall policy and the broadband product.
Can SSH work over IPv6?
Yes. SSH can operate over IPv6 when the client, server and network path support it. A globally routable IPv6 address does not remove the need for firewall controls.
Authoritative SSH specifications
The IETF SSH protocol architecture in RFC 4251 defines the transport, user authentication and connection components. The transport protocol is specified in RFC 4253, user authentication in RFC 4252 and the connection protocol in RFC 4254.
Key takeaway
SSH is a secure remote-access protocol, not simply an encrypted replacement for a password prompt. It authenticates the server, establishes a protected transport, authenticates the user and then carries one or more logical channels for shells, commands, file transfer or forwarding. For secure use, protect private keys, verify host keys, restrict exposure, keep systems patched and treat a reachable SSH service as an administrative interface that deserves deliberate access control.
To explore the related technical concepts used in this SSH (Secure Shell) guide, visit our broadband terminology guide.
