How to Allow SSH Through UFW on Ubuntu

To allow SSH through UFW on Ubuntu, add a rule for the port your SSH server actually uses before enabling the firewall. Keep your current session open, confirm the saved rule, and test a new login after enabling UFW.

The OpenSSH application profile may cover a default installation; a custom SSH port needs a matching rule. The steps below show how to choose between them, check the configuration, and preserve a recovery path if access fails.

Key takeaways

• Add the SSH rule before enabling UFW on a remote VPS.
• Use sudo ufw allow OpenSSH when the OpenSSH application profile matches your server.
• Use a port-specific rule such as sudo ufw allow 2222/tcp if SSH listens on a custom port.
• Keep the current SSH session open while testing a second session.
• Confirm sudo ufw status verbose before and after enabling the firewall.
• For related access tasks, read the Virtarix guides to generating SSH keys, securing a VPS, VPS security, and systemctl basics.

Before you enable UFW

Do these checks first:

1. Confirm you are logged in over SSH and the session is stable.
2. Confirm which port SSH actually listens on.
3. Decide whether you will use the OpenSSH application profile or a port rule.
4. Add the rule.
5. Enable UFW only after the rule exists.
6. Test a new SSH login before closing the original session.

If you are working through a hosting console, keep that console available too. It gives you a recovery path if you make a firewall mistake.

Step 1: check UFW status

Run:

sudo ufw status verbose

If UFW is inactive, that is normal on many fresh Ubuntu servers. You can still add rules before enabling it. If UFW is already active, be more careful: changing rules can affect live traffic immediately.

When UFW is active, verbose status shows its rules and default policies. When it is inactive, status does not list the saved rules; use sudo ufw show added to inspect those before enabling it. Save the relevant output in your maintenance notes.

Step 2: check available application profiles

Ubuntu packages can provide UFW application profiles. Check whether OpenSSH is listed:

sudo ufw app list

If OpenSSH appears, inspect it with sudo ufw app info OpenSSH and compare its port with the actual SSH listener. Allow the profile only when they match. A profile does not automatically follow a custom port configured in the SSH service.

Step 3: allow SSH with the OpenSSH profile

Run:

sudo ufw allow OpenSSH

This adds a rule for the OpenSSH application profile. It is clearer than a bare service name because it matches the profile name shown by ufw app list.

Before enabling UFW, inspect the saved rule:

sudo ufw show added

Look for the OpenSSH allow rule in the saved configuration. If UFW is already active, also check sudo ufw status verbose to inspect the running firewall.

Step 4: allow a custom SSH port instead

If you changed SSH to a custom port, allow that port explicitly. For example:

sudo ufw allow 2222/tcp

Replace 2222 with your real SSH port. Do not copy a custom-port example unless it matches the active SSH server configuration. If SSH listens on a different port, UFW will faithfully allow the wrong port and block the real one when the firewall becomes active.

After adding the rule, inspect the saved configuration:

sudo ufw show added

Confirm that the allow rule names your actual TCP port. When UFW is active, check sudo ufw status verbose as well.

Step 5: enable UFW safely

Before enabling UFW, confirm the SSH rule and any other inbound services the server must provide, such as HTTP and HTTPS. Enabling the firewall can affect those services too. Once the required rules and recovery access are ready, enable it:

sudo ufw enable

Read the warning carefully. On a remote VPS, enabling the firewall can disrupt existing connections if rules are wrong. Because you added the SSH rule first, the risk is lower, but you still need to test.

After enabling, check status again:

sudo ufw status verbose

Confirm that UFW is active and the SSH rule remains allowed.

Step 6: test a second SSH session

Do not close the original terminal yet. Open a new terminal and connect again using the expected port. If you use the default port, connect normally. If you use a custom port, specify that port in your SSH client.

A successful new login confirms access from that client over the tested address and port. Test other required paths, including IPv6 where used. If a login fails, keep the first session or recovery console open while you inspect the rules.

Lockout recovery checklist

If you accidentally block SSH, use the safest available recovery channel:

• Use the provider console if available.
• Check UFW status from the console.
• Add the correct SSH rule.
• Disable UFW temporarily only if you need emergency access.
• Re-enable it after the rule set is correct.

Do not repeatedly guess from a disconnected client. You need a console or an existing session to repair the firewall safely.

Common mistakes

Enabling UFW before allowing SSH

This is the classic lockout pattern. Add the SSH rule first, then enable UFW.

Allowing the wrong port

If the SSH daemon uses a custom port, ufw allow OpenSSH may not match your actual configuration. Confirm the SSH server port before choosing the rule.

Closing the only working session too early

Test a new login before closing your original session. An established connection can continue working even when the rules prevent new ones.

Forgetting IPv6

If IPv6 is enabled on the server, confirm your firewall policy matches your access requirements. UFW can manage IPv4 and IPv6 rules when configured for both.

When to use the service name instead of a port

Use the OpenSSH profile when the server follows the packaged Ubuntu OpenSSH setup and you have not moved SSH to a custom listener. Use the explicit TCP port rule when the SSH daemon has been changed, when you inherited an older server, or when documentation says remote access uses a non-standard port. The rule should describe the real listener, not the habit you use on other servers.

VPS-safe UFW checklist

Before you finish, confirm:

1. UFW status was checked before changes.
2. The OpenSSH profile or correct custom TCP port was allowed.
3. UFW was enabled only after the SSH rule existed.
4. A second SSH login succeeded.
5. The original session stayed open during testing.
6. The final rule list was saved in your notes.

This makes the change auditable and gives the next administrator enough context to understand why the rule exists.

FAQ

What is the command to allow SSH through UFW?

Use sudo ufw allow OpenSSH for the OpenSSH application profile, or use sudo ufw allow 2222/tcp if SSH listens on a custom TCP port.

Should I enable UFW before allowing SSH?

No. Add the SSH allow rule first, then enable UFW, then test a second SSH login before closing your original session.

How do I check if UFW allows SSH?

When UFW is active, run sudo ufw status verbose and look for the matching allow rule. Before enabling an inactive firewall, inspect saved rules with sudo ufw show added. Then test a new SSH connection after enabling it.

What if I changed the SSH port?

Allow the actual SSH port with a TCP rule. Do not rely on the default profile unless it matches your server configuration.

Summary

Match the UFW rule to the SSH listener, inspect saved rules before enabling the firewall, and test a new connection afterward. Record the final rules and recovery method so the next administrator can understand and maintain the setup.