SSH Port: Default Settings, How to Change It, and Security Tips

The default SSH port is 22. Every Linux server in the world listens on port 22 for SSH connections unless someone has changed it. This is one of those things that most people never think about until they need to troubleshoot a connection problem, set up a firewall rule, or harden their server against automated attacks.

This guide covers everything you need to know about the SSH port. What it is, why it matters, how to change it, and whether changing it actually improves security. If you manage a VPS or dedicated server, understanding SSH ports is fundamental to keeping your server accessible and secure.

SSH stands for Secure Shell. It is a network protocol that lets you connect to a remote server securely over an encrypted connection. When you open a terminal and type a command to connect to your server, your computer reaches out to the server on a specific port number. By default, that port is 22.

Think of ports like apartment numbers in a building. The building is your server, and each port is a door to a different service. Port 80 is where web traffic goes. Port 443 handles encrypted web traffic. Port 22 is where SSH lives. When your SSH client connects to your server, it knocks on port 22 and the SSH daemon answers.

Port 22 was assigned to SSH by the Internet Assigned Numbers Authority, also known as IANA. This happened back in 1995 when Tatu Ylonen created SSH as a secure replacement for older protocols like Telnet and rlogin, which sent everything including passwords in plain text.

Because every attacker on the internet knows that SSH runs on port 22, it is the first port they target. Automated bots scan millions of IP addresses every day, looking for servers with port 22 open. When they find one, they try common usernames and passwords in what is called a brute force attack.

If you have ever checked your server's authentication logs, you have probably seen thousands of failed login attempts from IP addresses you do not recognize. These are bots trying combinations like root/password, admin/123456, and other common credentials. On a typical VPS, these attempts start within minutes of the server going online.

This does not mean port 22 is inherently insecure. SSH itself is extremely secure when configured properly. The encryption is strong, and if you use SSH keys instead of passwords, brute force attacks are essentially impossible. But the constant barrage of login attempts fills up your logs, wastes server resources, and creates noise that can make it harder to spot a real attack.

If you are not sure which port your server's SSH daemon is listening on, there are a few ways to check.

Method 1: Check the SSH config file. The SSH daemon configuration lives at /etc/ssh/sshd_config on most Linux distributions. Open it with a text editor and look for a line that says Port followed by a number. If the line is commented out with a hash symbol at the beginning, the server is using the default port 22.

Method 2: Check active listeners. Run the command ss -tlnp or netstat -tlnp to see which ports have services listening on them. Look for the sshd process and note the port number next to it.

Method 3: Check from outside. If you can connect to your server, the port is whatever you used in your SSH command. If you did not specify a port, it connected on 22.

Changing the SSH port is straightforward, but you need to be careful. If you change the port and something goes wrong, you could lock yourself out of your server. Always keep your current SSH session open while testing the new configuration.

Open the SSH daemon configuration file with a text editor. You need root privileges for this. Navigate to /etc/ssh/sshd_config and find the line that says Port 22. If it is commented out, remove the hash symbol. Change 22 to your desired port number. Good choices are high numbered ports between 1024 and 65535 that are not used by other services. Common alternatives include 2222, 2200, or a random number like 34821.

Before restarting SSH, make sure your firewall allows connections on the new port. If you are using UFW, which is common on Ubuntu, add a rule to allow the new port. If you are using firewalld on CentOS or RHEL, add the port to your active zone. If you skip this step and restart SSH, the firewall will block connections on the new port and you will be locked out.

If you are running Ubuntu on your VPS, UFW is the default firewall and the easiest to configure for SSH port changes.

If your server runs CentOS, RHEL, or AlmaLinux with SELinux enabled, you need to tell SELinux about the new SSH port. SELinux has a strict policy about which ports services can use, and SSH is only allowed on port 22 by default. Use the semanage command to add your new port to the allowed list. If you skip this step, SELinux will block SSH from binding to the new port even if the configuration file is correct.

With the firewall updated and SELinux configured if applicable, restart the SSH daemon. The service name is sshd on most distributions. After restarting, do not close your current SSH session. Open a new terminal window and try connecting on the new port. If it works, you are good. If it does not, you still have your original session to troubleshoot.

Connect to your server using the new port by specifying it in your SSH command with the -p flag. If you can log in successfully, the change is working. Now try connecting on the old port 22 to confirm it is no longer accepting connections. Once you have verified everything works, you can close your original session.

When you change the SSH port, you need to specify it every time you connect. In the terminal, add the -p flag followed by the port number to your SSH command. For example, if you changed the port to 2222, your connection command would include -p 2222.

If you use an SSH config file on your local machine, you can save the port setting so you do not have to type it every time. Create or edit the file at ~/.ssh/config on your local machine and add an entry for your server with the Host, HostName, Port, and User fields. After saving this, you can connect using just the host alias without specifying the port manually.

For graphical SSH clients like PuTTY on Windows, there is a port field in the connection settings. Change it from 22 to your custom port before connecting. You can save the session so the port is remembered for future connections.

If you prefer a graphical remote desktop instead of command line SSH, a Windows RDP server gives you full desktop access through Remote Desktop Protocol, which uses port 3389 by default.

This is one of the most debated topics in server administration. The short answer is that changing the SSH port reduces noise but does not provide real security. Here is why.

Changing the port is a form of security through obscurity. It hides the SSH service from casual scans and automated bots that only check port 22. This dramatically reduces the number of brute force attempts in your logs. Some administrators report a 99 percent drop in failed login attempts after changing the port. That is a real benefit in terms of log cleanliness and reduced resource waste.

However, a determined attacker will find your SSH port regardless. A full port scan of all 65,535 ports takes seconds with modern tools. If someone is specifically targeting your server, changing the port buys you almost nothing. The real security comes from proper authentication and access controls.

This is the single most important thing you can do. SSH keys use public key cryptography, which is virtually impossible to brute force. Generate a key pair on your local machine, copy the public key to your server, and disable password authentication entirely. With this setup, even if an attacker finds your SSH port, they cannot get in without your private key file.

Never allow direct root login over SSH. Create a regular user account, give it sudo privileges, and set the PermitRootLogin option to no in your SSH configuration. This way, even if someone compromises a password, they do not get immediate root access.

Fail2Ban monitors your authentication logs and automatically blocks IP addresses that have too many failed login attempts. After a configurable number of failures, the offending IP gets added to your firewall's block list for a set period. This stops brute force attacks in their tracks without requiring you to change the SSH port.

If you always connect from the same IP address or a small range of addresses, configure your firewall to only allow SSH connections from those IPs. This is the most effective protection possible because it makes your SSH port invisible to everyone except your approved addresses.

SSH vulnerabilities are rare but they do happen. Keeping your SSH daemon updated ensures you have the latest security patches. On most Linux distributions, regular system updates include SSH updates automatically.

For a detailed walkthrough of securing a fresh server, check out our Ubuntu server setup guide which covers SSH hardening, firewall configuration, and more.

If you get a connection refused error, the SSH daemon is not listening on the port you are trying to connect to. This usually means the port number is wrong, the SSH service is not running, or a firewall is blocking the connection. Check the SSH configuration file to verify the port, make sure the sshd service is running, and confirm your firewall rules allow the port.

A timeout means your connection request is not reaching the server at all. This is almost always a firewall issue. Either the server's firewall is blocking the port, or a network firewall between you and the server is dropping the packets. Check both your server's firewall rules and any security groups or network ACLs if your server is behind a cloud provider's network layer.

If you changed the SSH port and cannot connect, you need an alternative way to access your server. Most VPS providers offer a web based console or VNC access through their control panel. Use that to log in and fix the SSH configuration. This is why it is critical to test the new port before closing your existing session.

If SSH fails to start after changing the port, another service might already be using that port number. Check which process is using the port with the ss or netstat command. Choose a different port that is not in use. Avoid well known ports below 1024 that are reserved for standard services.

If you run Docker containers on your server, be aware that Docker can bypass your firewall rules. Docker modifies iptables directly, which means a container that exposes port 22 could conflict with your SSH daemon. If you change your SSH port and later deploy a container that uses port 22, there should be no conflict. But if you are running SSH on a non standard port and a container tries to use that same port, one of them will fail to bind.

The best practice is to keep your SSH port separate from any ports used by Docker containers. Document your SSH port somewhere accessible so you do not forget it when configuring container port mappings.

SSH ports are not just for logging into servers. SSH supports port forwarding, which lets you create encrypted tunnels between your local machine and the server. This is useful for accessing services that are only available on the server's local network, like a database that only listens on localhost.

Local port forwarding maps a port on your local machine to a port on the remote server. For example, you can forward your local port 3306 to the server's MySQL port, letting you connect to the remote database as if it were running locally. Remote port forwarding does the opposite, making a local service accessible through the remote server.

Port forwarding works regardless of which port SSH itself runs on. You just need to specify the correct SSH port when setting up the tunnel.

• Document your SSH port. If you change it from 22, write it down somewhere secure. Getting locked out because you forgot the port is embarrassing and avoidable.
• Use SSH keys and disable password authentication. This is more important than any port change.
• Keep port 22 open during transitions. When changing ports, allow both the old and new port until you have confirmed the new one works.
• Use a port above 1024. Ports below 1024 are privileged and reserved for well known services. Higher ports are less likely to conflict with other software.
• Do not use obvious alternatives. Ports like 2222 or 222 are the first ones attackers check after 22. A random high port like 48291 is better if obscurity is your goal.
• Update your firewall first. Always add the new port to your firewall before changing the SSH configuration. The order matters.
• Test before closing your session. Never close your existing SSH connection until you have verified the new port works from a separate terminal.

For most VPS users, the practical approach is to keep SSH on port 22 and focus on real security measures. Use SSH keys, disable password authentication, install Fail2Ban, and keep your system updated. These steps make your server secure regardless of which port SSH runs on.

If the noise from automated scans bothers you or you want an extra layer of obscurity, changing the port is a quick and harmless addition to your security setup. Just remember that it is a supplement to proper security, not a replacement for it.

Whether you keep the default port or change it, a Linux VPS gives you full root access to configure SSH exactly the way you want, with the performance and uptime of data center hosting.

Ready to Deploy?

Get a high performance VPS with instant setup, full root access, and 24/7 support.