The safe order
sudo ufw allow OpenSSH
sudo ufw show added
sudo ufw enable
sudo ufw status
While ufw is off, ufw status shows only Status: inactive and hides your rules. That is why you use show added to check them.
Over SSH, ufw enable warns that it may disrupt connections and asks for confirmation. The manual warns that enabling may drop existing connections. In our test the open session kept working, but do not rely on that.
What happens if you get it wrong
The default policy is to deny incoming traffic. We enabled ufw with no SSH rule, and the next connection failed like this:
ssh: connect to host server port 22: Connection timed out
Your open session is your way back: add the rule from there. If it is gone, you need the console from your hosting provider. A cloud firewall in front of the server is a separate thing, and ufw cannot open it.
A safety net for remote servers
Before enabling ufw, schedule a command that turns it off again:
sudo systemd-run --on-active=5min --unit=ufw-undo ufw --force disable
sudo ufw enable
Test a new connection from another terminal. If it works, cancel the timer:
sudo systemctl stop ufw-undo.timer
If you get cut off, wait about six minutes, since the timer can run up to a minute late, and ufw turns itself off.
Which rule to use
| You want | Command |
|---|---|
| Standard port | sudo ufw allow OpenSSH |
| Same, without the profile | sudo ufw allow 22/tcp |
| Another port | sudo ufw allow 2222/tcp |
| Only from one address | sudo ufw allow from 203.0.113.10 to any port 22 proto tcp |
| Limit repeated connections | sudo ufw limit OpenSSH |
The profile OpenSSH always means port 22. To see it, run sudo ufw app info OpenSSH. It comes with the openssh-server package, so without that package the name is unknown.
What limit does
ufw limit denies an address that opens 6 or more connections within 30 seconds. In our test, five logins in a row worked and the sixth failed with this:
ssh: connect to host server port 22: Connection refused
This also hits you. A loop of scp commands or an Ansible run that opens many connections will trip it, and the message looks as if sshd has stopped. Reusing one connection helps: see SSH multiplexing.
It slows down password guessing, but it does not know whether a login succeeded. For that, use fail2ban. The real protection against guessing is having no password login.
Changing the SSH port
Add the new rule first, and remove the old one only after you have logged in on the new port:
sudo ufw allow 2222/tcp
# change the port in sshd and test it
sudo ufw delete allow OpenSSH
The whole procedure, including the socket on recent Ubuntu, is in how to change the SSH port.
Removing a rule
By number, or by repeating the rule after delete:
sudo ufw status numbered
sudo ufw delete 2
sudo ufw delete allow 22/tcp
Rules are listed twice, for IPv4 and IPv6, and numbers shift after each delete, so list them again before deleting another. Also, a rule made with allow OpenSSH and one made with allow 22/tcp are separate entries, so you can end up with both.
Questions
How do I check if ufw allows SSH?
Run sudo ufw status while ufw is active and look for 22/tcp, OpenSSH or your own port with ALLOW. While ufw is inactive, status hides the rules, so use sudo ufw show added.
What is the difference between ufw allow ssh and ufw allow OpenSSH?
ufw allow ssh uses the port from /etc/services and shows as 22/tcp. ufw allow OpenSSH uses the application profile installed by the openssh-server package, also for 22/tcp. Either works. Neither follows a port you changed in sshd_config.
Does ufw protect ports published by Docker?
No. Docker's documentation says published container ports bypass ufw rules.