LiveChat 
Support 
SSH Port Explained: Connecting, Changing It, and Whether You Should
The SSH port is the network port that the SSH daemon (`sshd`) listens on for incoming secure-shell connections. By default that port is 22. When you type `ssh user@host` with no extra flags, the client quietly assumes port 22 and opens a connection there. Almost every Linux server, cloud instance, and VPS ships with SSH already bound to this port, which is why it has become one of the most recognizable numbers in systems administration.
Understanding the SSH port matters for three practical reasons: you may need to connect to a server that runs SSH on a non-standard port, you may want to change the port to cut down on log noise, and you absolutely need to coordinate any port change with your firewall so you do not lock yourself out. This guide walks through all of it precisely.
Key Takeaways
• The default SSH port is 22; `ssh user@host` connects there automatically.
• To connect to a different port, use `ssh -puser@host` — this covers both “ssh to a specific port” and “ssh ip port” scenarios.
• Changing the SSH port requires editing `/etc/ssh/sshd_config`, opening the new port in the firewall *first*, restarting `sshd`, and testing in a second session before closing the first.
• Moving off port 22 reduces automated brute-force noise in your logs but is not real security — it is security through obscurity.
• Genuine SSH hardening is key-based auth, disabled root login, and `fail2ban` — these are independent of which port you use.
What is the SSH port and why is it 22?
A port is a numbered endpoint that lets a single server run many network services at once. Each service binds to a port so the operating system knows which incoming packets belong to which application. Web traffic uses 80 and 443, mail uses 25, and the Secure Shell protocol uses port 22.
Port 22 was formally assigned to SSH by the Internet Assigned Numbers Authority (IANA) in 1995, when the protocol’s creator, Tatu Ylönen, requested it. The number sat conveniently between Telnet (23) and FTP (21), the very protocols SSH was designed to replace with encryption. That assignment is why every SSH client and server defaults to 22 to this day.
Because the default is universal, both humans and automated tools assume it. That universality is convenient for you — and equally convenient for the bots that continuously scan the internet probing port 22 for weak credentials.
How do you connect to a specific SSH port?
When SSH is running on the standard port, the connection command is short:
“`bash ssh [email protected] “`
But if the server listens on a non-standard port — say 2222 — you must tell the client explicitly with the `-p` flag:
“`bash ssh -p 2222 [email protected] “`
The `-p` flag specifies the port for the SSH client. This is the answer to both “ssh to a specific port” and “ssh ip port” — you simply place the IP address (or hostname) after the user, and the port after `-p`. A few common variations:
“`bash
ssh -p 2222 [email protected]
scp -P 2222 backup.tar.gz [email protected]:/home/ravi/ “`
Note the inconsistency that trips up many administrators: `ssh` uses a lowercase `-p` for port, while `scp` and `sftp` use an uppercase `-P`. Memorize it once and it stops being a surprise.
To avoid typing the port every time, define a host alias in `~/.ssh/config`:
“` Host myserver HostName 192.0.2.10 User ravi Port 2222 “`
After that, `ssh myserver` connects to the right IP, user, and port automatically. For a deeper look at credentials and connection setup, see .
Why does the default SSH port 22 matter?
The default SSH port matters because of expectations. Tooling, documentation, monitoring agents, CI/CD runners, and firewall templates all assume 22 unless told otherwise. When you keep the default, everything “just works” without extra configuration.
The flip side is exposure. Internet-wide scanners hammer port 22 around the clock. If you watch the authentication log on a fresh public server, you will see a continuous stream of failed login attempts from random IP addresses within minutes of boot:
“`bash sudo journalctl -u ssh | grep “Failed password”
sudo grep “Failed password” /var/log/auth.log “`
This is the noise that motivates many administrators to move SSH off port 22 — which brings us to the most misunderstood decision in SSH administration.
Should you change the default SSH port?
The honest answer: changing the port is optional and cosmetic, not a security control. It is worth doing for one concrete reason and dangerous to do for the wrong one.
Here is the insight that cuts through a decade of conflicting blog advice. Changing the SSH port from 22 is widely recommended but widely misunderstood. It does *not* make you meaningfully more secure — a determined attacker scans all 65,535 ports in seconds with a tool like `nmap` or `masscan` and finds your SSH service regardless of where you hid it. What moving the port *actually* does is cut down the constant, dumb, automated brute-force noise that hammers port 22. Those bots almost never bother to scan other ports first; they just spray port 22 across millions of IPs. So relocating SSH cleans your logs, shrinks `fail2ban`’s workload, and saves a sliver of CPU and bandwidth. That is a real, measurable benefit — for *observability and resource hygiene*, not for security.
The danger is psychological. A non-standard port can lull you into feeling protected and skipping the controls that actually stop attacks. Real SSH security is orthogonal to the port number. It comes from three things:
- Disable password authentication — use SSH keys only. A bot cannot brute-force a key it does not have.
- Disable root login — force attackers to know both a valid username *and* a key.
- Run `fail2ban` — automatically ban IPs after repeated failures, on any port.
Move the port if you want quieter logs. Never let a non-standard port substitute for keys, disabled root login, and `fail2ban`. If you have not set up key-based authentication yet, do that first — see .
How do you change the SSH port safely?
Changing the SSH port is straightforward, but the *order of operations* is critical. Open the firewall before you restart `sshd`, and always keep a working session open until you have confirmed the new port works. Skipping these steps is the classic way to lock yourself out of a remote server.
1. Open the new port in your firewall first.
Do this *before* changing anything in the SSH config. If you change the SSH config first and the firewall blocks the new port, your next connection fails.
“`bash
sudo ufw allow 2222/tcp
sudo firewall-cmd –permanent –add-port=2222/tcp sudo firewall-cmd –reload “`
2. Edit the SSH daemon configuration.
Open `/etc/ssh/sshd_config` and set the `Port` directive:
“`bash sudo nano /etc/ssh/sshd_config “`
“`
Port 2222 “`
You can list two `Port` lines temporarily (`Port 22` and `Port 2222`) so SSH listens on both during the transition — a useful safety net while you confirm the new port works.
3. Validate the configuration before restarting.
“`bash sudo sshd -t “`
If this command returns nothing, the syntax is valid. Fix any reported errors before continuing.
4. Restart the SSH daemon.
“`bash sudo systemctl restart ssh
sudo systemctl restart sshd “`
5. Test in a SECOND session before closing the first.
This is the rule that saves careers. Leave your current SSH session open. From a *new* terminal, connect on the new port:
“`bash ssh -p 2222 [email protected] “`
Only once the new session logs in successfully should you close the original session. If the new port fails, you still have your first session open to diagnose and revert. Once confirmed, you can remove the temporary `Port 22` line and close port 22 in the firewall:
“`bash sudo ufw delete allow 22/tcp “`
SELinux note: On RHEL-family systems with SELinux enforcing, you must also register the new port for the SSH type, or `sshd` will refuse to bind:
“`bash
sudo semanage port -a -t ssh_port_t -p tcp 2222
“`
How do the firewall and SSH port work together?
Your firewall decides which ports accept traffic from the outside world; the SSH port is simply one of those ports. The two must agree. If `sshd` listens on 2222 but the firewall only allows 22, no connection succeeds. This is why every safe port change opens the firewall first.
A minimal, correct firewall posture for SSH allows exactly the port SSH uses and nothing extra:
“`bash
sudo ufw allow 2222/tcp sudo ufw enable sudo ufw status verbose “`
For an extra layer, restrict SSH to known source IPs so only your office or VPN can even reach the port:
“`bash
sudo ufw allow from 203.0.113.5 to any port 2222 proto tcp “`
Source-IP restriction is far more effective than port obscurity — it removes the entire public attack surface. For broader firewall strategy, see .
Running your own SSH server? DarazHost VPS and dedicated servers give you full root SSH access with the freedom to configure your SSH port, firewall, and key-based authentication exactly how you want — the control to harden access properly, with 24/7 support to help you avoid locking yourself out. Whether you keep SSH on port 22 with keys and `fail2ban`, or relocate it for quieter logs, you have complete control over the configuration.
Common SSH ports reference
While 22 is the universal default, you will encounter several conventional choices in the wild. There is no technically “correct” alternative — any unused port from 1024–65535 works — but these recur often enough to recognize.
| Port | Usage | Notes |
|---|---|---|
| 22 | Default SSH | IANA-assigned standard; assumed by all clients |
| 2222 | Common alternative | Popular “obvious” alternate; bots increasingly scan it too |
| 2200 | Alternative | Sometimes used by hosting panels |
| 443 | SSH over HTTPS port | Useful to bypass restrictive outbound firewalls |
| Custom (1024–65535) | Any high port | Best choice for log-noise reduction; avoid well-known service ports |
A quick comparison of what a port change does and does not achieve:
| Goal | Does changing the port help? |
|---|---|
| Reduce automated brute-force log noise | Yes — bots mostly target 22 |
| Stop a targeted attacker | No — they scan all ports in seconds |
| Replace SSH keys | No — keys are non-negotiable |
| Replace `fail2ban` / root-login lockdown | No — these are the real controls |
For the full context on hardening and managing your servers end to end, read our pillar guide: The Complete Guide to Managing Linux Servers.
Frequently asked questions
What is the default SSH port? The default SSH port is 22. It was assigned to the Secure Shell protocol by IANA in 1995 and is the port every SSH client and server uses unless explicitly configured otherwise.
How do I SSH to a specific port? Use the `-p` flag followed by the port number: `ssh -p 2222 [email protected]`. The IP or hostname goes after the username, and the port goes after `-p`. For `scp` and `sftp`, use an uppercase `-P` instead.
Is changing the SSH port more secure? Not meaningfully. Moving SSH off port 22 reduces the volume of automated brute-force attempts hitting your logs, but a determined attacker can scan every port in seconds and find your SSH service. Real security comes from key-based authentication, disabling root login, and running `fail2ban` — not from the port number.
Why won’t I connect after changing the SSH port? The most common cause is a firewall that still blocks the new port. Always open the new port (`ufw allow 2222/tcp` or the firewalld equivalent) *before* restarting `sshd`. On SELinux systems, you must also run `semanage port -a -t ssh_port_t -p tcp 2222`. Test in a second session before closing your working one.
Can I run SSH on more than one port at once? Yes. Add multiple `Port` lines to `/etc/ssh/sshd_config` (for example `Port 22` and `Port 2222`). This is a useful safety measure during a port migration, letting you connect on either port until you confirm the new one works.
