11 Steps to Secure Your Servers Part 5: Locking Remote Access

DZone 's Guide to

11 Steps to Secure Your Servers Part 5: Locking Remote Access

Part 5 of a series of posts on server security from Inversoft's 2016 Guide to User Data Security discusses locking remote access.

· Performance Zone ·
Free Resource

This is part 5 of a series of posts on server security from Inversoft's 2016 Guide to User Data Security.

Remote access is always through SSH on Linux servers. In most cases, SSH is set up to allow access to user accounts via passwords. By allowing users to log in to your server using their passwords, you allow hackers to brute force attack your server from anywhere in the world. Instead, your servers should use RSA keys to allow users to log in. This will only allow users to access the server from the computer that contains their private key. Since private keys will be password locked and never shared, this will ensure that only authorized users will be able to access the server.

To secure remote access to your servers, change server configuration so that SSH access requires RSA keys. If you are running in Amazon, some of this configuration is standard on their servers. You'll still want to verify your configuration using the steps below.

To start this process, you need to create a public/private key pair on your local computer. To generate a key pair on a Mac or Linux machine, execute this command:

$ ssh-keygen -t rsa -b 2048

This process will ask for a passphrase for the key. You should select a passphrase that is complex.

NOTE: A complex passphrase generally means it is 16 characters or longer and contains numbers, letters, and punctuation. You should always use a complex passphrase for your keys because leaving the key without a passphrase makes it much more vulnerable overall. Even if your private key is stolen or socially hacked, a passphrase will ensure it will be much more difficult to use.

Once logged in you will create an ordinary user account so that you aren't constantly logging into the root account. This also allows you to secure the machine further. To create an ordinary user account, run this command and specify the username you want to use:

$ useradd -m -G sudo -s /bin/bash your-username

This command specifies that the user should have an extra group of sudo (the -G sudo option). This group will allow the user permissions to execute superuser commands on the server.

NOTE: Some systems have passwordless sudo enabled for the sudo group. You need to disable this so that all users are forced to type in their passwords to use the sudo command.

From your terminal window that is logged into the root account, edit the file /etc/sudoers like this:

$ nano /etc/sudoers

You can also use vi if you prefer that over nano for text file editing. If you aren't familiar with vi, nano will save you a lot of headache learning vicommands. This file should contain a line that looks like this:

%sudo   ALL=(ALL:ALL) ALL

If this line looks like this:


You will want to remove the "NOPASSWD": part of the line.

Now that the user has been created, you need to set a strong password for this user. This password should be complex. To set the password for your user, execute this command:

$ passwd your-username

In another terminal window, ensure that you can log into this user account using the password you just created:

$ ssh your-username@

While you are here, you should also verify that this user has sudo access. Type this command to test for sudo access:

$ sudo ls /

You should see a directory listing of the server. However, if you see a message that says you aren't in the sudoers file, you will need to edit your /etc/sudoers file from the terminal that is logged in as root and add this line:

%sudo   ALL=(ALL:ALL) ALL

You can logout of this terminal by typing exit or hitting ctrl-d.

Next, copy your public key from your local computer to the server.

NOTE: Be sure to copy your public key only and NOT your private key. Here's the command to copy your public key to the server:

$ scp ~/.ssh/id_rsa.pub your-username@

After the public key is on the server, put the key into the ~/.ssh/authorized_keys file so that the SSH system will use it next time you log in rather than prompting for a password. Log back into the server as the ordinary user and then execute the following commands:

$ mkdir .ssh
$ chmod 700 .ssh
$ mv id_rsa.pub .ssh/authorized_keys
$ chmod 600 .ssh/authorized_keys

Now, logout of the server and log back in as the ordinary user. You should not be prompted to type in a password. You should instead be prompted to enter the passphrase you used when creating the SSH key above. If you are prompted for a password rather than the passphrase you likely renamed your key files or specified a different name when you created them. Therefore, you must use the -i flag to tell SSH to use the proper identity file for this server like this:

$ ssh -i server_rsa your-username@

The server is now ready to have the SSH system secured. In the terminal that is still logged in as root, edit the /etc/ssh/sshd_config file. You need to change a few lines in this file to prevent anyone from logging into the server without an SSH key pair and to prevent the root user from logging into the server via SSH. Find these configuration options and change their values to those below. Some of these options might be commented out because they are prefixed with a # character. Simply remove the # character and change the setting.

PermitRootLogin no
PasswordAuthentication no

Save this file and restart the SSH service like this:

$ service ssh restart

You can verify that your server is now secure by attempting to SSH to it as the root user. You should receive an error message like this:

Permission denied (publickey).

Find our Github project here: https://github.com/inversoft/2016-security-scripts. This project contains a set of scripts you can execute from your local computer to secure a remote server. 

security, security best practices, server

Published at DZone with permission of Kelly Strain . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}