What port does SSH use? SSH port number explained

SSH uses port 22. That is the default, and unless someone has changed it, every SSH server in the world listens on TCP port 22. When you run ssh user@example.com without specifying a port, your client connects to port 22 on the remote machine.

This applies to everything that runs over SSH. SFTP file transfers, SCP file copies, SSH tunnels, Git over SSH – all of them use port 22 by default because they all run inside an SSH connection. One port for all of it.

This article covers why SSH uses port 22, how to connect when the port has been changed, how to change the SSH port on a server, whether changing it actually improves security, and how to configure your SSH client so you do not have to type the port every time.

Why port 22#

Port 22 was assigned to SSH by the Internet Assigned Numbers Authority (IANA) in 1995 when Tatu Ylonen, the creator of SSH, registered the protocol. The story is straightforward: Ylonen needed an unassigned port number for his new protocol, checked which ports were available in the well-known range (1-1023), and requested port 22. It was between Telnet on port 23 and FTP on port 21. IANA approved the assignment, and SSH has been on port 22 ever since.

Ports 0-1023 are called “well-known ports” or “system ports.” They are reserved for standard services by IANA. Some of the ones you encounter most often:

SSH replaced two older remote access protocols that were both insecure: Telnet (port 23) and rlogin (port 513). Both transmitted everything in plaintext, including passwords. SSH was designed from the start to encrypt the entire session. The fact that SSH sits right next to Telnet in the port numbering is coincidental, but fitting.

How to connect to SSH on a non-standard port#

If the server runs SSH on a different port, you need to tell your SSH client which port to use. The flag is -p (lowercase):

ssh -p 2222 user@example.com

This connects to port 2222 instead of port 22. Common non-standard SSH ports are 2222, 2200, and 22000, but a server can use any available port.

SFTP on a non-standard port

SFTP uses -P (uppercase):

sftp -P 2222 user@example.com

The uppercase/lowercase difference between SSH and SFTP is one of those inconsistencies that exists for historical reasons. SSH uses lowercase -p for port because uppercase -P was not needed for anything else at the time. SFTP uses uppercase -P because lowercase -p was already taken for preserving file timestamps. It is confusing, but it is how the tools work.

SCP on a non-standard port

SCP also uses -P (uppercase), same as SFTP:

scp -P 2222 file.txt user@example.com:/home/user/

See How to transfer files over SSH using SCP for the full SCP reference.

Git over SSH on a non-standard port

Git does not have a port flag for SSH. Instead, you configure the SSH port in your SSH config file (covered below) or use the SSH URL format with the port:

git clone ssh://user@example.com:2222/path/to/repo.git

Note: this uses a colon after the hostname to specify the port, which differs from the standard Git SSH URL format ( user@example.com:path/to/repo.git ). The ssh:// prefix is required when specifying a port.

Using the SSH config file#

Typing -p 2222 every time you connect to a server gets old. The SSH config file lets you set the port (and other options) per host, so you just type ssh myserver and the right settings are applied automatically.

The config file lives at ~/.ssh/config on Linux and Mac. On Windows, it is at C:\Users\YourUsername\.ssh\config . Create it if it does not exist.

Host myserver
    HostName example.com
    User john
    Port 2222

Now you can connect with:

ssh myserver

SSH reads the config file, sees that myserver maps to example.com on port 2222 with username john , and connects accordingly. This also works with SFTP, SCP, and Git – any tool that uses SSH under the hood reads the same config file.

Multiple servers with different ports

Host production
    HostName prod.example.com
    User deploy
    Port 22

Host staging
    HostName staging.example.com
    User deploy
    Port 2222

Host dev
    HostName dev.example.com
    User john
    Port 22
    IdentityFile ~/.ssh/id_ed25519_dev

Each host entry can have its own port, username, and SSH key. The IdentityFile directive specifies which SSH key to use for that connection. See the SSH keys guide for setting up key authentication.

Wildcard entries

You can set defaults that apply to all connections:

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

This sends a keepalive packet every 60 seconds and disconnects after 3 missed responses. It prevents idle connections from being dropped by firewalls or NAT gateways. Wildcard entries go at the bottom of the config file – SSH applies the first matching value for each directive, so specific host entries should come before the wildcard.

How to change the SSH port on a server#

The SSH port is configured in the SSH daemon’s configuration file, typically /etc/ssh/sshd_config on Linux.

Step 1: Edit the configuration

sudo nano /etc/ssh/sshd_config

Find the line:

#Port 22

Uncomment it and change the port number:

Port 2222

Step 2: Allow the new port in the firewall

Before restarting SSH, make sure the new port is open in the firewall. If you restart SSH on the new port and the firewall blocks it, you lock yourself out.

On Ubuntu/Debian with UFW:

sudo ufw allow 2222/tcp

On CentOS/RHEL with firewalld:

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

Step 3: Restart the SSH service

sudo systemctl restart sshd

Step 4: Test the new port

Open a new terminal and connect on the new port:

ssh -p 2222 user@example.com

Do not close your existing SSH session until you have confirmed the new port works. If something went wrong, you still have the old session to fix it.

Step 5: Optionally close the old port

Once the new port is confirmed working, you can remove port 22 from the firewall:

sudo ufw delete allow 22/tcp

On managed hosting

On managed hosting platforms, the SSH port is typically configured by the hosting provider, not by the user. On Hostney, SSH runs on port 22 and is accessible through the connection details shown under Terminal Access in the control panel. Each account’s SSH access runs inside an isolated container, so there is no need to change the port for security – the container architecture handles isolation at a deeper level than port obscurity.

Does changing the SSH port improve security#

This is a common recommendation that needs context.

What changing the port does

Moving SSH to a non-standard port reduces automated scanning noise. The vast majority of SSH brute force bots scan port 22 exclusively. They are not looking for your server specifically – they sweep entire IP ranges on port 22, trying common username/password combinations. If your SSH is on port 2222, these bots never find it. Your auth logs get quieter. That is the real benefit.

What changing the port does not do

Changing the port does not make SSH more secure in any meaningful way. It is obscurity, not security. A targeted attacker will port scan your server and find SSH on whatever port it is running. Tools like nmap identify SSH by its protocol banner regardless of the port number. A full port scan takes seconds.

Changing the port also does not protect against:

• Compromised SSH keys
• Weak passwords (if password authentication is enabled)
• Vulnerabilities in the SSH daemon itself
• Authenticated users doing things they should not

What actually secures SSH

SSH key authentication. Disable password authentication entirely and require SSH keys. A 256-bit Ed25519 key cannot be brute forced. This eliminates the entire class of attack that port changing is supposed to address. See the SSH keys guide for setup.

Fail2ban or equivalent. Automatically ban IPs after a number of failed login attempts. This stops brute force attacks even if SSH is on port 22.

Firewall rules. Restrict SSH access to known IP addresses if your use case allows it. If only three IPs need SSH access, only allow those three.

Keep OpenSSH updated. Security patches matter. An unpatched SSH daemon on port 2222 is less secure than a patched one on port 22.

The practical recommendation

If you manage your own server, changing the SSH port is fine as a noise reduction measure. It is easy to do and it makes your logs cleaner. But do not treat it as a security control. Implement key-based authentication, fail2ban, and firewall rules first. Those are the things that actually protect SSH.

On managed hosting, the provider typically handles SSH security at the infrastructure level. On Hostney, SSH brute force attempts are caught by the bot detection system before they reach your container, and SSH key authentication is the only supported method. Changing the port is unnecessary because the actual security controls are in place.

SSH port and firewalls#

Firewalls are the most common reason SSH connections fail. If port 22 (or whatever port SSH uses) is blocked between you and the server, the connection times out or is refused.

Common firewall scenarios

Corporate networks often block outbound port 22. If you cannot connect to SSH from your office network but can from home, the corporate firewall is likely blocking port 22. Running SSH on port 443 (the HTTPS port) sometimes works as a workaround because port 443 is almost never blocked – but this only works if the server is not already running HTTPS on port 443.

Cloud provider security groups (AWS, GCP, Azure) default to blocking all inbound traffic. You must explicitly allow inbound TCP on port 22 (or your custom SSH port) in the security group or network ACL.

UFW, firewalld, iptables on the server itself can block SSH if misconfigured. This is the most dangerous scenario – if you change the SSH port and forget to allow the new port in the firewall before restarting SSH, you lock yourself out. Always open the new port before closing the old one.

Diagnosing port issues

If SSH is not connecting, check whether the port is reachable:

nc -zv example.com 22

If this returns “Connection refused,” the server is reachable but nothing is listening on port 22 (SSH might be on a different port, or the SSH service is not running).

If this hangs and times out, a firewall is blocking the connection somewhere between you and the server.

telnet example.com 22

Works the same way. If the port is open, you see the SSH banner ( SSH-2.0-OpenSSH_... ). If it is blocked, the connection hangs.

Ports used by related protocols#

SSH is not the only protocol with a well-known port. Here is how the ports relate across protocols you are likely to encounter alongside SSH:

SFTP and SCP both use port 22 because they both run inside SSH. They are not separate services with their own ports – they are subsystems and utilities of SSH. If you change the SSH port, SFTP and SCP follow automatically. For details on how these tools compare, see What is SFTP and how does it work and the SFTP commands reference.

SSH port on Hostney#

On Hostney, SSH runs on port 22. Your connection details are shown in the control panel under Terminal Access.

Connect using:

• Host: your server hostname from the control panel
• Port: 22
• Username: your account username
• Authentication: SSH key (configured through the SSH Keys section in the control panel)

ssh user@your-server.hostney.com

SFTP and SCP use the same port and the same credentials:

sftp user@your-server.hostney.com
scp file.txt user@your-server.hostney.com:/var/www/html/

SSH key authentication is required. Password authentication is not available. This eliminates brute force attacks against SSH entirely – there is no password to guess.

Summary#

SSH uses TCP port 22 by default. SFTP and SCP use the same port because they run inside SSH. You can change the SSH port on a server by editing sshd_config , but this is a noise reduction measure, not a security control. The things that actually secure SSH are key-based authentication, fail2ban, firewall rules, and keeping OpenSSH patched. Use the SSH config file at ~/.ssh/config to save per-host port settings so you do not have to type them every time.