user@computer:~$ sudo awk 'gsub(".*sshd.*Failed password for (invalid user )?", "") {print $1}' /var/log/auth.log* | sort | uniq -c | sort -rn | head -5
 11 root
 9 admin
 6 sales
 2 user

So how do you secure your ssh server so that inquisitive people across the globe can’t access and harm your sensitive data?

Before we start.

Most of the settings we discuss exist in the SSH config file, /etc/ssh/sshd_config. To edit this file, use your favourite text editor (gedit, nano, vi, whatever) as root, as you’ll need elevated rights to save the file afterwards.

When you’ve made a change and want to apply it, restart the SSH server by performing the following command as root (or via sudo):

/etc/init.d/ssh restart

Finally, if you’re using this guide to secure a remote server, make a backup of sshd_config before you start, and keep your active SSH connection running when you do a restart. Perform your tests with a new SSH session, and if you can’t connect, go back to your original session, restore the backup of your sshd_config and restart the server to roll things back.

Step 1: Install SSH (if you haven’t already).

For Ubuntu or Debian:

sudo apt-get install openssh-server

Fedora should already have installed the required packages, so you should only need to do the following:

/sbin/service sshd status

to see if the service is running. If it’s not, then you can do this:

/sbin/service sshd start

to start it, and

su -
yum install openssh-server

to install it.

If you’re using a different Linux distro or a flavour of Unix, then jump on to google and type “install ssh server ” to hunt down a howto.

Step 2: Choose a strong password.

A strong password is crucial for every account on your machine – Especially root, as it’s the most commonly attacked account. You can test the strength of passwords on your system with John the Ripper – if it doesn’t take long to crack, then it’s time to change your passwords to something stronger.

Your password should:

• Be at least 8 characters long. 12 is better.
• Contain upper and lower case letters
• Contain at least one number
• Contain at least one special character
• Still be easy for you to remember

A strong, yet easy to remember password would be:

MyP@55w0rD42

To change your password, do the following from a terminal:

user@computer:~$ passwd
Changing password for user.
(current) UNIX password:
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

Step 3: Restrict logins to protocol 2.

The older SSH protocol 1 is pretty insecure. Restrict connections to protocol 2:

#Protocol 2,1
Protocol 2

Step 4: Don’t use port 22.

Port 22, the default TCP/IP port for SSH, is the first place script kiddies are going to look when they’re attacking your system. It’s best to use a completely different port, either by redirecting port 2222 (for example) on your firewall, or by editing your sshd_config file as follows:

#Port 22
Port 2222

Step 5: Restrict which users can connect.

By default, your SSH server will allow every user on your computer to connect remotely. We can restrict who can connect in three ways.

First, we can disable the root account:

#PermitRootLogin yes
PermitRootLogin no

Second, we can define a white list of users:

AllowUsers fred bob jane

Third, we can restrict access to only a group of users:

AllowGroups sshaccess

and then add the required users to the sshaccess group like this:

user@computer:~$ sudo usermod -a -G sshaccess

Step 6: Restrict which parts of the ‘net can access your machine.

If you know that you’re only going to connect from work (let’s say it’s 210.215.55.243), as well as from other computers in your home network (assuming you’re using the 192.168.0.0/24 subnet), you can block all other IP addresses from accessing your SSH server. To do so, add the following lines to /etc/hosts.allow

sshd: 192.168.0.0/255.255.255.0
sshd: 210.215.55.243

So now the entire 192.168.0.0 subnet can connect, as well as your work IP address. You can then block everyone else from accessing by adding the following line to /etc/hosts.deny

sshd: ALL

Step 7: Make it harder for attackers to get a foothold.

By default, unauthenticated sessions (connections where the server is waiting for a username or password) allow ten connections to your machine, all of which will have two minutes to authenticate before the system boots them out. This means that attackers can potentially have a few attacks running concurrently.

You can cut these options by adding the following lines to your sshd_config:

#LoginGraceTime 2m
LoginGraceTime 30

#MaxStartups 10
MaxStartups 3

Thirty seconds is plenty of time to enter your username and password. The second section reduces maximum login attempts to 3 (which can increased if you have lots of people logging in). You can also add some extra options to MaxStartups to force the system to drop extra connection attempts at random – check man sshd_config for more info.

Step 8: Require keys.

Part of the SSH suite is public/private keys, where the server has a public key and your local workstation has a private key. Without the correct private key, connections will be rejected.

Step 8.1: Create a private key on your local Linux workstation.

user@local:~$ mkdir ~/.ssh
user@local:~$ ssh-keygen -t rsa

Enter a passphrase to further secure the key, or you can press enter if you don’t want one.

This will create two new files in the .ssh directory: id_rsa and id_rsa.pub, where the former is your private key and the latter is the one which you need to put on your remote server:

user@local:~$ scp ~/.ssh/id_rsa.pub user@remote:/home/user/.ssh/authorized_keys

Then log in to your remote server and make sure that you’re the only one who can access it:

user@remote:~$ chown user:user /home/user/.ssh
user@remote:~$ chmod 700 /home/user/.ssh
user@remote:~$ chmod 600 /home/user/.ssh/authorized_keys

Step 8.2: Create a private key on your local Windows workstation.

PuTTY is my SSH client of choice, as it’s simple, lightweight, and offers a really complete feature set. It even includes a serial option, which is handy for logging in to routers, switches and phone systems, which I tend to do regularly. When you get a copy of PuTTY, you can also download PuTTYgen – an RSA key generator for creating a public/private key pair.

Launch PuTTYgen, Change the number of generated bits to 2048 and press Generate:

Move your mouse cursor around in the blank area to create some random information, which is used to generate the cipher:

Once the generation has finished, you’ll see a window like this:

The top field is your new public key, which we’ll copy over to the server in a moment. Moving down we have the key fingerprint, a comment for the key, and the key passphrase. If you want to have a passphrase in addition to the key, enter it here. If not, leave it blank.

Next, press “Save public key” and “Save private key” and save the two files to a safe place on your local workstation.

Next, we have to copy the public key over to our remote computer. Highlight the content in the top section and copy it to your clipboard:

SSH into your remote computer and paste the key into ~/.ssh/authorized_keys with your favourite text editor, then restrict the file so it can only be accessed by you:

user@remote:~$ chown -R user:user /home/user/.ssh
user@remote:~$ chmod 700 /home/user/.ssh
user@remote:~$ chmod 600 /home/user/.ssh/authorized_keys

Finally, tell PuTTY to use the private key any time you’re connecting to the server by editing the entry in your hosts list:

Step 8.3: Disable password logins on your server’s SSH config.

Again, keep a connection active after you’ve done this in case you’ve messed something up, because from this point on you won’t be able to access your server without your public/private key pair.

Add the following line to your sshd_config file:

PasswordAuthentication no

Once that’s done and you restart your server, anyone who doesn’t have their keys set up will simply be rejected outright.

user@othermachine:~$ ssh remote
Permission denied (publickey).

Your SSH server is vulnerable unless properly secured. Make a backup of your ssh config file:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.old

Then save the following as /etc/ssh/sshd_config and restart your sshd service:

# Secure SSHD Config

# Listen on a different port
Port 2222

# Only accept more secure protocol
Protocol 2

# Don't accept root logins
PermitRootLogin no

# If you want to use secure keys instead of passwords
# change the following to no
PasswordAuthentication yes

# Don't allow your users to have empty passwords
PermitEmptyPasswords no

# Don't allow X11 Forwarding
X11Forwarding no

# Don't bother looking up remote DNS entries
UseDNS no

# Don't use Pluggable Authentication Module
# we'll use passwords or keys instead
UsePAM no

# Add your username below so only you can connect
# Then uncomment the line
# AllowUsers YOURNAME