Initial Ubuntu 20.04 Server Setup: Safe, Simple, and Secure

When you spin up a fresh Ubuntu server, it feels great for about five seconds.

Then the worry kicks in:

“I’m logged in as root… is that bad?”
“Is SSH already getting hammered by bots?”
“If I mess this up, will I lock myself out?”

Before: you’ve got a brand-new Ubuntu box, wide open, running as root, and you’re hoping nobody notices.

After: you’ve got a normal user with sudo, keys set up for SSH, and a firewall in front. Same server, but now it’s a lot less attractive to random scanners and brute-force attacks.

This walkthrough is for anyone who just created an Ubuntu 20.04 (or later) server and wants a simple, low-drama initial setup.

1. Understand What You’re Fixing (and Why It Matters)

A fresh Ubuntu server usually starts you off with root access over SSH.

That’s convenient, but from a security point of view it’s a mess:

Root can do anything, instantly.
Attack bots love trying passwords on root.
One mistake as root can nuke your system.

So there are three basic hardening steps you want to do right away:

Create a non-root user with sudo
So you don’t live in root and can still do admin tasks safely.
Configure SSH key authentication
So logins use keys instead of passwords (harder to brute force).
Enable a firewall
So only required ports are reachable from the internet.

These don’t turn your server into a fortress, but they cut off a bunch of very common attacks that just scan the internet for default setups and weak passwords.

Important safety note before we start: don’t close your root SSH session until you have tested the new user and sudo. If you mess something up and close root, you might lock yourself out and need your provider’s recovery/console access.

2. Log In as Root (One Last Time)

You’ll start from root, because that’s what a fresh install usually gives you.

You’ll need:

Your server’s public IP address
The root password or the private SSH key if you already set one for root

From your local machine, connect with SSH. In a terminal:

ssh root@your_server_ip

If it’s using password auth, it will prompt you for the root password.
If it’s using key auth, it will use your private key (and may ask for the key’s passphrase).

Once you’re in as root, leave this session open the whole time while you do the setup.

3. Create a Non-Root User With Sudo

Now you’ll make a normal user for daily use.

3.1 Add the new user

Pick a username (lowercase, no spaces). Example: deploy.

adduser deploy

The system will:

Ask for a password for this new user
Ask for some optional info (you can just press Enter to skip)

You now have a non-root user, but it can’t do admin tasks yet.

3.2 Give the user sudo privileges

You want this user to be able to run admin commands via sudo.

On Ubuntu, the typical way is to put the user in the sudo group:

usermod -aG sudo deploy

That -aG means: append to Groups, not replace existing ones.

Now the deploy user can run commands like:

sudo apt update

and will be prompted for their own password.

3.3 Test the new user login (DO NOT SKIP)

Before messing with SSH or anything else, make sure this user actually works.

From your root session, switch to the new user:

su - deploy

The - makes sure you get that user’s full environment.

Now, test sudo:

sudo whoami

You should see something like:

[sudo] password for deploy:  
root

If that works, good. If sudo fails, fix it now while you still have root open.

Once you’re confident this user works, keep this session handy. We’ll use it for SSH key setup next.

4. Set Up SSH Key Authentication for the New User

SSH keys are way stronger than passwords and stop most brute-force login attempts cold.

You’ll need an SSH keypair on your local machine:

A private key (you keep this and never share it)
A public key (safe to copy to servers)

If you already have a keypair, you can reuse it. If not, you’d generate one locally (the exact command depends on your system, but typically it’s done with ssh-keygen on your machine). Once you have a keypair, you’re ready to tell the server about your public key.

4.1 Create the SSH directory for the user

Back on the server, as your new user (deploy in this example):

su - deploy   # if you're still root
mkdir -p ~/.ssh
chmod 700 ~/.ssh

mkdir -p ~/.ssh creates the directory if it doesn’t exist.
chmod 700 makes sure only this user can access it (important for SSH).

4.2 Add your public key

You need to put your public key into the user’s authorized_keys file.

Still as deploy on the server:

nano ~/.ssh/authorized_keys

Paste your public SSH key into this file (it usually starts with ssh-rsa or ssh-ed25519 and is one long line). Then save and exit.

After that, fix the permissions:

chmod 600 ~/.ssh/authorized_keys

SSH is very picky about permissions. This step prevents the "unprotected private key"-style errors.

4.3 Test SSH login as the new user

Now, from your local machine, open a new terminal window and try logging in as your new user:

ssh deploy@your_server_ip

If all is good, it should log you in without asking for a password (unless your local key has a passphrase, which is separate).

Once you confirm this works:

You know SSH keys are properly configured for deploy.
You can safely start relying less on root.

Again: don’t close your working root session until you’re sure this login works.

5. Turn On a Firewall to Limit Open Ports

With a public server, you want to expose only what you need.

For most basic setups, that’s:

SSH (so you can manage the server)
Maybe HTTP/HTTPS later (when you add a web server)

The source mentions enabling a firewall as one of the key steps. On Ubuntu, a common way is to use a firewall tool that lets you:

Allow SSH first (or you’ll lock yourself out)
Then enable the firewall so other random ports are blocked

When you do this, the idea is:

Confirm SSH is allowed through the firewall.
Enable the firewall so only whitelisted services are reachable.

This cuts down the noise from bots probing every port they can find.

As always when touching network rules: keep one working SSH session open while you test a new one. If the new one connects fine, you’re safe. If it doesn’t, you can still fix the rules from the existing session.

6. Keep Yourself From Getting Locked Out

A few self-defense habits when doing this kind of initial setup:

Never close the original root session until:
Your new user can log in via SSH, and
sudo works for that user.
Test in a second terminal
Open a new SSH window to test changes. If it fails, switch back to the old session and fix things.
Know your provider’s recovery option
If something goes wrong and you can’t log in, you’ll usually need your hosting provider’s console or recovery system to get back in and undo the mistake.

These steps take maybe 10–15 minutes, but they save you from that horrible feeling of, “I changed one thing… and now I’m locked out of my own server.”

7. What You’ve Achieved (and What’s Next)

If you followed along, you’ve now:

Logged in as root one last time
Created a non-root user
Given that user sudo privileges
Set up SSH key authentication for the new user
Enabled a firewall to limit what’s exposed

That’s the basic, boring-but-important foundation for an Ubuntu 20.04+ server. You’ve reduced your attack surface and made day-to-day work a bit safer.

From here, you can start installing your actual stack (web server, database, whatever you need) on top of a cleaner base.

Need more help? Check the latest CrushEdge posts.