When you first create a new Debian 8 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.
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):
- 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.
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.
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:
- 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.
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.
Debian 8 doesn’t come with
sudo installed, so let’s install it with apt-get.
First, update the apt package index:
- apt-get update
Then use this command to install sudo:
- apt-get install sudo
Now you are able to use the
To add these privileges to our new user, we need to add the new user to the “sudo” group. By default, on Debian 8, users who belong to the “sudo” group are allowed to use the
root, run this command to add your new user to the sudo group (substitute the highlighted word with your new user):
- usermod -a -G sudo demo
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.
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):
Assuming your local user is called “localuser”, you will see output that looks like the following:
ssh-keygen outputGenerating 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!
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.
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.
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.
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 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.
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/id_rsa.pub
This should print your public SSH key, which should look something like the following:
id_rsa.pub contentsssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBGTO0tsVejssuaYR5R3Y/i73SppJAhme1dH7W2c47d4gOqB4izP0+fRLfvbz/tnXFz4iOP/H6eCV05hqUhF+KYRxt9Y8tVMrpDZR2l75o6+xSbUOMu6xN+uVF0T9XzKcxmzTmnV7Na5up3QM3DoSRYX/EP3utr2+zAqpJIfKPLdA74w7g56oYWI9blpnpzxkEd3edVJOivUkpZ4JoenWManvIaSdMTJXMy3MtlQhva+j9CgguyVbUkdzK9KKEuah+pFZvaugtebsU+bllPTB0nlXGIJk98Ie9ZtxuY3nCKneB+KjKiXrAvXUPCI9mWkYS/1rggpFmu3HbXBnWSUdf firstname.lastname@example.org
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 switch to the new user (substitute your own user name):
- 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:
- 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.
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
Type this command once to return to the
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.
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:
- nano /etc/ssh/sshd_config
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.
To disable remote root logins, we need to find the line that looks like this:
You can modify this line to “no” like this if you want to disable root login:
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 (
Now that we have made our changes, we need to restart the SSH service so that it will use our new configuration.
Type this to restart SSH:
- systemctl restart ssh
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. 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.
- ssh demo@SERVER_IP_ADDRESS
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:
- sudo command_to_run
If all is well, you can exit your sessions by typing:
At this point, you have a solid foundation for your Debian 8 server. You can install any of the software you need on your server now.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
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!
Click below to sign up and get $200 of credit to try our products over 60 days!
Great tutorial. Worked like a charm.
I’m guessing most people that would be attempting this would already know this but just in case…
ssh-copy-iddoesn’t ship with OSX but if you have Homebrew installed (you should, or equivalent package management software, if not you probably shouldn’t be attempting this), you can install it with:
brew install ssh-copy-id
Thank you for the post!
However, section about manual copy of the newly generated SSH key is redundant — there is much more efficient way. On your host type:
<server>is your server’s IP. It will do the rest by itself helping to avoid the hustle. Also it is less error-prone as the user doesn’t have to create directories, set correct permissions and even put the key into clipboard.
Also I wouldn’t recommend remapping the default SSH port as it degrades interoperability and doesn’t add much security (it’s still easy to use
nmapto find the new SSH port and continue attempts to login with guessed password).
Much better solution would be: set up public key authentication and completely disable password authentication. It is done similarly to restricting the root login: edit
nano /etc/ssh/sshd_configand set:
This will eliminate brute force attacks without remapping SSH default port.
Nice work m8 ! kudos, simple and useful!
SSH french tutorial : https://www.visionduweb.eu/wiki/index.php?title=SSH
I have a few questions about the public key and disabling root access. I use Win SCP quite a lot instead of Nano because as a totally-blind user, I find notepad to be more accessible than using Nano or Win SCP’s internal editor. If I disabled root access, how can I change file ownership and permissions, or move and delete files in Win SCP as the root user? Also, I currently have Windows 10 and Windows Power Shell with Scoop’s Open-SSH. I tried using ssh-keygen, but it said it failed to create a directory in a certain path. Luckily, I have a Linux subsystem that is included in the Windows 10 anniversary, and it also comes with the ssh-copy-id , so I was able to use that to copy the publickey to the .ssh folder of my VPS.
Thank you for the post!
At present, it seems that login using password is disabled by default. Password sent to the mail on creating a droplet for the first time --but not adding SSH key before creating the droplet, is good only for changing the root password. However, the new self-created password can not be used for log in using PuTTY (Windows) or SSH (Linux based OS).
Therefore it is advisable to create the SSH key pair on your system before creating the droplet. And save your public key in “Add your SSH keys” (AYSK) section before hitting the “create” button on “Create Droplets” page.
If you are using PuTTY Key Generator (PKG), copy the public key directly from the PKG’s dialogue box, and paste it in “Add your SSH keys” section. Because when PKG saves the public key file, it modifies the preamble and postscript of the public key. Therefore, if you try to use public key from the PKG saved file, AYSK is not able to parse it correctly to be a valid RSA key, and may complain.
This would be great if you have time to give back comment about a set-up script I just wrote: https://github.com/MattDelac/set_up_security_server/
All comments are welcome Thanks
PuTTY Fatal Error Couldn’t agree a client-to-server cipher (availble: aes128-ctr,aes192-ctr,aes256-ctr,email@example.com@openssh.com, firstname.lastname@example.org
did not work for me , but this did