Initial Server Setup with Ubuntu

Install GUI 

If you want a fully-featured GUI as though you’d installed regular Ubuntu, Xubuntu, Kubuntu, or Lubuntu, but without the applications that come with them, then you can install one of these packages with the –no-install-recommends flag:

sudo apt-get --no-install-recommends install ubuntu-desktop

To start your GUI, run startx. Note that it may require substantial manual configuration, for it to be to your liking, depending on your needs.

Desktop resize :

$ xrandr
Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192
VGA1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 410mm x 230mm
   1366x768       59.8*+
   1024x768       75.1     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   640x480        72.8     75.0     66.7     60.0  

$xrandr -s  1366x768

Root Login     

To log into your server, you will need to know your server’s public IP address. You will also need the password or, if you installed an SSH key for authentication, the private key for the “root” user’s account.

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):

ssh root@your_server_ip

SSH Login as Root

Now that you have all of the required information and software, you are now ready to log in to your server for the first time. Make sure to only follow the instructions that are relevant to your SSH client.

Option 1: OpenSSH (Linux and Mac OS X)

The OpenSSH ssh client is a command-line tool, so open a Terminal window to get started.

$ apt-get install openssh-server
$ service ssh restart


Step 1 — Initiate the Connection

At the command prompt, enter the following command to attempt to connect to your server as the root user (subsitute the highlight word with your server’s IP address):


For example, if the server IP address was, the command would look like this: ssh root@

The first time you attempt to connect to your server, you will likely see a warning that looks like this:

The authenticity of host ' (' can't be established.
ECDSA key fingerprint is
Are you sure you want to continue connecting (yes/no)?

Go ahead and type yes to continue to connect. Here, your computer is telling you that the remote server is not recognized. Since this is your first time connecting, this is completely expected.

 Skip to step 2, Authentication.

If you happened to destroy a droplet directly prior to creating the one that you are connecting to, you may see a warning like this:

Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.

If this is the case, your new droplet probably has the same IP address as the old, destroyed droplet, but a different host SSH key. This is fine, and you can remove the warning, by deleting the old droplet’s host key from your system, by running this command:


Now try connecting to your server again.

Step 2 — Authenticate

The authentication step involves providing a password and/or a private SSH key to prove that you are authorized to log in as root.

If you added an SSH key to your Droplet, and you have the private key installed on your computer, OpenSSH will attempt to use the key to authenticate to the root account. If you used a key with a passphrase, you will need to provide the passphrase to complete the login process. At this point, if you are unable to log in, you may need to start your ssh-agent and add your SSH keys to it with the following command (assuming your key is called “id_rsa”), then go back to Step 1:

eval `ssh-agent -s`

ssh-add ~/.ssh/id_rsa

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 “sammy”, but you should replace it with a username that you like:

adduser server1

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.

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 “superuser” 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 16.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):

usermod -aG sudo server1

How To Modify the Sudoers File

You will be presented with the /etc/sudoers file in your selected text editor.

I have copied and pasted the file from Ubuntu 16.04, with comments removed. The CentOS /etc/sudoers file has many more lines, some of which we will not discuss in this guide.

vi /etc/sudoers
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

root    ALL=(ALL:ALL) ALL

%admin ALL=(ALL) ALL
%sudo   ALL=(ALL:ALL) ALL

#includedir /etc/sudoers.d

User Privilege Lines

The fourth line, , which dictates the root user’s sudo privileges, is different from the preceding lines. Let’s take a look at what the different fields mean:


The first field indicates the username that the rule will apply to (root).


The first “ALL” indicates that this rule applies to all hosts.


This “ALL” indicates that the root user can run commands as all users.


This “ALL” indicates that the root user can run commands as all groups.


The last “ALL” indicates these rules apply to all commands.

Group Privilege Lines

The next two lines are similar to the user privilege lines, but they specify sudo rules for groups.

Names beginning with a “%” indicate group names.

Here, we see the “admin” group can execute any command as any user on any host. Similarly, the sudo group can has the same privileges, but can execute as any group as well.

Execute sudo without Password?

Open terminal window and type:

sudo visudo

In the bottom of the file, type the follow:


Here, we see the “admin” group can execute any command as any user on any host. Similarly, the sudo group can has the same privileges, but can execute as any group as well.

Add Public Key Authentication (Recommended)

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):

$ ssh-keygen -t rsa

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,, 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!

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

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

The key fingerprint is:

a9:49:2e:2a:5e:33:3e:a9:de:4e:77:11:58:b6:90:26 username@remote_host

The key’s randomart image is:

+–[ RSA 2048]—-+

|     ..o         |

|   E o= .        |

|    o. o         |

|        ..       |

|      ..S        |

|     o o.        |

|   =o.+.         |

|. =++..          |

|o=++.            |


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.

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:

ssh-copy-id server1@your_server_ip

$ scp -r /root/.ssh/* server1@your_server_ip:/root/.ssh 

$ chmod 700 ~/.ssh

$ chmod 600 ~/.ssh/authorized_keys

ssh  server1@your_server_ip “chmod 700 .ssh; chmod 640 .ssh/authorized_keys”

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 (

cat ~/.ssh/

This should print your public SSH key, which should look something like the following: 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.

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 temporarily switch to the new user (substitute your own user name):

su – server1

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:

mkdir ~/.ssh
chmod 700 ~/.ssh

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

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:

chmod 600 ~/.ssh/authorized_keys

Disable Password Authentication (Recommended)

Now that your new user can use SSH keys to log in, you can increase your server’s security by disabling password-only authentication. Doing so will restrict SSH access to your server to public key authentication only. That is, the only way to log in to your server (aside from the console) is to possess the private key that pairs with the public key that was installed.

To disable password authentication on your server, follow these steps.

As root or your new sudo user, open the SSH daemon configuration:

sudo nano /etc/ssh/sshd_config

Find the line that specifies PasswordAuthentication, uncomment it by deleting the preceding #, then change its value to “no”. It should look like this after you have made the change:

sshd_config — Disable password authentication

PasswordAuthentication no

Here are two other settings that are important for key-only authentication and are set by default. If you haven’t modified this file before, you do not need to change these settings:

sshd_config — Important defaults

PubkeyAuthentication yes

ChallengeResponseAuthentication no

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).

Type this to reload the SSH daemon:

sudo systemctl reload sshd

Test Log In

Now, before you log out of the server, you should test your new configuration. Do not disconnect until you confirm that you can successfully log in via SSH.

In a new terminal on your local machine, log in to your server using the new account that we created. To do so, use this command (substitute your username and server IP address):

ssh sammy@your_server_ip

If you added public key authentication to your user, as described in steps four and five, your private key will be used as authentication. Otherwise, you will be prompted for your user’s password.

Set Up a Basic Firewall

Ubuntu 16.04 servers can use the UFW firewall to make sure only connections to certain services are allowed. We can set up a basic firewall very easily using this application.

Different applications can register their profiles with UFW upon installation. These profiles allow UFW to manage these applications by name. OpenSSH, the service allowing us to connect to our server now, has a profile registered with UFW.

You can see this by typing:

sudo ufw app list
Available applications:

We need to make sure that the firewall allows SSH connections so that we can log back in next time. We can allow these connections by typing:

sudo ufw allow OpenSSH

Afterwards, we can enable the firewall by typing:

sudo ufw enable

Type “y” and press ENTER to proceed. You can see that SSH connections are still allowed by typing:

sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)

If you install and configure additional services, you will need to adjust the firewall settings to allow acceptable traffic in

Functions :

Allow Incoming SSH from Specific IP Address or Subnet

sudo ufw allow from  to any port 22

Allow MySQL from Specific IP Address or Subnet

sudo ufw allow from to any port 3306

Disable Firewall :

$ sudo ufw disable 

Check the Version of Server :

 lsb_release –a

Install lsb core :

sudo apt-get install lsb-core

Configure Network Manager 

Install the network-manger package

apt-get install network-manager

Edit the config file :


Do the following changes 


Enable Root User Login (not recommended )

sudo passwd

Open the below link 

sudo gedit /usr/share/lightdm/lightdm.conf.d/50-unity-greeter.conf

Add the below line 



Edit /etc/gdm/custom.conf file and include AllowRoot=true.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Powered by

Up ↑

%d bloggers like this: