Port 22 (SSH): What It Is, How to Change and Secure It

Port 22 is the default TCP port for SSH (Secure Shell). Every SSH service runs through this single port — remote login, command execution, SFTP and SCP file transfer, port forwarding, and tunneling. When you type ssh user@server, your client connects to port 22 unless you tell it otherwise.

Port 22 is also one of the most scanned ports on the internet. Automated botnets probe it around the clock, trying usernames and passwords. Knowing how port 22 works, how to change it, how to lock it down, and how to troubleshoot it is basic hygiene for anyone who manages servers, network devices, or industrial systems.

This guide goes from the IANA registration down to working firewall rules and sshd_config examples.

• 1. What Is Port 22
• 2. Why Is SSH on Port 22
• 3. IANA Registration Details
• 4. How SSH Uses Port 22
• 5. SSH Connection Sequence
• 6. What Runs on Port 22: SSH Services
• 7. How to Check if SSH Is Listening on Port 22
• 8. How to Change the SSH Port Number
• 9. Firewall Rules for Port 22
• 10. How to Test Port 22 Connectivity
• 11. SSH Port Forwarding and Tunneling
• 12. SFTP and SCP Port Numbers
• 13. Common Port 22 Problems and Fixes
• 14. Security Best Practices for Port 22
• FAQ
• Summary

1. What Is Port 22

Port 22 is the TCP port assigned to the SSH protocol. It is the network entry point where SSH connections land: the server listens on it, the client connects to it, and everything SSH does happens inside that one connection.

SSH replaced older protocols like Telnet (port 23), RSH, and rlogin (port 513) that sent passwords and commands across the network in plain text. SSH encrypts everything — authentication, commands, and data. On a captured port 22 session, an attacker sees only encrypted bytes.

One thing port 22 does not do: provide security by itself. The port number only decides where the TCP handshake lands. All the real security — encryption algorithms, authentication rules, access restrictions — lives in the SSH configuration, not in the number 22.

2. Why Is SSH on Port 22

The number is a piece of internet history. In 1995, Tatu Ylönen wrote SSH at Helsinki University of Technology as a secure replacement for two protocols: Telnet, which held port 23, and FTP, which held ports 20 and 21. Port 22 sat unassigned right between them. Ylönen requested it from IANA, got it, and the number stuck.

So port 22 carries no technical meaning. It was simply the free slot between the two protocols SSH was built to replace.

3. IANA Registration Details

The registration has not changed since 1995. In practice SSH is a TCP-only protocol — the UDP registration exists on paper but no mainstream implementation uses it.

4. How SSH Uses Port 22

SSH is a client-server protocol:

The server always listens. The client always initiates. The server's identity is proven by its host key — a permanent key pair that signs the connection setup so the client knows it reached the right machine and not an impostor.

5. SSH Connection Sequence

Notice the order: encryption starts at step 6 and the server proves its identity before the user does. Your password or key response never crosses the network until the channel is already encrypted and the host is verified.

One version-string detail worth knowing: a banner reporting SSH-1.99 means the server accepts both the broken SSH-1 protocol and SSH-2. That is a downgrade risk. Modern OpenSSH has removed SSH-1 entirely; if a device on your network still offers it, replace the device.

6. What Runs on Port 22: SSH Services

Port 22 carries multiple services over the same encrypted channel:

All of these use the same port 22. No additional ports need to be opened.

7. How to Check if SSH Is Listening on Port 22

Linux

bash

# Check if sshd is listening
ss -tlnp | grep :22
 
# Expected output:
# LISTEN  0  128  0.0.0.0:22  0.0.0.0:*  users:(("sshd",pid=1234,fd=3))
 
# Alternative:
netstat -tlnp | grep :22

Windows (OpenSSH Server)

powershell

netstat -an | findstr :22

Check from a Remote Machine

bash

# Test if port 22 is open
nc -zv 192.168.1.100 22
 
# Or using telnet
telnet 192.168.1.100 22
 
# Or using PowerShell
Test-NetConnection -ComputerName 192.168.1.100 -Port 22

8. How to Change the SSH Port Number

Changing the SSH port reduces automated scanning noise in your logs. Be clear about what it does not do: it is not a security control. Scanners that target you specifically will find the new port in seconds. Change the port to cut log noise, then do the real hardening in section 14.

Step 1. Edit sshd_config

bash

sudo nano /etc/ssh/sshd_config

Find the line:

#Port 22

Change it to (example: port 2222):

Port 2222

The Port keyword can appear more than once. During a migration you can listen on both ports at the same time:

Port 22
Port 2222

Step 2. Allow the New Port in the Firewall

bash

# UFW (Ubuntu)
sudo ufw allow 2222/tcp
 
# firewalld (RHEL/CentOS)
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload
 
# iptables
sudo iptables -A INPUT -p tcp --dport 2222 -j ACCEPT

Step 3. If Using SELinux (RHEL/CentOS)

bash

sudo semanage port -a -t ssh_port_t -p tcp 2222

Step 4. Validate and Restart SSH

bash

# Check the config file for errors before restarting
sudo sshd -t
 
sudo systemctl restart sshd

Step 5. Connect Using the New Port

bash

ssh -p 2222 user@server

ℹ

⚠️ Important: Do not close your current SSH session until you have verified the new port works. Open a second terminal and test the new port first. If the new port does not work, you can still fix it from the original session.

9. Firewall Rules for Port 22

Linux iptables

bash

# Allow SSH from a specific IP
iptables -A INPUT -p tcp -s 192.168.1.10 --dport 22 -j ACCEPT
 
# Block SSH from all other IPs
iptables -A INPUT -p tcp --dport 22 -j DROP

Ubuntu UFW

bash

# Allow SSH
sudo ufw allow 22/tcp
 
# Allow SSH only from a specific subnet
sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp

Windows Firewall (PowerShell)

powershell

# Allow inbound SSH
New-NetFirewallRule -DisplayName "SSH" -Direction Inbound -Protocol TCP -LocalPort 22 -Action Allow
 
# Allow SSH only from a specific IP
New-NetFirewallRule -DisplayName "SSH Restricted" -Direction Inbound -Protocol TCP -LocalPort 22 -RemoteAddress 192.168.1.10 -Action Allow

Cisco IOS ACL

access-list 101 permit tcp host 192.168.1.10 any eq 22
access-list 101 deny tcp any any eq 22

SSH itself can add a second layer on top of the firewall. The AllowUsers keyword in sshd_config accepts user@network patterns, so a specific account can be pinned to a source subnet even if the firewall lets more through:

AllowUsers backup@192.168.1.0/24

10. How to Test Port 22 Connectivity

What the Results Mean

11. SSH Port Forwarding and Tunneling

SSH can forward other protocols through port 22, creating encrypted tunnels.

Local Port Forwarding

Access a remote service (e.g., a database on port 3306) through an encrypted SSH tunnel:

bash

ssh -L 3306:localhost:3306 user@server

Now connect to localhost:3306 on your machine — the traffic is tunneled through SSH to the server's port 3306.

Remote Port Forwarding

Expose a local service through the remote server:

bash

ssh -R 8080:localhost:80 user@server

Now anyone connecting to server:8080 is tunneled to your local machine's port 80.

SCADA Use Case

SSH tunneling is commonly used to secure Modbus TCP (port 502), IEC 104 (port 2404), and OPC UA (port 4840) traffic over untrusted networks — without modifying the SCADA application.

bash

# Tunnel Modbus TCP through SSH
ssh -L 502:192.168.1.100:502 user@gateway

Your SCADA master connects to localhost:502. SSH forwards the traffic to the remote RTU at 192.168.1.100:502 through an encrypted tunnel.

Two server-side keywords control this feature. AllowTcpForwarding enables or disables forwarding entirely, and GatewayPorts decides whether forwarded ports are reachable from other machines or only from localhost. If your users should not be able to proxy arbitrary traffic through your server, set AllowTcpForwarding no and open it per-user with a Match block.

For a permanent site-to-site link, note that SSH tunnels run TCP inside TCP, which behaves poorly under packet loss. They are excellent for on-demand access; for a standing encrypted link, a dedicated VPN is the better tool — see WireGuard vs OpenVPN for SCADA systems.

12. SFTP and SCP Port Numbers

Both SFTP and SCP use the same port as SSH — port 22. They do not use separate ports.

SFTP is not FTP over SSH. It is a completely different protocol that runs as an SSH subsystem on port 22. No additional ports need to be opened for SFTP. Since OpenSSH 9.0, the scp command itself uses the SFTP protocol under the hood — the legacy SCP wire protocol is being retired.

The subsystem is enabled by a single sshd_config line, present by default on most systems:

Subsystem sftp /usr/libexec/sftp-server

A common admin task is giving users file access without shell access. Four lines create SFTP-only accounts locked into their home directories:

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

13. Common Port 22 Problems and Fixes

About the Host Key Warning

The "REMOTE HOST IDENTIFICATION HAS CHANGED" warning means the key the server presented on port 22 does not match the one your client stored from previous connections. Usually the server was reinstalled and generated fresh keys. Sometimes it means someone is intercepting your connection.

Confirm the reason before you continue. If the change is legitimate, remove the stale entry and verify the new fingerprint against the one from the server console:

bash

# Remove the old stored key
ssh-keygen -R server
 
# On the server console: print the fingerprint to compare
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

If the fingerprints match, accept the new key. If they don't, stop and investigate.

14. Security Best Practices for Port 22

Automated brute-force scanning against port 22 never stops. Botnets coordinate so that each attacking IP tries only a few passwords before the next one takes over — which is exactly why blocking individual addresses doesn't solve the problem. Given enough time, a password-authenticated server exposed to the internet will fall. The defense is structural: stop accepting passwords.

Do

• Use SSH key authentication instead of passwords. Generate a modern key with ssh-keygen -t ed25519, protect it with a passphrase, and load it into an SSH agent so you type the passphrase once per work session. A stolen key file without its passphrase is useless — and so is a passphrase without the file.
• Disable password authentication entirely — set PasswordAuthentication no in sshd_config once keys are deployed
• Disable root login — set PermitRootLogin no (or prohibit-password at minimum)
• Restrict access by user — one AllowUsers or AllowGroups entry in sshd_config denies everyone not listed
• Restrict access by IP — firewall rules should allow only trusted networks
• Use fail2ban or similar tools to slow down repeated failed login attempts
• Keep SSH software updated — OpenSSH patches are critical
• Use SSH certificates for large environments — a certificate authority signs user keys with expiry dates, instead of managing authorized_keys files on every host
• Log all SSH sessions — enable logging in sshd_config and monitor with SIEM
• Validate config changes with sshd -t before restarting, and keep a working session open until the new config is verified

Do Not

• Expose port 22 to the internet without IP restrictions
• Use password authentication on internet-facing servers
• Allow root login directly via SSH
• Tolerate SSH protocol version 1 anywhere on the network — it is broken, and a server offering it undermines every client that connects
• Enable agent forwarding toward servers you don't fully trust — a root user on that server can borrow your identity while you're connected; use ProxyJump for multi-hop access instead
• Ignore host key warnings — they can indicate a man-in-the-middle attack
• Treat a changed port number as security — it only reduces log noise

For SCADA/OT Environments

• Place SSH jump servers in a DMZ between IT and OT networks
• Use multi-factor authentication (MFA) for SSH access to industrial systems
• Restrict SSH access to read-only commands where possible (use ForceCommand in sshd_config)
• Disable SSH on field devices that do not need remote access
• Monitor SSH sessions with OT-specific security tools (Claroty, Nozomi, Dragos)

FAQ

Is port 22 TCP or UDP?

Port 22 is a TCP port in practice. IANA registered it for both TCP and UDP in 1995, but SSH runs over TCP, and no mainstream SSH implementation uses UDP on port 22.

Why is SSH assigned to port 22?

SSH was designed in 1995 to replace Telnet (port 23) and FTP (ports 20 and 21). Port 22 was the free number sitting between them, so Tatu Ylönen requested it from IANA. The number has no technical meaning.

Is it safe to leave port 22 open?

Only with restrictions. An internet-facing port 22 with password login will be brute-forced continuously. It is reasonably safe when access is limited to trusted IP ranges, password authentication is disabled, and only key-based login is accepted.

What is the difference between port 22 and port 443?

Port 22 is for SSH: remote login, command execution, and SFTP file transfer. Port 443 is for HTTPS: encrypted web traffic. Both are encrypted, but they carry different protocols. Some admins run SSH on port 443 to pass through networks that block port 22.

Summary

SSH uses TCP port 22 by default. This one port handles remote login, command execution, SFTP file transfer, SCP, and port forwarding — all encrypted.

The key things to remember:

• Port 22 is IANA registered to SSH since 1995 — the number was simply the free slot between Telnet (23) and FTP (21)
• The server listens on port 22. The client connects to port 22.
• SFTP and SCP also use port 22 — no additional ports needed
• To change the port: edit /etc/ssh/sshd_config, update firewall rules, validate with sshd -t, restart sshd
• To test connectivity: use ssh -v, nc -zv, or Test-NetConnection
• Changing the port reduces log noise; keys instead of passwords is what actually secures it
• Never expose port 22 to the internet without IP restrictions and key-only authentication
• SSH tunneling can secure SCADA protocols (Modbus, IEC 104, OPC UA) over untrusted networks