SSH Uses TCP, Not UDP: What to Allow Through Your Firewall

If a firewall rule asks whether SSH should use TCP or UDP, choose TCP. Standard OpenSSH connects over TCP, usually on port 22. That applies to remote shells as well as file transfers made with SFTP or SCP.

The distinction matters when you configure a host firewall, router, or cloud security group: allowing UDP 22 does not enable a normal SSH connection.

The practical firewall rule

For a typical SSH server, allow inbound TCP on port 22. If the server listens on a custom port, use that port number instead; the transport is still TCP.

Connection	Transport	Typical port
Standard OpenSSH	TCP	22
SFTP or SCP over SSH	TCP	The SSH server's port, usually 22
UDP port 22	Not used by a standard OpenSSH server	—

A cloud firewall or security group may ask you to specify the protocol separately from the port. Set the protocol to TCP, then enter 22—or your configured SSH port. You generally don't need a UDP rule for SSH itself.

If you're checking the basics of what port 22 means for SSH, remember that the port number alone isn't the whole rule: the transport matters too.

Check whether the TCP port is reachable

From a client machine, you can test whether a TCP connection to port 22 succeeds:

nc -zv your-server 22

If you have nmap installed, you can also run:

nmap -p 22 your-server

These checks test TCP reachability; they don't prove that SSH authentication will succeed. A reachable port can still reject a login because of credentials, account restrictions, or server configuration. If you use a non-default SSH port, replace 22 in the test with that port.

A failed connection test also doesn't automatically mean you need a UDP rule. Check whether the SSH server is listening on the expected TCP port and whether the firewall or network path allows it. When changing firewall rules remotely, make sure you don't remove the access path you need to manage the server.

Why TCP fits SSH

SSH carries an ordered stream of data. TCP handles delivery and ordering for that stream, so the SSH client and server can exchange terminal input, command output, and file-transfer data in sequence.

UDP does not provide the same built-in delivery and ordering guarantees. If data arrives out of order or goes missing, the application has to deal with that itself. Standard SSH isn't a UDP-based service with a separate recovery layer; OpenSSH uses TCP for its connection.

That transport also carries SFTP and SCP sessions. They don't require separate UDP ports just because they're transferring files: they run through SSH, using the SSH connection's TCP transport.

What about tunnels and other tools?

Standard SSH port forwarding—such as -L, -R, and -D—doesn't turn the SSH connection into a general-purpose UDP tunnel. Those forwarding options carry TCP connections through SSH. The SSH connection itself remains TCP.

If you need to carry UDP-based traffic, that requires a different approach; opening UDP 22 won't make ordinary SSH forwarding handle it. The distinction between SSH tunnels and the traffic they forward is useful when you're deciding which firewall rules a particular setup needs.

Some tools associated with remote shells do use UDP, but that doesn't change the transport used by standard OpenSSH. For example, Mosh starts with an SSH connection for authentication, then uses a UDP-based connection for its session. If a remote-terminal tool asks for UDP access, check which tool and traffic it refers to rather than assuming it's an OpenSSH requirement.

The IANA registry can be confusing

A port registry can list a service name for more than one transport. That registration doesn't mean a common server implementation listens on every listed transport. In particular, seeing an SSH entry associated with UDP does not mean a standard OpenSSH server is accepting SSH over UDP.

For day-to-day firewall configuration, use the behavior of the SSH implementation you actually run: standard OpenSSH uses TCP, by default on port 22.

A quick troubleshooting checklist

When SSH won't connect, check the protocol and port before changing unrelated rules:

1. Confirm the server is configured to listen on the port you're testing.
2. Allow inbound TCP to that port in the relevant firewall or security group.
3. Test TCP reachability from the client with nc or nmap.
4. If the port is reachable but login fails, investigate SSH authentication and server access settings separately.

For a normal SSH, SFTP, or SCP connection, the key takeaway is simple: use TCP, not UDP.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.