Server setup using Ubuntu

1. Server setup on Ubuntu

Have you recently purchased a VPS or a VDS and want to set up your server for web development or other purposes? Then this guide is for you. When you first acquire a new Ubuntu server from any provider, there are some important steps that you need to follow to make your server up and running. These steps will improve both the security and ease of use of your server.

2. Changing password to SSH authentication

SSH login is more secure than password login. No matter how strong your password is, I always recommend using ssh login over password authentication.

Passwords are often not sufficiently long or complex to resist brute-force attempts, especially given modern processing capabilities and automated scripts. Although other methods (like fail2ban) can improve security, I find that SSH keys are a strong alternative.

SSH keys come in pairs: a private key and a public key. The private key is kept on your own machine, and it should never be shared. If someone obtains your private key, they can log into any server that trusts the corresponding public key. For extra safety, you can encrypt the private key on your own disk with a passphrase.

The public key can be shared without risk. It allows for encrypting messages that only the private key can decrypt, which is how the server verifies that the connecting client truly possesses the private key. The public key must be added to a file named ~/.ssh/authorized_keys on the remote server. When you initiate an SSH connection with key-based authentication, the server checks if you hold the matching private key.

2.1 Generating SSH keys locally

First, create an SSH key pair on your local computer using ssh-keygen. By default, ssh-keygen creates a 3072-bit RSA key pair. In a terminal on your local machine, run:

ssh-keygen

It will ask where to save the generated keys. By default, they go into ~/.ssh, with the private key named id_rsa and the public key named id_rsa.pub. I usually accept the default setting by pressing ENTER.

If you already have a key named id_rsa in ~/.ssh, ssh-keygen will ask if you want to overwrite it:

Overwrite (y/n)?

Choosing y replaces the old key with the new one, permanently preventing you from using the original key. You must be certain before overwriting.

Next, you will be prompted for a passphrase to secure the private key on disk. A passphrase is optional, but it is recommended. Here are some reasons to use one:

• The private key itself never travels over the network; the passphrase only decrypts it locally.
• The private key is stored with restricted permissions, protecting it from other local users.
• If someone gains access to your system, the passphrase adds another barrier before they can reuse your private key.

Here is an example of a strong passphrase:

I_L0ve_H!king@table-M0untains$unrise

If you choose a passphrase, you’ll need to enter it whenever you try to log in via SSH. To avoid this, you can cache your passphrase using:

ssh-add ~/.ssh/id_rsa

Now you won’t be asked for your passphrase every single time you connect via SSH during this session.

After the process completes, you’ll see something like this:

Your identification has been saved in /home/username/.ssh/id_rsa
Your public key has been saved in /home/username/.ssh/id_rsa.pub

You now have a private and a public key. Next, you need to place the public key on the remote server so you can authenticate without a password.

2.2 Copying the public key to the server

There are a few different ways to add your public key to the remote server’s ~/.ssh/authorized_keys file. Here are some common methods.

Method 1: using ssh-copy-id

If your local machine has the ssh-copy-id utility and you have password-based SSH access to the remote server, this is the easiest approach. you just run:

ssh-copy-id username@remote_host

After confirming the server’s authenticity, ssh-copy-id scans for ~/.ssh/id_rsa.pub and then prompts for the remote user’s password. Once you enter it, ssh-copy-id appends your public key to ~/.ssh/authorized_keys on the server.

Method 2: using ssh and cat

If ssh-copy-id is not available but you still have password access, you can manually append your public key to the remote server as follow:

cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

When prompted, you enter the remote user’s password. This command ensures there is a ~/.ssh directory on the remote side, then appends your public key to authorized_keys.

Method 3: manual copying

If password-based SSH isn’t available and you only have some other form of access (like a web console), you can manually copy the contents of ~/.ssh/id_rsa.pub on your local machine:

cat ~/.ssh/id_rsa.pub

Copy that entire line (which begins with something like ssh-rsa AAAAB3N...) and then, on the remote server, create or ensure there is a ~/.ssh directory:

mkdir -p ~/.ssh

Finally, paste the copied public key string to ~/.ssh/authorized_keys:

After doing this, key-based authentication should be configured.

3. Authenticating with SSH Keys

Now that your public key is on the server, you can try to log in with:

ssh root@remote_host

If it’s the first time you connect to this server, you may see a prompt about the server’s authenticity. If everything looks correct, type yes and press ENTER.

If you did not set a passphrase, It should connect immediately. If you did set one, you will be asked to enter it here. Once the passphrase is entered, you get a shell session on the remote machine.

Optional recommendations: setting up an SSH config file (on your local machine):

You can create an SSH configuration file to store shortcuts for your servers. This is to avoid typing ssh -AXY root@your_server_ip every time you want to log in to your server. Instead, you can just type. e.g., ssh -AXY root, after you set up the following configuration. You can follow the following steps:

Edit ~/.ssh/config and add an entry similar to this (replace the Hostname and User with your server details):

Host root
Hostname your_server_ip
User root
PubKeyAuthentication yes

Then save and close the file. Now, to SSH into your server, simply type:

ssh root

4. Disabling password authentication

I recommend turning off password authentication after confirming that key-based authentication works. This prevents brute-force attempts against the server’s SSH. Before proceeding, make sure you can log in via SSH keys for a user with appropriate privileges (for instance, a sudo-enabled account or root if necessary).

Edit the SSH daemon’s configuration file:

sudo vim /etc/ssh/sshd_config

Look for the line:

#PasswordAuthentication yes

Remove the # (if present) and change yes to no:

PasswordAuthentication no

This will disable password logins entirely. After that, save the file and exit. To apply the changes, restart SSH:

sudo systemctl restart ssh

From this point forward, the only way to log in will be via SSH keys, which is much more secure.

At this stage, you have configured SSH key-based authentication so that you can log in without a password. You also have the option of disabling passwords entirely to bolster security.

The root account in Linux has complete administrative privileges and can execute any command—including destructive ones. It's safer to create a non-root user for daily tasks.

5. Creating a new user

Once logged in as root, create a new user account (this example uses username, but you can choose any name):

adduser username

You’ll be prompted to set a password and optionally fill out user information. If you skip any fields by pressing ENTER, that’s fine.

6. Granting administrative privileges

Your new user has regular privileges. However, you can grant temporary administrative powers using sudo so you don’t have to log out and back in as root each time.

usermod -aG sudo username

Now, when you need to run a command as root, type:

sudo command_to_run

You’ll be asked for your regular user’s password the first time you use sudo during a session (and periodically afterward).

7. Setting up a firewall

Ubuntu servers typically come with the UFW firewall (Uncomplicated Firewall), which lets you control incoming and outgoing connections. By default, OpenSSH (the SSH service) has a profile registered with UFW.

1. List available application profiles:

   ufw app list

2. Allow SSH connections so you don’t get locked out:

   ufw allow OpenSSH

3. Enable the firewall:

   ufw enable

   Type y and press ENTER if prompted.
4. Verify the firewall status:

   ufw status

   It should indicate that OpenSSH is allowed.

From now on, UFW is blocking all incoming connections except for SSH. If you install new services (like a web server), you’ll need to allow them through the firewall.

8. Enabling external access for your regular user

Now that you have a sudo-capable user, you’ll want to log in directly under this user rather than root.

You can copy your existing SSH key from root to your new user’s account. Ensure your root account has the key in /root/.ssh/authorized_keys. Then run:

rsync --archive --chown=username:username ~/.ssh /home/username

Replace username with your actual username. This command will:

• Preserve permissions on the SSH folder.
• Set the correct ownership for the new user.
• Copy all necessary files in one go.

Finally, open a new terminal session on your local machine and SSH in as the new user:

ssh username@your_server_ip

You should now be able to connect without a password if you’re using an SSH key without a passphrase, or with a passphrase if your key is passphrase-protected.

9. Conclusion

At this point, you have:

• Secured your server with a firewall.
• Created a new user with sudo privileges instead of using root for regular operations.
• Configured SSH key-based authentication for more secure access.
• Optionally created an SSH config file and used ssh-add to avoid repeated passphrase entry.

With these steps in place, your Ubuntu server is set up with better security and convenience, forming a strong base for hosting your web applications or other projects.