How can I change my SSH port?

What this is#

Moving SSH off the default port 22. It cuts the automated brute-force noise in your logs to near zero, and as a bonus, our network's port-22 SSH firewall no longer applies to you, so a mistyped password can never get your IP banned.

(To be clear about what it is not: it's obscurity, not security. Keep using keys and the rest of the hardening basics, this just quiets the door-rattling.)

One thing has genuinely changed in recent years, and most guides haven't caught up: on newer Ubuntu releases, the port is not always controlled by sshd_config. This page covers both mechanisms, and the order below is arranged so that no step can lock you out.

Where the port is actually set#

There are two mechanisms in the wild:

• The classic one: sshd_config. The SSH daemon listens where the Port line says. This is how it works on Debian, AlmaLinux and Rocky, Ubuntu up to 22.04, and most everything else.
• systemd socket activation: ssh.socket. Starting with Ubuntu 22.10, sshd is started on demand by systemd, and systemd owns the listening port, not sshd. On Ubuntu 22.10 through 23.10, the Port line in sshd_config is ignored outright: you can edit it, restart, see no errors, and SSH keeps listening on 22. From Ubuntu 24.04, socket activation remains, but Ubuntu added a generator that reads the port from sshd_config and applies it to the socket at daemon-reload, so the classic edit works again as long as you reload.

Check which world you're in:

systemctl is-active ssh.socket

active means socket activation; inactive or "could not be found" means classic sshd. If you're unsure, or the output surprises you, simply do both edits below. Setting Port in sshd_config is harmless on a socket-activated system, and the socket drop-in is harmless on a classic one, the two settings don't conflict, and one of them will be the one that counts.

The steps, in an order that can't lock you out#

Throughout, 2222 is the example, pick any free port you'll remember, and stay clear of ports used by your own services.

1. Allow the new port in your firewall, first#

If you run a firewall that currently allows SSH on 22, it knows nothing about your new port, and restarting SSH before the rule exists is the classic self-lockout. Add the allow rule before touching SSH:

# ufw (Ubuntu/Debian)
ufw allow 2222/tcp

# firewalld (Alma/Rocky)
firewall-cmd --permanent --add-port=2222/tcp && firewall-cmd --reload

# raw nftables
nft add rule inet filter input tcp dport 2222 accept

More variants (iptables, and finding out which firewall you're even running) are in allowing SSH in common firewalls. Our managed edge firewall doesn't block custom ports, so there's nothing to change on our side.

Leave the port-22 rule in place for now, remove it only after the new port is proven (last step).

2. Set the port in sshd_config#

Do this on every system, it's the source of truth everywhere except Ubuntu 22.10-23.10, and harmless there:

nano /etc/ssh/sshd_config

Find the #Port 22 line, uncomment it, set your port:

Port 2222

3. Ubuntu with ssh.socket: set the socket too#

If the systemctl is-active ssh.socket check above said active (any Ubuntu from 22.10 on), give the socket the same port via a drop-in:

systemctl edit ssh.socket

In the editor, add:

[Socket]
ListenStream=
ListenStream=2222

The empty ListenStream= line first is deliberate: it clears the inherited port 22, then the second line sets yours. Save and exit.

On Ubuntu 24.04 and later this drop-in is technically optional (the generator picks the port up from sshd_config), but it does no harm, and doing both is the version-proof move.

4. Alma/Rocky: tell SELinux about the port#

On the RHEL family, SELinux only permits sshd to bind to registered SSH ports, and a new port isn't one until you say so, skip this and sshd fails to start with a permission error in its log:

dnf install policycoreutils-python-utils   # if semanage is missing
semanage port -a -t ssh_port_t -p tcp 2222

Debian and Ubuntu don't need this step.

5. Validate, then apply#

First, check your edit the way nginx -t checks a web server config:

sshd -t

Silence means the config parses; an error names the line to fix, before anything restarts. Then apply:

systemctl daemon-reload
systemctl restart ssh        # Debian/Ubuntu
systemctl restart sshd       # Alma/Rocky

The daemon-reload is what makes systemd re-read the socket drop-in, and on Ubuntu 24.04+ it's the moment the generator syncs the port from sshd_config. On classic systems it's a no-op, so it belongs in the sequence unconditionally.

6. Confirm before you trust it#

Two checks, and they answer different questions:

sshd -T | grep -i '^port'

sshd -T prints the effective configuration after parsing sshd_config (and it refuses to run if the config has a syntax error, which makes it a free config test). It should print port 2222.

ss -tlnp | grep ssh

This is the ground truth: what is actually listening right now. You want to see your new port here. On a socket-activated Ubuntu the listener may show as systemd rather than sshd, that's normal, it's the socket holding the port. If sshd -T says 2222 but ss still shows only 22, you're in the socket-activation case and step 3 is the part that's missing.

7. Test from a second terminal, then clean up#

Keep your current session open. From a new terminal:

ssh -p 2222 [email protected]

Only after the new port logs you in: close the old session, and if you want, remove the old firewall allowance (ufw delete allow 22/tcp, or the firewalld/nftables equivalent). From here on, every SSH and SFTP client needs the port set (-p 2222, or the Port field in FileZilla/WinSCP).

Why changing your IP won't stop the scans#

A request we sometimes get instead: "give me a new IP, mine is being scanned." A new IP won't change anything, because the scanning isn't about your IP. Every public IPv4 address is public knowledge, the entire address space is only 4 billion addresses, and modern scanners sweep all of it in under an hour, around the clock. Any address, brand new or decades old, starts receiving SSH probes within minutes of going online. Security folks call it internet background noise: it's the weather, not a targeting decision, and it isn't tied to anything you did.

So the fix is never a different address, it's making the noise irrelevant: move SSH off port 22 as above, use key-only authentication so guesses can't succeed, and let the log noise fall to zero. The same goes for firewalling SSH to your own IPs if your addresses are static.

If it went wrong anyway#

You still have the Console, log in there and fix the config, socket drop-in, or firewall rule at the machine's own keyboard, no SSH needed. The full recovery flow is in How to restore my SSH access.

Still need help?#

You can open a support ticket. So we can help on the first reply, it's worth mentioning:

• the VPS hostname or IP, its OS and version, and the port you moved SSH to,
• what sshd -T | grep -i '^port' and ss -tlnp | grep ssh print,
• whether the Console still gets you in.

Related questions#

• "How do I change my SSH port?"
• "I changed Port in sshd_config on Ubuntu and SSH still listens on 22."
• "What is ssh.socket and why does it ignore sshd_config?"
• "How do I verify which port SSH is actually listening on?"
• "Why won't sshd start on my new port on AlmaLinux or Rocky?"
• "I changed my SSH port and can't connect anymore."
• "Does changing the SSH port improve security?"
• "Do I need to tell you if I move SSH off port 22?"
• "My server is being scanned, can I get a new IP?"
• "Will changing my IP address stop the attacks?"