After creating a new Ubuntu 18.04 server, you should take some configuration steps as part of an initial server setup in order to increase security and facilitate management later.
This guide will walk you through a few procedures that you should complete early on in order to create a solid foundation for your new server, before moving on to installing and configuring any software or services.
Newly installed servers typically have only a root account set up, and that is the account you’ll use to log into your server for the first time.
The root user is an administrative user that has very broad privileges. Because of the heightened privileges of the root account, you are discouraged from using it on a regular basis. This is because part of the power inherent to the root account is the ability to make very destructive changes, even by accident. For that reason, the recommended practice is to set up a regular system user and give this user sudo
permissions, so that it may run administrative commands with certain limitations. In the next step, you’ll set up such a user.
To get started, you’ll need to log into your server. Make sure you know your server’s public IP address. To authenticate, you’ll need either the account’s password or the SSH private key for the root user’s account, in case you have set up an SSH key for authentication within the server. If you have not already logged into your server, you may want to follow our guide on how to connect to your Droplet with SSH, which covers this process in detail.
If you are not already connected to your server, go ahead and log in as the root user with the following command. Be sure to replace the highlighted portion of the command with your server’s public IP address:
Accept the warning about host authenticity if it appears. If you are using password authentication, provide your root password to log in. Alternatively, if you are using an SSH key that is passphrase protected, you may be prompted to enter the passphrase the first time you use the key each session. Additionally, if this is your first time logging into the server with a password, you may also be prompted to change the root password.
In the next step, you’ll set up a new system user account with reduced privileges, and configure this user to run administrative commands via sudo
.
Once you are logged in as root, you can create a new user that will be your regular system user from now on.
The following example creates a new user called sammy, but you should replace it with a username of your choice:
You will be asked a few questions, starting with the account password.
Enter a strong password and, optionally, fill in any of the additional information if you would like. This is not required and you can just hit ENTER
in any field you wish to skip.
In the next step, you’ll set up sudo
privileges for this user. This will allow the user to execute administrative tasks as the root user through the sudo
program.
You have now a new user account with regular privileges. Sometimes, however, you’ll need to perform administrative tasks, like managing servers, editing configuration files, or restarting a server.
To avoid having to log out of your regular user and log back in as the root account, you can set up what are known as “superuser” or root privileges for your regular account. This will allow your regular user to run commands with administrative privileges by prefixing each command with the word sudo
.
To add these privileges to you new user, you need to add the new user to the sudo group. By default on Ubuntu 18.04, users who belong to the sudo group are allowed to use the sudo
command.
The following command will modify the default user settings, including the sudo
group in the list of groups a user already belongs to. Pay attention to the -a
argument, which stands for append. Without this option, the current groups a user is linked to would be replaced by sudo
, which would cause unexpected consequences. The -G
argument tells usermod
to change a user’s group settings.
As root, run this command to add your new user to the sudo group (replace the highlighted word with your new user):
Your system user is now set up. In the next step, you’ll configure a basic firewall for your server.
UFW (Uncomplicated Firewall) is a firewall configuration tool that comes with Ubuntu servers. You can use the UFW firewall to make sure only connections to certain services are allowed on your server.
Note: If your servers are running on DigitalOcean, you can optionally use DigitalOcean Cloud Firewalls instead of the UFW firewall. We recommend using only one firewall at a time to avoid conflicting rules that may be difficult to debug.
Applications can register their profiles with UFW upon installation. These profiles allow UFW to manage per-application settings by name. OpenSSH, the service allowing you to connect to your server now, has a profile registered within UFW.
Run the following command to get a list of all current available profiles:
OutputAvailable applications:
OpenSSH
You need to make sure that the firewall allows SSH connections so that you can log back in next time. You can allow these connections by typing:
Afterwards, you can enable the firewall with:
Type “y
” and press ENTER
to proceed. You can see that SSH connections are still allowed by typing:
OutputStatus: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
As the firewall is currently blocking all connections except for SSH, if you install and configure additional services, you will need to adjust the firewall settings to allow acceptable traffic in. You can learn some common UFW operations in this guide.
Now that you have a regular user for daily use, you need to make sure you can SSH into the account directly.
Note: Until verifying that you can log in and use sudo
as your new user, we recommend staying logged in as root. This way, if you have problems, you can troubleshoot and make any necessary changes as root. If you are using a DigitalOcean Droplet and experience problems with your root SSH connection, you can log into the Droplet using the DigitalOcean Console.
The process for configuring SSH access for your new user depends on whether your server’s root account uses a password or SSH keys for authentication.
If you logged in to your root account using a password, it means that password authentication is enabled for SSH. You can SSH to your new user account by opening up a new terminal session and using SSH with your new username:
After entering your regular user’s password, you will be logged in. Remember, if you need to run a command with administrative privileges, type sudo
before it like this:
You will be prompted for your regular user password when using sudo
for the first time each session (and periodically afterwards).
To enhance your server’s security, we strongly recommend setting up SSH keys instead of using password authentication. Follow our guide on setting up SSH keys on Ubuntu 18.04 to learn how to configure key-based authentication.
If you logged in to your root account using SSH keys, it’s likely that password authentication is disabled for SSH. You will need to add a copy of your local public key to the new user’s ~/.ssh/authorized_keys
file to log in successfully.
Since your public key is already in the root account’s ~/.ssh/authorized_keys
file on the server, you can copy that file and directory structure to your new user account in your existing session.
The simplest way to copy the files with the correct ownership and permissions is with the rsync
command. This will copy the root user’s .ssh
directory, preserve the permissions, and modify the file owners, all in a single command. Make sure to change the highlighted portions of the following command to match your regular user’s name:
Note: The rsync
command treats sources and destinations that end with a trailing slash differently than those without a trailing slash. When using rsync
below, be sure that the source directory (~/.ssh
) does not include a trailing slash (check to make sure you are not using ~/.ssh/
).
If you accidentally add a trailing slash to the command, rsync
will copy the contents of the root account’s ~/.ssh
directory to the sudo
user’s home directory instead of copying the entire ~/.ssh
directory structure. The files will be in the wrong location and SSH will not be able to find and use them.
Now, open up a new terminal session and try to log in with your new username:
You should be able to log into the new user account without being prompted for the remote user’s SSH password for authentication. If your SSH key was set up with a keyphrase, you may be asked to unlock the SSH key by providing that password when you use the key for the first time in a terminal session.
Remember, if you need to run a command with administrative privileges, type sudo
before it like this:
You will be prompted for your regular user password when using sudo
for the first time each session (and periodically afterwards).
At this point, you have a solid foundation for your server. You can install any of the software you need on your server now.
If you’d like to get more familiar with Linux commands, you can check our Linux Command Line Primer. To extend your setup, you may want to check our Ubuntu 18.04 tag page for more guides based on that distribution.
Get Ubuntu on a hosted virtual machine in seconds with DigitalOcean Droplets! Simple enough for any user, powerful enough for fast-growing applications or businesses.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
I have made a bash script to automate the setup process, hopefully this will be useful to someone else.
@jasonheecs nice! however, feels like cheating to an extent. no pain, no gain, they say. on the other hand, I adore bash scripts. NICE)
Nice
You sir are awesome. Automation is an Admins friend.
Hey, Justin! Thanks for the great tutorial. In your last step,
rsync --archive --chown=sammy:sammy ~/.ssh /home/sammy
, it might be worth pointing out that there should be no trailing slash on~/.ssh
. I only mention that because when I was typing it in, I hit <tab> (to autocomplete, out of habit) and bash turned that into/root/ssh/
.I tried to log in with my new user, but because rsync doesn’t copy the source directory itself when it is appended with a trailing slash, my
authorized_keys
file was just hanging out in my new user’s home directory. A quick note might save someone else the trouble. Thanks again!@benforshey Yeah, that’s a good call. Thanks for the input! I’ve added a note to help users avoid that problem in the future.
This saved my day. Thank you very much.
Hi…i followed this steps but I still cannot SSH login, i remove the trailing slash followed this rsync but still error…what am i doing wrong? please guide…thanks (rsync --archive --chown=sammy:sammy .ssh /home/sammy). with trailing slash and without trailing slash still cannot login with SSH.
Hey, @odtrtest! Are you replacing
sammy
with your own username?Thanks buddy!
It’s also probably advisable to include a Step 6: Disable SSH root login.
This can be done by setting
PermitRootLogin
tono
in/etc/ssh/sshd_config
.If you disable SSH root login, will you still be able to access the server via DigitalOcean web console, in case of emergency?
Yes.
Although the web console isn’t great, and is extremely buggy with copy and pasting (e.g. the copy and pasting of a new ssh key).
Thanks!
And don’t forget to restart ssh with
sudo service ssh restart
.Dont forget to
sudo systemctl restart sshd!
I also prefer to install fail2ban to prevent anybody trying to hack into the system.
Installing
fail2ban
is an excellent way to enhance the security of your system by protecting it against brute-force attacks.You can also check this article on Fail2ban:
https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-ubuntu-20-04
Regards
This comment has been deleted
The old 16-04 tutorial made a lot more sense with how to get the keys in the correct place for ssh on the new user.
You might not be able to access using the new user you created, make sure you allow OpenSSH on uwf by (logged in as root or access it via the droplet console):
ufw allow OpenSSH
in my case i also allowed port 22
ufw allow 22
Heya,
Also when working with firewalls make sure there is no other firewall tool where you’ll need to open/allow the port as well.
Regards
Great piece! thank you. Keep up the good work :)
https://transfer.sh/ is a neat alternative for rsync. \Yet, not sure about security compliance on their side.
i.e.
output returns a downloadable link that fits both for cli and webUI Also addable as alias to .bashrc:
Heya,
Thanks for sharing this! If you’re interested in using
rsync
orscp
you can check the following article:https://www.digitalocean.com/community/tutorials/how-to-use-rsync-to-sync-local-and-remote-directories
Regards
Very useful, short and it works. Thx for sharing.
Please include this in your doc
sudo ufw allow 22
Why? It already includes
ufw allow OpenSSH
.Note also that it is equivalent to
ufw allow 22/tcp
, which is more restrictive and thus better than what you’re suggesting.Didn’t work. I’m getting “Permission denied (publickey)”.
that’s usually a local problem… make sure you’ve got your agent running and using the correct key
This can also happen when you try to access your newly created user before actually copying the keys over from the root user.
Make sure to
rsync --archive --chown [...]
the home directory of your newly created user. Search the article forrsync
. The complete command is documented by the author.I followed the steps but at the end when trying to ssh using my new user I get this
and I’m immediately back at my shell. What’s going on? I checked and I have
and als the authorized_keys are both at root and my user .ssh directory.
Hi, how would this go along with https://www.digitalocean.com/community/tutorials/an-introduction-to-cloud-config-scripting ?
It would be nice to include at the end a cloud-config that will automatically run all this on first server boot
I am using Putty. Is there a way to set up this with Putty instead of OpenSSH?
You can use PuTTy to access your server, there is no issue with that. Once the server is allowing connections on port 22 you’ll be good to go.
https://docs.digitalocean.com/products/droplets/how-to/connect-with-ssh/putty/
Regards
usefull, thanks ;3
after i logged in as
ssh sammy@your_server_ip
i got problem with this command
rsync --archive --chown=sammy:sammy ~/.ssh /home/sammy
here is the error
rsync: link_stat “/home/sammy/.ssh” failed: No such file or directory (2) rsync error: some files/attrs were not transferred (see previous errors) (code 2 3) at main.c(1196) [sender=3.1.2]
create dir before launch this command: mkdir .ssh
The error “rsync: link_stat ‘/home/sammy/.ssh’ failed: No such file or directory (2)” occurs because the
.ssh
directory does not exist in/home/sammy/
.Regards
Can’t get the command
rsync --archive --chown=sammy:sammy ~/.ssh /home/sammy
to work either after following these instructions. Anyone got any idea how to make this work?
From https://help.ubuntu.com/community/rsync: “Rsync is installed in Ubuntu by default”.
Make sure there are two dashes (
--
) before thearchive
andchown
flags. Make sure you replacesammy
with the name of YOUR user. If the name for your user on the server isjanedoe
you replacesammy
withjanedoe
. The command is to be executed ON the server in an SSH session. Not on your local machine.So your command might look something like this:
Before running the
rsync
command, make sure the/home/sammy/.ssh
directory exists. If it doesn’t, you need to create it. The.ssh
directory should be owned by the user (sammy
) and should have the correct permissions.Run the following commands:
This ensures the
.ssh
directory is created and the correct permissions are applied.The
rsync
command uses relative paths based on the user’s home directory. It’s important to make sure the~/.ssh
directory exists and contains the necessary files likeauthorized_keys
, and that you are specifying the destination path correctly.If you’re running the command as root or another user, you may need to use the absolute path for the home directory. For example:
This will copy the SSH configuration files from
/root/.ssh/
to/home/sammy/.ssh/
. Make sure there is a trailing slash (/
) at the end of the source path so it correctly copies the contents of the directory rather than the directory itself.Regards
The problem I was having was when I tried logging in with my username, it would give me an error “No supported authentication methods available (server sent: publickey)”
When I logged in as root and ran this command (changing sammy to my username)
chown -R sammy:sammy /home/sammy/.ssh
…it worked.
Heya,
I’m glad that you’ve sorted this! This issue can often be related to files’s permissions and ownership so it’s a good idea to start looking there when troubleshooting.
Regards
Thanks for the article. This worked very well for me with the exception of setting up the firewall.
I typed the following, hoping to allow SSH and HTTP :
sudo ufw allow 22 sudo ufw allow 80 ufw enable
HTTP does not work. I had to disable ufw to get HTTP to work.
Heya,
If you need to allow connections for HTTP and HTTPS you can open the ports in UFW.
You can check our article on the initial Ubuntu Apache setup here:
https://www.digitalocean.com/community/tutorials/how-to-install-the-apache-web-server-on-ubuntu-22-04
Regards
Followed all the steps for SSH key authentication but after the last step as root user
rsync –archive –chown=anthony:anthony ~/.ssh /home/anthony
and opening a new tab in my terminal, I still had to enter my passphrase after running ssh anthony@178.xx.xxx.xxxSSH requires strict permissions on your
.ssh
folder and keys.Run the following commands on your server:
Check your SSH configuration:
Make sure the following lines exist and are not commented out (
#
):Save and restart SSH:
Regards
This comment has been deleted
This comment has been deleted
This comment has been deleted
This comment has been deleted
This comment has been deleted
This comment has been deleted
This comment has been deleted
Followed all the steps for SSH key authentication but after the last step as root user
rsync –archive –chown=anthony:anthony ~/.ssh /home/anthony
and opening a new tab in my terminal, I still had to enter my passphrase after running ssh anthony@178.xx.xxx.xxxThe SSH agent is responsible for managing your SSH keys in memory, so you don’t have to type the passphrase every time.
First, check if the SSH agent is running:
If the agent isn’t running, you can start it with:
If the agent is running, but the key isn’t loaded, you’ll need to add it manually:
Replace
id_rsa
with the actual name of your private key file if you’re using a different one.After adding the key, try logging in again with:
You should be prompted for your passphrase (if the key has one), but it should not ask for the user password.
Regards
Yet it should be noted rsync could copy a root’s ssh private key when the one is existing. May be, a command to rsync authorized_keys file only would look better for beginners.
When using
rsync
, if not used carefully, it could inadvertently copy sensitive files like a root user’s SSH private key (if it exists) to a destination, which poses a security risk.For beginners, it’s best to only copy the necessary SSH configuration files, such as the
authorized_keys
file, to avoid inadvertently transferring sensitive data like private keys.Regards
Followed all the steps for SSH key authentication but after the last step as root user
rsync –archive –chown=anthony:anthony ~/.ssh /home/anthony
and opening a new tab in my terminal, I still had to enter my passphrase after running ssh anthony@178.xx.xxx.xxxSSH requires strict permissions on your
.ssh
folder and keys.Run the following commands on your server:
Check your SSH configuration:
Make sure the following lines exist and are not commented out (
#
):Save and restart SSH:
Regards
This comment has been deleted
This comment has been deleted
This comment has been deleted
This comment has been deleted
This comment has been deleted
This comment has been deleted
This comment has been deleted
Followed all the steps for SSH key authentication but after the last step as root user
rsync –archive –chown=anthony:anthony ~/.ssh /home/anthony
and opening a new tab in my terminal, I still had to enter my passphrase after running ssh anthony@178.xx.xxx.xxxThe SSH agent is responsible for managing your SSH keys in memory, so you don’t have to type the passphrase every time.
First, check if the SSH agent is running:
If the agent isn’t running, you can start it with:
If the agent is running, but the key isn’t loaded, you’ll need to add it manually:
Replace
id_rsa
with the actual name of your private key file if you’re using a different one.After adding the key, try logging in again with:
You should be prompted for your passphrase (if the key has one), but it should not ask for the user password.
Regards
Yet it should be noted rsync could copy a root’s ssh private key when the one is existing. May be, a command to rsync authorized_keys file only would look better for beginners.
When using
rsync
, if not used carefully, it could inadvertently copy sensitive files like a root user’s SSH private key (if it exists) to a destination, which poses a security risk.For beginners, it’s best to only copy the necessary SSH configuration files, such as the
authorized_keys
file, to avoid inadvertently transferring sensitive data like private keys.Regards
Once I’ve created a working system, is it easy to duplicate it to instances in other datacenters?
We are looking at using DO for tiny ‘remote monitors’ and basically want the same image running all over the world. Being able to build up one reference machine, then duplicating that for deployment would rock.
@CoSoWes Yes!
Many developers use snapshots for this exact thing.
The general idea is:
Spin up a Droplet and configure it to be your “reference machine” - You’ll probably want to configure services to auto-start on boot, and you can even use the metadata api if each Droplet will need to know its own name/region/IP etc…
Once it’s ready, take a snapshot of the Droplet, either through the control panel, or command-line tool,
doctl
Now you can create new Droplets (through the control panel or CLI) that use the Snapshot instead of a base image like Debian.
This sounds perfect for our need.
Good info on the metadata api, we will probably want to report on the public IP, and likely the region as well.
May I just add, awesome response time!
I need to add the new user to group ‘sudo’ before user has root privileges.
adduser newuser sudo
Hello,
For anyone interested, I just created a similar video demo on how to do the initial server setup as described in this tutorial:
Hope that this helps!
Regards, Bobby
Why not add the following commands to the end of this tutorial? I think it is a good practice to update a fresh Ubuntu installation, no?
Thanks for the feedback! Yes, this is a valid point! I totally agree with you it is always a good idea to update a fresh installation when starting to build your droplet.
Regards
Great Mind. I want to be like you when I finally understand all these
Excellent article, thank you!
Just regarding the use of
rsync
. If you had multiple users on ubuntu representing real people of different machines then you might not want to usersync
to prevent access via ssh regardless of whether once logged in they’re able to switch users.For example Fred has a different client machine to Michael and so Fred has a different public key. That public key gets coppied in authorized_keys for ssh in Fred’s directory and only contains Fred’s key. Likewise for Michael. So that Fred can only ssh into Fred on Fred’s machine, and Michael can only ssh into Michael on Michael’s machine and not each others.
Is this use of rsync here because we start out with the root user and then add our first additional user?
Heya,
The use of
rsync
in the tutorial is primarily for system setup and file transfer, and it doesn’t bypass user access control. When usingrsync
, if Fred and Michael are logged in separately, each will only have access to their own files as long as permissions are correctly set. If you’re concerned about users accessing each other’s data, make sure to use the correct file ownership and permissions for each user’s home directory and their.ssh
folder.Regards
Bonjour. J’ai voulu me connecter à mon serveur en tant que root avec la commande “ssh root@your_server_ip” mais quand je saisis mon mot de passe on met “permission denied,please try again” et à la fin je n’arrive pas à me connecter en tant que root. Pouvez-vous m’aider svp
You can ensure that root login is allowed in your SSH configuration. Open the SSH configuration file on your server:
Look for the following line:
If it’s set to
no
orprohibit-password
, change it toyes
. If the line is commented out, uncomment it.After editing the file, save it and restart the SSH service:
Ensure that the permissions for your
.ssh
directory and its contents are correct. On your server, check that the following files have the correct permissions:Also, ensure the file ownership is correct:
If you’re trying to log in using a password, make sure that password authentication is enabled in the SSH config file. Check for this line in
/etc/ssh/sshd_config
:If it’s set to
no
, change it toyes
and restart SSH:Ensure that your firewall is not blocking the SSH port (usually port 22). You can check if SSH is allowed through the firewall by running:
Double-check that you’re entering the correct root password. If you’ve forgotten it, you can reset the root password.
If none of the above works, you can check the SSH logs to get more information about the issue:
This will show any SSH-related log entries and may provide additional clues.
Guys you need to let these through your ufw: To Action From
OpenSSH ALLOW Anywhere 80 ALLOW Anywhere 443 ALLOW Anywhere 51820/udp ALLOW Anywhere 55967 ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) 80 (v6) ALLOW Anywhere (v6) 443 (v6) ALLOW Anywhere (v6) 51820/udp (v6) ALLOW Anywhere (v6) 55967 (v6) ALLOW Anywhere (v6)
I also had to change the DNS servers. Not sure how I managed to bungle them. You can do that in the client.
You can always allow additional ports and services if you require this, for start allowing the openssh port will grant you access to the droplet from where you can additionally develop the firewall configuration.
Regards
This comment has been deleted
Thank you and the community for a detailed tutorial.
I followed all the steps in this tutorial, but was still unable to login as a non-root user from putty client, with error - Server refused our key. No supported authentication methods available (server sent: public key)
You can verify this by making a fresh droplet and following this tutorial.
Found this in auth.log in /var/log - User myUsernamer from xx.xx.xx.xx not allowed because not listed in AllowUsers
For Enabling External Access for Your Regular(Non-Root) User, you need to add the user to list of users who are allowed access via SSH in /etc/ssh/sshd_config file, which is specified in line starting with AllowUsers.
Something like - AllowUsers root, yourUser1, myUserName
Please add instructions for this step.
It seems like the error you’re encountering is due to the
AllowUsers
directive in the SSH configuration file, which limits which users are allowed to log in via SSH. If your non-root user is not listed in theAllowUsers
section, you’ll get the error message you mentioned.Open the
/etc/ssh/sshd_config
file in a text editor likenano
:Look for the line that starts with
AllowUsers
. This line restricts SSH access to only certain users. If this line exists and does not include your non-root username, you’ll need to modify it.If the line is missing or commented out, you can add it yourself. For example, if the username of your non-root user is
myUserName
, you would modify or add the line like this:To apply the changes, restart the SSH service:
Regards
Good day,can someone pls share me a link to download and install ubuntu on mac os,thanks.
Heya,
If you’re looking to install Ubuntu Desktop you can check this article:
https://ubuntu.com/tutorials/install-ubuntu-desktop
Regards
This comment has been deleted