Initial Debian 10 Server Setup: Users, SSH, and Firewall

When you spin up a fresh Debian 10 server, it’s basically a blank room with the door wide open.

Before you start installing apps or hosting sites, you want a basic setup: safe login, a non-root user, and a simple firewall.

This walkthrough is for anyone who just got a new Debian 10 box from a provider and wants a clean, minimal, low-drama base to build on.

What We’re Doing (and Why It Matters)

New servers usually come with:

  • Root login enabled
  • No extra users
  • No firewall rules set up

That’s workable for 5 minutes of testing, but bad for anything real.

In this guide we’ll:

  1. Log in as root over SSH
  2. Create a new, safer user for daily work
  3. Give that user admin powers when needed
  4. Set up a basic firewall

We’ll keep it simple and only touch what’s covered in the source: login, users, and basic firewall.

Step 1: Log In as Root with SSH

First job: actually get into the server.

You’ll need:

  • Your server’s public IP address
  • Either:
  • The root password, or
  • An SSH private key that matches the root user’s key on the server

On your local machine, open a terminal and connect (swap in your actual IP):

ssh root@your_server_ip

A few things that might happen here:

  • First time connecting? SSH will show a warning about host authenticity. Type yes to accept it.
  • If you’re using password auth, it will ask for the root password.
  • If you’re using an SSH key with a passphrase, it may ask for the passphrase the first time each session.
  • If this is literally your first login and you’re using a password, Debian may force you to change the root password. That’s normal.

Once you’re in, you’ll be sitting at a shell prompt as root.

Root can do anything, including mistakes that wreck the server in one line, so we’re not going to stay as root for daily work.

Step 2: Understand Why You Shouldn’t Live as root

On Linux, the root user is the boss.

Root can:

  • Edit or delete any file
  • Change any permission
  • Install or remove any package

That power is useful, but also dangerous.

One wrong command, one misplaced rm, and you’re rebuilding the server from scratch. Ask me how I learned that with bad RAM back in the 486 days…

So instead of living as root, we:

  • Create a “normal” user for everyday stuff
  • Give that user a way to temporarily get extra privileges only when needed

This makes accidents less likely and adds a bit of safety if someone ever gets access to that account.

Step 3: Create a New User for Daily Use

You’re still logged in as root.

Now we’ll make a new user for normal work. Pick a username you like (I’ll use deploy as an example).

From the root shell:

adduser deploy

Debian will ask you for:

  • A password for this new user
  • Some optional details (full name, room number, etc.) — you can press Enter through these if you don’t care

Once that’s done, you have a new user with limited privileges.

This user can log in, move around the filesystem, and do normal things, but can’t do fully privileged system changes by default. That’s exactly what we want for day-to-day commands.

Step 4: Give the New User Admin Power (When Needed)

Sometimes you do need extra power — installing packages, editing system configs, and so on.

The pattern we want is: work as the normal user, then temporarily elevate when you must.

To prepare for that, while still logged in as root, add your new user to the admin-type group.

Assuming your user is deploy, run:

usermod -aG sudo deploy

This doesn’t do anything visible right now, but it gives that user permission to request elevated privileges later.

After this, you’ll be able to log in as deploy and then run commands with sudo when you need more power.

Step 5: Test Logging In as the New User

Before we go further, let’s confirm the new account works.

On your local machine (not inside the existing root session), open another terminal and connect using your new username:

ssh deploy@your_server_ip
  • If you set a password for this user, you’ll be asked for it now.
  • If you have SSH keys set up, and the provider copied keys to this user, you may be prompted for the key passphrase instead.

Once you’re logged in, you’re now working as deploy (or whatever username you chose), not as root.

To test that elevated access works, try:

sudo echo "sudo works"

The first time you use sudo in a session, it will ask for your user password (the one you set for deploy). If it prints the text without complaining, you’re good.

Why test now? Because you don’t want to lock yourself out later by misconfiguring privileges. Better to catch issues while the root session is still open in another window.

Step 6: Set Up a Basic Firewall

A new server with no firewall is like leaving every window open.

As part of basic setup, you’ll want a firewall that only allows the services you actually use. The source specifically mentions setting up a basic firewall, but doesn’t dig into the exact command set, so the main idea is:

  • Ensure SSH stays accessible so you don’t lock yourself out
  • Then add rules for whatever else you’ll run later (web server, etc.)

From a high level, the workflow is:

  1. Connect as root (or as your new user with sudo).
  2. Configure the firewall to allow SSH on your current port.
  3. Enable the firewall so it starts enforcing rules.

Do this carefully and always verify you can still log in from a second terminal before closing your existing sessions. If you mess up a rule and drop your SSH access, you’ll have to use your provider’s recovery console to undo it.

Since the source only states that we’ll set up a basic firewall and doesn’t give specific commands, stick to your hosting provider’s recommended firewall setup steps or Debian 10’s official docs, and test slowly.

What to Do Next

At this point you have:

  • Root access (for emergencies only)
  • A regular user account for everyday work
  • That user tied into admin privileges when needed
  • A basic firewall concept in place so you’re thinking about what to expose

That’s a good, clean foundation for:

  • Installing a web server
  • Hosting a WordPress or other app
  • Hardening SSH further, tuning firewall rules, and so on

From here, follow your app’s install guide, always running daily commands as your non-root user and only elevating privilege when it’s really needed.

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

No Comments

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.