Tutorial

Initial Server Setup with Ubuntu 14.04

Initial Server Setup with Ubuntu 14.04
Not using Ubuntu 14.04?Choose a different version or distribution.
Ubuntu 14.04

Introduction

When you first create a new Ubuntu 14.04 server, there are a few configuration steps that you should take early on as part of the basic setup. This will increase the security and usability of your server and will give you a solid foundation for subsequent actions.

Step One — Root Login

To log into your server, you will need to know your server’s public IP address and the password for the “root” user’s account. If you have not already logged into your server, you may want to follow the first tutorial in this series, 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 using the following command (substitute the highlighted word with your server’s public IP address):

  1. ssh root@SERVER_IP_ADDRESS

Complete the login process by accepting the warning about host authenticity, if it appears, then providing your root authentication (password or private key). If it is your first time logging into the server, with a password, you will also be prompted to change the root password.

About Root

The root user is the administrative user in a Linux environment that has very broad privileges. Because of the heightened privileges of the root account, you are actually discouraged from using it on a regular basis. This is because part of the power inherent with the root account is the ability to make very destructive changes, even by accident.

The next step is to set up an alternative user account with a reduced scope of influence for day-to-day work. We’ll teach you how to gain increased privileges during the times when you need them.

Step Two — Create a New User

Once you are logged in as root, we’re prepared to add the new user account that we will use to log in from now on.

This example creates a new user called “demo”, but you should replace it with a user name that you like:

  1. adduser demo

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.

Step Three — Root Privileges

Now, we have a new user account with regular account privileges. However, we may sometimes need to do administrative tasks.

To avoid having to log out of our normal user and log back in as the root account, we can set up what is known as “super user” or root privileges for our normal account. This will allow our normal user to run commands with administrative privileges by putting the word sudo before each command.

To add these privileges to our new user, we need to add the new user to the “sudo” group. By default, on Ubuntu 14.04, users who belong to the “sudo” group are allowed to use the sudo command.

As root, run this command to add your new user to the sudo group (substitute the highlighted word with your new user):

  1. gpasswd -a demo sudo

Now your user can run commands with super user privileges! For more information about how this works, check out this sudoers tutorial.

The next step in securing your server is to set up public key authentication for your new user. Setting this up will increase the security of your server by requiring a private SSH key to log in.

Generate a Key Pair

If you do not already have an SSH key pair, which consists of a public and private key, you need to generate one. If you already have a key that you want to use, skip to the Copy the Public Key step.

To generate a new key pair, enter the following command at the terminal of your local machine (ie. your computer):

  1. ssh-keygen

Assuming your local user is called “localuser”, you will see output that looks like the following:

ssh-keygen output
Generating public/private rsa key pair. Enter file in which to save the key (/Users/localuser/.ssh/id_rsa):

Hit return to accept this file name and path (or enter a new name).

Next, you will be prompted for a passphrase to secure the key with. You may either enter a passphrase or leave the passphrase blank.

Note: If you leave the passphrase blank, you will be able to use the private key for authentication without entering a passphrase. If you enter a passphrase, you will need both the private key and the passphrase to log in. Securing your keys with passphrases is more secure, but both methods have their uses and are more secure than basic password authentication.

This generates a private key, id_rsa, and a public key, id_rsa.pub, in the .ssh directory of the localuser’s home directory. Remember that the private key should not be shared with anyone who should not have access to your servers!

Copy the Public Key

After generating an SSH key pair, you will want to copy your public key to your new server. We will cover two easy ways to do this.

Note: The ssh-copy-id method will not work on DigitalOcean if an SSH key was selected during Droplet creation. This is because DigitalOcean disables password authentication if an SSH key is present, and the ssh-copy-id relies on password authentication to copy the key.

If you are using DigitalOcean and selected an SSH key during Droplet creation, use option 2 instead.

Option 1: Use ssh-copy-id

If your local machine has the ssh-copy-id script installed, you can use it to install your public key to any user that you have login credentials for.

Run the ssh-copy-id script by specifying the user and IP address of the server that you want to install the key on, like this:

  1. ssh-copy-id demo@SERVER_IP_ADDRESS

After providing your password at the prompt, your public key will be added to the remote user’s .ssh/authorized_keys file. The corresponding private key can now be used to log into the server.

Option 2: Manually Install the Key

Assuming you generated an SSH key pair using the previous step, use the following command at the terminal of your local machine to print your public key (id_rsa.pub):

  1. cat ~/.ssh/id_rsa.pub

This should print your public SSH key, which should look something like the following:

id_rsa.pub contents
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBGTO0tsVejssuaYR5R3Y/i73SppJAhme1dH7W2c47d4gOqB4izP0+fRLfvbz/tnXFz4iOP/H6eCV05hqUhF+KYRxt9Y8tVMrpDZR2l75o6+xSbUOMu6xN+uVF0T9XzKcxmzTmnV7Na5up3QM3DoSRYX/EP3utr2+zAqpJIfKPLdA74w7g56oYWI9blpnpzxkEd3edVJOivUkpZ4JoenWManvIaSdMTJXMy3MtlQhva+j9CgguyVbUkdzK9KKEuah+pFZvaugtebsU+bllPTB0nlXGIJk98Ie9ZtxuY3nCKneB+KjKiXrAvXUPCI9mWkYS/1rggpFmu3HbXBnWSUdf localuser@machine.local

Select the public key, and copy it to your clipboard.

Add Public Key to New Remote User

To enable the use of SSH key to authenticate as the new remote user, you must add the public key to a special file in the user’s home directory.

On the server, as the root user, enter the following command to switch to the new user (substitute your own user name):

  1. su - demo

Now you will be in your new user’s home directory.

Create a new directory called .ssh and restrict its permissions with the following commands:

  1. mkdir .ssh
  2. chmod 700 .ssh

Now open a file in .ssh called authorized_keys with a text editor. We will use nano to edit the file:

  1. nano .ssh/authorized_keys

Now insert your public key (which should be in your clipboard) by pasting it into the editor.

Hit CTRL-X to exit the file, then Y to save the changes that you made, then ENTER to confirm the file name.

Now restrict the permissions of the authorized_keys file with this command:

  1. chmod 600 .ssh/authorized_keys

Type this command once to return to the root user:

  1. exit

Now you may SSH login as your new user, using the private key as authentication.

To read more about how key authentication works, read this tutorial: How To Configure SSH Key-Based Authentication on a Linux Server.

Step Five — Configure SSH Daemon

Now that we have our new account, we can secure our server a little bit by modifying its SSH daemon configuration (the program that allows us to log in remotely) to disallow remote SSH access to the root account.

Begin by opening the configuration file with your text editor as root:

  1. nano /etc/ssh/sshd_config

Next, we need to find the line that looks like this:

/etc/ssh/sshd_config (before)
PermitRootLogin yes

Here, we have the option to disable root login through SSH. This is generally a more secure setting since we can now access our server through our normal user account and escalate privileges when necessary.

Modify this line to “no” like this to disable root login:

/etc/ssh/sshd_config (after)
PermitRootLogin no

Disabling remote root login is highly recommended on every server!

When you are finished making your changes, save and close the file using the method we went over earlier (CTRL-X, then Y, then ENTER).

Step Six – Reload SSH

Now that we have made our change, we need to restart the SSH service so that it will use our new configuration.

Type this to restart SSH:

  1. service ssh restart

Now, before we log out of the server, we should test our new configuration. We do not want to disconnect until we can confirm that new connections can be established successfully.

Open a new terminal window on your local machine. In the new window, we need to begin a new connection to our server. This time, instead of using the root account, we want to use the new account that we created.

For the server that we showed you how to configure above, you would connect using this command. Substitute your own user name and server IP address where appropriate:

  1. ssh demo@SERVER_IP_ADDRESS

Note: If you are using PuTTY to connect to your servers, be sure to update the session’s port number to match your server’s current configuration.

You will be prompted for the new user’s password that you configured. After that, you will be logged in as your new user.

Remember, if you need to run a command with root privileges, type “sudo” before it like this:

  1. sudo command_to_run

If all is well, you can exit your sessions by typing:

  1. exit

Where To Go From Here?

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 are not sure what you want to do with your server, check out the next tutorial in this series for Additional Recommended Steps for New Ubuntu 14.04 Servers. It covers things like basic firewall settings, NTP, and swap files. It also provides links to tutorials that show you how to set up common web applications. You may also want to check out this guide to learn how to enable fail2ban to reduce the effectiveness of brute force attacks.

If you just want to explore, take a look at the rest of our community to find more tutorials. Some popular ideas are configuring a LAMP stack or a LEMP stack, which will allow you to host websites.

Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.

Learn more about our products


Tutorial Series: New Ubuntu 14.04 Server Checklist

When creating a new Ubuntu 14.04 server, there are some basic steps that you should take to ensure that your server is secure and configured properly. This tutorial series covers connecting to your server and general security best practices, and provides links to articles that will help you start running your own web server or application.

Tutorial Series: Introduction to Nginx and LEMP on Ubuntu 14.04

This tutorial series helps sysadmins set up a new web server using the LEMP stack, focusing on Nginx setup with virtual blocks. This will let you serve multiple websites from one Droplet.

You’ll start by setting up your Ubuntu 14.04 server and end with multiple virtual blocks set up for your websites. An Nginx configuration guide is included at the end for reference.

About the authors

Still looking for an answer?

Ask a questionSearch for more help

Was this helpful?
 
30 Comments
Leave a comment...

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!

When I try to restart the SSH server after some modifications I get this error:

WARNING: Usage of “server” is deprecated, it has been renamed to “rspserver”! Starting service Echo… Echo Server - Version 1.0

General Parameters: Pool Handle = EchoPool Reregistration Interval = 30.000s Local Addresses = { all } Runtime Limit = off Policy Settings Policy Type = RoundRobin Load Degradation = 0.000% Load DPF = 0.000% Weight = 0 Weight DPF = 0.000% 20-Apr-2014 01:51:53.0852: P3130.7f57bfb19780@stuff rserpoolsocket.c:354 doRegistration() 20-Apr-2014 01:51:53.0857: Error: (Re-)Registration failed: no registrar available Registration: Identifier = $62292d97

Plus, my shell prompt become’s locked and I have to reconnect.

This is with a fresh copy of Ubuntu 14.04 installed minutes ago.

Fred

It seems that denyhosts is marked unmaintained for 14.04.

This comment has been deleted

    This comment has been deleted

      I think you meant to say under Step Four:

      “replacing “demo” with the user you created:”

      Andrew SB
      DigitalOcean Employee
      DigitalOcean Employee badge
      April 21, 2014

      @Dustin Fixed. Thanks for catching that!

      Andrew SB
      DigitalOcean Employee
      DigitalOcean Employee badge
      April 21, 2014

      @Rick Roberts: Right, denyhosts has been dead upstream for awhile, and Ubuntu and Debian have decided to stop providing it. Check out:

      http://askubuntu.com/questions/433924/package-denyhosts-in-ubuntu-trusty-tahr-is-deleted-temporary-or-forever

      You should use fail2ban. I’ll remove the link to denyhosts above. Thanks!

      If anyone following step 5 gets stuck with a “Connection refused” error (like I did), there may be a typo in your config file. While still logged in as root in your other terminal window, you can run the following to test the ssh config file for issues:

      sshd -T

      If there is an issue with a config file, it will tell you which one and on what line.

      If you logged out for some reason, you can use DO’s console access to log in and fix any issues.

      Cheers

      Thanks for posting this!! (sshd -T) I had a typo myself Allowuser should of been Allowusers and I couldn’t see it. This was driving me mad as everything looked correct the ssh service would start but I couldn’t get anything from netstat or ps. I kept looking at my configs just couldn’t see the typo lol! I read your post and went oh, ran the command and bam there it was! thwarted by a single character haha!

      Thanks again great very happy :)

      Thank you! Luckily I came across your post as soon as I encountered the issue.

      I have followed this tutorial and it is all working, but now I have followed the sftp tutorial too and it keeps checking port 22. With this tutorial I changed that port “to something in between 1025 and 65536”, so my question is: how do I know get SFTP to work?

      Justin Ellingwood
      DigitalOcean Employee
      DigitalOcean Employee badge
      May 2, 2014

      Piet:

      If you’ve changed the port that SSH operates on, you can tell the sftp command or your file transfer client the new port you selected.

      If you are running from the command line, you can specify a non-default port like this. If the port you selected is 4444, the command would look like:

      sftp -P 4444 username@server.com

      If you are using an (S)FTP client to connect to the server, you can input the new port in the options. For instance, in Filezilla, there is a field on the right-hand side labeled “Port” as you can see here:

      https://i.imgur.com/4FBl4vX.png

      Let us know if that works for you or not.

      I may be missing something, but if the point is to make it more secure by removing roots access, and giving another user the permissions… haven’t we just chased our own tail?

      We’re exactly where we started, except that it’s now also a username they need to know.

      Andrew SB
      DigitalOcean Employee
      DigitalOcean Employee badge
      May 5, 2014

      @drphilbobaggins: Having to guess the username is surprisingly helpful when it comes to server security. Run a server for long enough, and you’ll see many brute force attempts to SSH into the root account. So if you don’t want to disable the root user, at least create a new user and set PermitRootLogin to no in your SSH configuration.

      I am using putty to log into my server, I followed the tutorial, added user changed port and log in with putty under new settings I now receive the message: “server refused our key”

      I am then prompted for pass, for the new user I enter it and gain access. I am not sure what I have missed in the tutorial that is stopping the SSH key from authenticating.

      This authenticated when it was on default 22 and login as root.

      Went through this guide perfectly without any problem. Thank you for the write up Justin.

      It works, searched for putty tutorials, I had to add my public key for my new user /.ssh/authorized_keys and chmod 700 and 600

      Please add in the tutorial username ALL=(ALL) NOPASSWD: ALL for those that dont want to type password for sudo each time. It is not practical to type password each time thanks

      Kamal Nasser
      DigitalOcean Employee
      DigitalOcean Employee badge
      May 13, 2014

      @adsf: I wouldn’t recommend doing that. It’s insecure to leave sudo access unprotected, it’s actually more secure to type out your password every one in a while.

      Kamal Nasser
      DigitalOcean Employee
      DigitalOcean Employee badge
      April 28, 2016

      This comment has been deleted

        @adsf: If typing the password is an annoyance for you, type “sudo su” to temporarily log in as root. This is a much better option than leaving sudo access unprotected.

        When I use FileZilla and try delete index.php from /var/www/html/ I get - permission denied. How send sudo to ftp-client?

        Kamal Nasser
        DigitalOcean Employee
        DigitalOcean Employee badge
        May 27, 2014

        @timothybernerslee: You can’t use sudo or connect as root using FTP. Use SFTP instead – it’s much more secure (while the name is very similar to “FTP”, it’s not related to the FTP protocol at all): <a href=“https://www.digitalocean.com/community/articles/how-to-use-filezilla-to-transfer-and-manage-files-securely-on-your-vps”>https://www.digitalocean.com/community/articles/how-to-use-filezilla-to-transfer-and-manage-files-securely-on-your-vps</a>.

        Make sure your user has write permissions to index.php so you can delete it: <pre>sudo chown youruser /var/www/html/index.php</pre>

        After going through these steps I’m finding that ssh access is requiring a password to login (using the new user btw and not root as that is of course disabled) , in this case ssh keys were setup during droplet creation, is there another step to take to rectify this so no password is required for ssh with this new user?

        Note: initially root@droplet-ip ssh is working out of the box with no password required on this same laptop/droplet combo.

        Thanks!

        I had the same problem and it has been solved.

        Apparently, the “authorized_keys” file’s owner need to be the account username, NOT root. Login as root to change the file’s owner “chown user:user authorized_keys” will solve the problem.

        Andrew SB
        DigitalOcean Employee
        DigitalOcean Employee badge
        June 12, 2014

        You need to make sure that your public key is in the authorized_keys file for your user. Run: <pre> cat ~/.ssh/id_rsa.pub | ssh user@your.ip.address “cat >> ~/.ssh/authorized_keys” </pre>

        I got the Public Key in section 4. How can I obtain my private key? That not mentioned here and its a most confusing things newbies like me.

        Andrew SB
        DigitalOcean Employee
        DigitalOcean Employee badge
        December 11, 2014

        @bijuoosmail Running the ssh-keygen command will produce two files. Your private key, id_rsa, which should stay on your local computor, and a public key that is copied to the server id_rsa.pub

        @astarr yes its definitely in there, I’ve tried all kinds of combinations, like taking all other keys out of authorized_keys and leaving only the public key from the new pair I create, but still only the ssh login will work that is setup via DO droplet creation, no other key pair works, still requires password. Also permissions of the authorized_keys file are as they should be.

        Anything else I could be missing?

        Andrew SB
        DigitalOcean Employee
        DigitalOcean Employee badge
        June 13, 2014

        In your <code>/etc/ssh/sshd_config</code> file did you add an <code>AllowUsers</code> line? If so make sure your user is listed.

        Thanks @astarr I eventually figured a way to get it working, I had to do the following: <pre> eval ssh-agent -s ssh-add ~/.ssh/bitbucketkey </pre> and add this line… <pre> IdentityFile ~/.ssh/bitbucketkey </pre> to ~/.ssh/config

        Not sure if all of it is necessary, but following various error messages these steps resolved them and has got things working!

        Hello! I’m really REALLY new Ubuntu user. I’m trying to do this procedure to make wordpress work on my pc (I got Ubuntu 14.04 LTS), yet when I do the first step (ssh root@server_ip_address) i got this message: ssh: connect to host 192.168.1.5 port 22: Connection refused Don’t have any clue what that’s it means… so… please… some help… Thank you very much!!! :-)

        Andrew SB
        DigitalOcean Employee
        DigitalOcean Employee badge
        June 23, 2014

        @manuel.fernando.camperos: Are you trying to install Wordpress locally to your PC? If so, then you don’t need to use SSH. SSH is a way to securely connect to a remote computer. Most articles on installing Wordpress will assume that you are installing it to a server remotely.

        @astarr Thank you for your answer!! Yes that’s exactly what I’m trying to do. On the “How To Install Wordpress on Ubuntu 14.04” tutorial on step four they used “the same account that we set up during the initial server setup guide, which we called demo.” So I thought It was something important that I had to do… Isn’t? Once again thank you for your comments. :-)

        Changing the port, looking at the comments, seems to cause a lot of trouble to users and provides absolutely no additional security.

        May I suggest removing that section or at least strongly indicate that it’s for the overly paranoid?


        Authentication:

        LoginGraceTime 120 PermitRootLogin without-password StrictModes yes


        Mine looks like the above, it doesn’t just say:

        PermitRootLogin yes

        So how should it be changed?

        @gp+digitalocean

        Of course it provides additional security, do I want to target servers that I first have to sniff out the ssh port on? Or would it be easier to get the idiots who keep it at the default?

        Yes it causes problems, if you want something that “just works” get an apple product, it’s caused me hours and hours of frustration too, but each time I learn something new. Imagine how hard things would be if you were using windows for the first few times? But most of us go into the device manager or command prompt like pros and troubleshoot and fix things easily.

        Try DigitalOcean for free

        Click below to sign up and get $200 of credit to try our products over 60 days!

        Sign up

        Join the Tech Talk
        Success! Thank you! Please check your email for further details.

        Please complete your information!

        Become a contributor for community

        Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.

        DigitalOcean Documentation

        Full documentation for every DigitalOcean product.

        Resources for startups and SMBs

        The Wave has everything you need to know about building a business, from raising funding to marketing your product.

        Get our newsletter

        Stay up to date by signing up for DigitalOcean’s Infrastructure as a Newsletter.

        New accounts only. By submitting your email you agree to our Privacy Policy

        The developer cloud

        Scale up as you grow — whether you're running one virtual machine or ten thousand.

        Get started for free

        Sign up and get $200 in credit for your first 60 days with DigitalOcean.*

        *This promotional offer applies to new accounts only.