When people spin up a fresh Ubuntu 16.04 server, there’s one mistake I see a lot: rushing in, changing SSH ports, poking at firewalls, and then… boom, you lock yourself out of your own box.

If that sounds familiar, don’t worry. You’re not the first, and you won’t be the last.

In this guide, I’ll walk you through a practical initial setup flow for Ubuntu 16.04 that keeps you logged in and gives you a safer base without over-complicating things. We’ll focus on SSH access, a simple firewall, and one important thing: not breaking your server while you “secure” it.

---

Who This Is For (And What We’re Doing)

This is for you if:

• You’ve just created a new Ubuntu 16.04 server (VPS, cloud instance, whatever).
• You connect via SSH and want basic security without reading a 50-page manual.
• You don’t want to accidentally lock yourself out.

What we’ll cover, step by step:

1. Connect as root (if that’s what your host uses by default).
2. Create a regular user with sudo privileges.
3. Adjust SSH so you don’t rely on root logins.
4. Set up a simple firewall and avoid a nasty SSH lockout.

We’ll not be changing the default SSH port here, for a reason I’ll explain in a bit.

---

Step 1: Log In and Add a Sudo User

On many fresh servers, your host gives you a root login via SSH. That’s convenient but a bit risky long term.

Still, first login is usually:

ssh root@your_server_ip

Once you’re in, create a regular user you’ll actually use day-to-day. I’ll call it deploy in this example, but pick any name you like:

adduser deploy

Ubuntu will ask for a password and a few details. You can skip the personal info by just pressing Enter.

Now add that user to the sudo group so it can run admin commands with sudo:

usermod -aG sudo deploy

Why this matters:

• Using sudo instead of logging in as root makes it easier to track what’s happening in the logs.
• If something goes wrong, you see who ran the command, not just root did it.

Before you log out from root, test that the new user can log in and use sudo:

ssh deploy@your_server_ip

Once logged in as deploy:

sudo ls /root

If it asks for deploy’s password and then lists /root, you’re good. If not, fix that now before you continue.

---

Step 2: Why We’re Not Changing the SSH Port

Old Ubuntu hardening checklists often say: “Change SSH from port 22 to something else.”

Sounds nice in theory, but here’s the practical problem on Ubuntu 16.04 with ufw:

• If you change /etc/ssh/sshd_config to use a non-default port.
• And then you enable the UFW firewall using the built-in OpenSSH profile.
• You can easily block your new SSH port and lose access.

In other words, that “simple tweak” can turn into an instant lockout.

So in this guide, we keep SSH on the default port 22 and focus on safer, cleaner changes:

• Create a sudo user (already done above).
• Optionally prevent direct root logins via SSH.
• Use UFW with its built-in SSH profile and optional rate limiting.

If later you’re more comfortable and have console access from your provider, you can revisit port changes. But for a typical small VPS, staying on port 22 with good rules is way less drama.

---

Step 3: Disable Direct Root SSH Login (Optional but Recommended)

A lot of people prefer to completely disable direct root SSH logins. Instead, you:

• Log in as your regular user.
• Use sudo when you need admin rights.

This makes logging clearer and slightly raises the bar for attackers.

Important:

Make sure your sudo user login works before you do this. You already tested in Step 1. If you skipped that, go back.

Now, edit the SSH daemon config as your sudo user:

sudo nano /etc/ssh/sshd_config

Look for a line like:

PermitRootLogin yes

Change it to:

PermitRootLogin no

If the line starts with a #, remove the # and then set it to no:

PermitRootLogin no

Save the file and exit.

Then restart SSH to apply the change:

sudo systemctl restart ssh

Now, do not close your current SSH session yet.

Open a new terminal window and try logging in again as your sudo user:

ssh deploy@your_server_ip

• If that works: you’re safe to close the old session.
• If it fails, you can still go back to the other session and undo the change.

This simple habit—keep one working session open while testing changes—has saved me more headaches than I can count.

---

Step 4: Set Up a Basic UFW Firewall Without Locking Yourself Out

On Ubuntu, ufw (Uncomplicated Firewall) is a nice wrapper around iptables. For a fresh 16.04 server, the usual move is:

• Allow SSH.
• Optionally limit SSH to slow down brute-force attempts.
• Enable the firewall.

The key tip from the source discussion: don’t change the SSH port and then blindly use the OpenSSH app profile. That combo is what gets people locked out.

Since we’re staying on port 22, we can safely use the built-in SSH rule.

Check UFW status first:

sudo ufw status verbose

If it says Status: inactive, you’re starting clean.

Allow SSH via the pre-defined app profile:

sudo ufw allow OpenSSH

If you want SSH rate limiting to help with brute-force attempts, you can use limit instead of a plain allow. According to the docs, ufw will normally allow the connection but deny if an IP tries to start 6 or more connections within 30 seconds.

Typical usage from the manual:

sudo ufw limit ssh/tcp

This is specifically useful against automated brute-force scripts that hammer SSH.

You can combine both styles too, but for a basic setup, I’d usually pick one:

• allow OpenSSH if you want it simple.
• limit ssh/tcp if you want that extra rate limiting.

Once your SSH rule is in place, enable UFW:

sudo ufw enable

It will ask: Command may disrupt existing ssh connections. Proceed with operation (y|n)?

Hit y and Enter.

Then confirm:

sudo ufw status numbered

You should see something like:

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)

or, if you used limit:

22/tcp                     LIMIT       Anywhere
22/tcp (v6)                LIMIT       Anywhere (v6)

Again, keep your current SSH session open and open a new terminal to test reconnecting. If you can log in again without issues, you’re safe.

---

Step 5: A Word on Time Sync and Swap (Why They’re Not in This Flow)

In older Ubuntu setup guides (like for 14.04), you might see steps to:

• Install ntp to keep the server clock in sync.
• Manually configure swap space.

The source question specifically asks why those bits aren’t in the Ubuntu 16.04 guide. The short answer based on that context: this particular setup flow focuses more on the core, everyday items—SSH access and firewall—rather than repeating every older habit.

Since the source material doesn’t go into detail on NTP or swap for 16.04, I won’t invent extra instructions here. Just note:

• Time sync and swap are valid topics, but not strictly required to get a safe, usable baseline for many small servers.
• This guide sticks to what’s clearly mentioned in the 16.04 discussion: SSH and firewall behavior, especially around UFW and root login.

If you later need to fine-tune timekeeping or memory behavior, you can always tackle those in a follow-up pass.

---

Quick Recap and What to Do Next

Let’s summarize what you just did:

• Logged in as root only long enough to set up a proper sudo user.
• Switched to using that sudo user for normal SSH access.
• Optionally disabled root SSH login to make logging and security a bit saner.
• Enabled UFW with either allow OpenSSH or limit ssh/tcp so you don’t accidentally firewall yourself away from the box.
• Deliberately did not change the SSH port, avoiding a common Ubuntu 16.04 + UFW lockout trap.

From here, your next steps depend on what you’re building—web server, database, WordPress, whatever. But at least now you’ve got a clean, safer starting point without drama.

If this saved you time, bookmark CrushEdge for more fixes.