Navigating the Network Layer: Why Standard SSH Relies Strictly on TCP (And Why UDP Configurations Spell Failure for Administrators)

Main Facts

When configuring firewalls, routing tables, cloud security groups, or infrastructure-as-code scripts, systems administrators inevitably encounter a foundational question: Should Secure Shell (SSH) traffic be assigned to the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP)?

For standard OpenSSH implementations—the ubiquitous backbone of remote server administration, secure file transfers, and automated deployment pipelines—the definitive answer is TCP.

Standard OpenSSH connects exclusively over TCP, traditionally utilizing port 22. This protocol assignment governs not only interactive remote shell access but also secure file operations executed via SFTP (Secure File Transfer Protocol) and SCP (Secure Copy Protocol). A frequent pitfall for junior administrators and automated cloud provisioning tools alike is opening UDP port 22 in a security group or host-based firewall, under the mistaken impression that it mirrors TCP connectivity. In reality, allowing inbound UDP on port 22 does not enable a normal SSH connection. Because standard OpenSSH does not listen for or parse UDP packets on that port, any attempt to authenticate or establish a session will fail silently or drop with a connection timeout.

Understanding this distinction is vital for maintaining robust security postures without inadvertently locking administrators out of critical infrastructure. While the Internet Assigned Numbers Authority (IANA) port registries can sometimes list service names across multiple transport protocols—leading to confusion over whether secondary protocols are required—practical systems administration relies on the actual behavior of the server software being deployed. Standard OpenSSH is fundamentally a TCP-oriented protocol suite.

Chronology

To fully understand why standard SSH is tethered to TCP, it is helpful to look back at the historical development of remote administration protocols and how they evolved from insecure foundations to modern cryptographic standards.

The Era of Cleartext Protocols (Pre-1995)

Before the widespread adoption of SSH, remote systems management relied heavily on cleartext protocols such as Telnet (TCP port 23), rlogin, and rsh. These legacy utilities were built directly on top of TCP because terminal sessions required reliable, in-order delivery of character streams. If a packet containing a keystroke or a block of output was lost or corrupted, the transport layer needed to retransmit it seamlessly to prevent data corruption or desynchronization in the terminal UI. However, because these protocols transmitted all data—including passwords—in plain text, they became unacceptable security risks as the internet expanded.

The Birth of OpenSSH and TCP Integration (1995–Present)

In 1995, Tatu Ylönen introduced the first version of SSH (SSH-1) to replace insecure remote login tools. Designed as a secure cryptographic tunnel, SSH was architected from the ground up to inherit the reliability characteristics of TCP. When OpenBSD developers later forked the project to create OpenSSH—the open-source standard used across nearly all Linux, Unix, and macOS environments today—they preserved this TCP-first architecture.

Over the decades, as SFTP and SCP were integrated into the SSH protocol suite to replace FTP and rcp, they did not spin up independent transport mechanisms. Instead, they were engineered as subsystems running entirely inside the established SSH connection, leveraging the underlying TCP transport layer. Even as modern alternatives like Mosh (Mobile Shell) emerged in the 2010s to address high-latency and roaming network connections by introducing UDP-based session layers, they retained an initial TCP-based SSH handshake for authentication, further cementing TCP’s role as the indispensable gateway for secure shell access.

Supporting Data and Protocol Analysis

To demystify how SSH behaves across different networking layers, consider the structural comparison between TCP and UDP implementations in modern server environments:

Why TCP Fits SSH Structurally

The primary reason TCP is the mandatory transport layer for SSH lies in the nature of the data being transmitted. SSH carries an ordered stream of terminal input, cryptographic handshake data, command outputs, and file-transfer blocks.

• Ordered Delivery: TCP guarantees that data packets arrive at their destination in the exact sequence they were transmitted. If a packet is dropped en route, TCP pauses delivery to the application layer, requests a retransmission from the sender, and ensures data integrity before handing the stream off to the SSH daemon.
• Stream-Oriented Architecture: UDP, by contrast, is a connectionless protocol that offers no built-in delivery guarantees, ordering, or flow control. If an application utilizes UDP, it must implement its own mechanisms for packet sequencing, loss recovery, and acknowledgment. Because standard OpenSSH is not a UDP-based service with an embedded recovery layer, forcing it to run over UDP is fundamentally incompatible with its codebase.

Tunneling, Port Forwarding, and UDP Traffic

A common point of confusion among system administrators involves SSH tunneling and port forwarding options (such as local forwarding -L, remote forwarding -R, and dynamic SOCKS proxying -D).

While these tools allow administrators to tunnel various types of network traffic—including database queries, web traffic, and specialized application data—through a secure SSH connection, they do not transform the underlying SSH transport into a general-purpose UDP tunnel. Standard SSH port forwarding encapsulates TCP connections inside the encrypted SSH stream. If an administrator needs to tunnel raw UDP traffic, specialized tools or VPN overlays (such as WireGuard or OpenVPN in TAP mode) must be employed, as simply opening UDP port 22 on a firewall will not facilitate UDP-based SSH forwarding.

Official Responses and Industry Best Practices

Leading cloud providers, enterprise operating system vendors, and security compliance authorities maintain rigorous guidelines regarding firewall rule management and port configurations for SSH.

Cloud Provider Security Standards

Major cloud infrastructure providers—including Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP)—enforce explicit protocol declarations within their Virtual Private Cloud (VPC) security groups and firewall rulesets.

In official AWS documentation and security blueprints, engineers are consistently instructed to restrict inbound security group rules for SSH (TCP port 22) to trusted CIDR blocks rather than wide-open public access (0.0.0.0/0). Furthermore, cloud security posture management (CSPM) tools flag any security group that exposes overly permissive or misconfigured protocols. Automated scanners routinely check whether ports are bound strictly to TCP, noting that accidental creation of UDP-only rules on port 22 represents both a configuration error and a potential administrative blind spot.

Enterprise Compliance Frameworks

Frameworks such as the Center for Internet Security (CIS) Benchmarks, Payment Card Industry Data Security Standard (PCI-DSS), and the National Institute of Standards and Technology (NIST) Special Publication 800-53 explicitly mandate strict network access controls for remote administrative interfaces.

Security auditors inspecting host-based firewalls (such as iptables, nftables, or ufw) and enterprise perimeter routers look for explicit validation that administrative access is bound exclusively to TCP sockets. Compliance guidelines emphasize that minimizing the attack surface requires disabling unused protocols and ensuring that services do not listen on unexpected transport layers.

Implications for Infrastructure Management and Troubleshooting

Misinterpreting the relationship between SSH and its transport layer can lead to costly downtime, security vulnerabilities, or severe administrative lockouts. System administrators must approach firewall provisioning and network troubleshooting with a clear methodology.

Diagnosing Reachability Issues

When an SSH connection hangs or refuses to connect, administrators should systematically verify TCP reachability before altering system configurations or debugging cryptographic keys. Tools like netcat (nc) and nmap provide rapid feedback on whether a TCP socket is open and accepting connections:

# Test TCP reachability on default SSH port 22
nc -zv your-server-hostname 22

# Alternatively, scan port status using nmap
nmap -p 22 your-server-hostname

It is crucial to note that a successful connection test confirms only that the TCP port is reachable through the network path and firewall rules; it does not guarantee that authentication will succeed. A reachable port can still reject a login attempt due to expired credentials, misconfigured public keys (authorized_keys), disabled root logins, or SELinux/AppArmor restrictions. Conversely, if a connection test fails, administrators must inspect whether the SSH daemon (sshd) is actively listening on the expected TCP port and verify that intermediate firewalls are not dropping TCP packets.

Safe Firewall Modification Practices

When modifying firewall rules remotely, administrators must exercise extreme caution to avoid severing their own management access path. Best practices dictate:

1. Never apply untested firewall rules globally without an out-of-band management console (such as a cloud provider’s serial console or IPMI interface) available as a fallback.
2. Explicitly specify TCP when writing configuration scripts or cloud security group templates, avoiding wildcard protocols where possible.
3. Verify custom port bindings: If an SSH daemon has been moved from the default port 22 to a hardened custom port (e.g., port 2222) to evade automated brute-force scripts, ensure that both the firewall rule and the connectivity tests (nc or nmap) are updated to reflect the new port number while retaining the TCP transport protocol.

By maintaining strict adherence to TCP principles for OpenSSH infrastructure, organizations can ensure reliable, secure, and resilient remote administration across all cloud, on-premises, and hybrid environments.