Short answer: SSH runs over TCP, not UDP, and this is not an arbitrary choice by its designers but a direct consequence of the job the remote server management protocol does. The difference between TCP and UDP explains why SSH behaves predictably even on an unstable link.
SSH runs over TCP
The SSH protocol was designed from the start on top of TCP and uses port 22 specifically as a TCP port. Any SSH connection starts with establishing a TCP session with a packet exchange for synchronization, and only on top of that does the encryption and authentication of SSH itself unfold.
Why TCP and not UDP
The choice of protocol comes down to what guarantees it provides at the transport layer.
| Property | TCP | UDP |
|---|---|---|
| Packet delivery | Guaranteed, with retransmission on loss | Not guaranteed |
| Packet order | Always preserved | Not guaranteed |
| Connection setup | Yes, via a three-way handshake | No, packets are sent right away |
| Typical use | SSH, HTTP, file transfer | DNS, video streams, games |
An SSH session is a continuous stream of commands and their results, where losing or reordering packets is unacceptable: if part of a command were silently lost, it could lead to a garbled command being executed on the server. TCP takes that guarantee on itself, so the SSH protocol does not need to implement it on its own.
The SSH port and how to check it
The standard SSH port is 22, and you can confirm that the service listens specifically on TCP right on the server.
ss -tlnp | grep ssh
# Example output:
# LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=842,fd=3))The letter t in the -tlnp flag stands for TCP exactly — for UDP services the -u flag is used, and the output for sshd would show nothing there, because the service does not listen on UDP.
Are there alternatives to SSH over UDP
There is no direct alternative to SSH on UDP, but there are related tools that use UDP for resilience against packet loss on mobile and unstable networks — for example, mosh, which synchronizes terminal state over UDP instead of transmitting a raw stream of commands. That is a separate protocol, not a version of SSH, and for initial authentication it still reaches out to regular SSH over TCP, which is covered in detail in the article about connecting to a VDS over SSH.
What this means for firewall configuration
Since SSH runs over TCP, the firewall rule for port 22 needs to be written specifically for TCP traffic — opening the same port number for UDP accomplishes nothing and is not required. This is worth keeping in mind when hardening server settings, covered in detail in the article about hardening sshd_config, and when working with access keys, described in the piece about SSH keys for a VDS.
What to do: how to check and protect the SSH port
A few checks are enough to make sure SSH is configured correctly and reachable only by those who need it.
- Check with ss -tlnp that sshd listens on port 22 specifically over TCP, rather than being hung or not running at all.
- Make sure the firewall rule for port 22 allows TCP traffic from the right addresses instead of blocking it by mistake.
- Disable password login in favor of SSH keys if that has not been done yet.
- Check the connection log for suspicious login attempts from unfamiliar addresses.
Frequently asked questions
Can SSH be made to run over UDP?
No, the SSH protocol itself is defined on top of TCP, and a standard sshd cannot listen on a UDP port for regular sessions. Tools like mosh that use UDP implement their own protocol on top of it rather than switching SSH to a different transport.
Why does SSH sometimes hang on an unstable Wi-Fi connection?
An SSH TCP connection keeps session state, and after a long network interruption it does not recover automatically — you have to reconnect. Tools built over UDP appeared exactly for such conditions, surviving a connectivity drop without losing the session.
Do I need to open UDP port 22 in the firewall for SSH?
No, this is not required and has no effect: sshd does not listen on UDP on any port, so a rule for UDP/22 stays dead and does not affect SSH. A correct rule for TCP/22 is enough.