Home > Support > HOWTO List > Linux > Managing user accounts

Working with Linux howtos

Securing Your Server: Managing ssh access

All our servers come with ssh access. By default ssh is pretty secure, however there are a few measure you can take to step up the security a bit, especially in older installs.

Enforcing modern standards

You can find various settings located in /etc/ssh/sshd_config. We recomend the below values as a good default. Remeber to restart the ssh service after changing this file. Before logging off, test logging in to the server via a separate terminal to make sure the changes have not blocked you.

#disable protocol 1
Protocol 2
#reduce maximum login attempts
MaxAuthTries 4
#move ssh from default port (22), example, other numbers can be used
Port 2022
#decrease time user has to authenticate
LoginGraceTime 30s
#deny root user to authenticate without ssh keypair
PermitRootLogin without-password
#throttle concurrent login attempts
#allow 3 concurrent connections and randomly reject additional attempts (75% probability)
#until 10 connections are running concurrently.  anything beyond 10 is rejected
MaxStartups 3:75:10

Generating SSH Keypairs

SSH uses asymmetric keys, which is a fancy way to say a key has two different parts, a private component which you keep to yourself, and a public half which you can place on the target server. When connecting to a server SSH matches the private and public key using mathematical algorithms. Only the one private key can ever work with a given public key.

Using cryptographic keypairs for authentication means you dont have to remeber complicated passwords. You also gain the option to completely disable password authentication on your server, making your server more secure since then password guessing is no longer possible.

#generate public/private keypair
~# ssh-keygen -b 2048 -C user@domain.com

The above command will generate both the public (eg id_rsa.pub) and a private keyfile (eg id_rsa). Refer to the man page for more detailed options.

You can copy the public key to a target host with the following command. Or manually copy paste it into the .ssh/authorized_keys file there.

#copy contents of public key to your list of authorized keys
~# ssh-copy-id -i .ssh/id_rsa.pub root@yourserverip

If your home system is running Linux, you can use that keyfile directly to authenticate via ssh. If you are connecting through Putty, you'll want to download a copy of Puttygen and use that to convert your private key into a format which is compatible with Putty.

Security considerations for key pairs.

When you generate the key, if you prefer to not have a password on that, just leave that field blank. This is only fine provided you are confident the ssh key is not at risk. Or if you are using the key pair in a script.

Use at least 2048 bit keys, this should be the default unless you are on an old install. We also recommend the use of rsa type keys, dsa keys have some issues that make them potentially less secure over time.

Do not leave the private key file on your server you are using it to authenticate to the same server

When using ssh keys, its important to keep them secure. the ssh daemon also enforces this by ignoring keys that are stored with weak permissions. Take a look a our Enabling access page for tips on this.

Preventing abuse of ssh services

Since ssh runs on a well known port by default (22), it is an easy target for hackers/bots trying to guess account passwords (provide that is still enabled, see above). This can create a lot of noise in your logs, and wastes valuable resources as well (cpu/network).

In addition to limiting concurrent login attempts and changing the default port, we recommend using fail2ban to automatically block connections from naughty IPs. On new Ubuntu and Debian installs this should be enabled by default. You can easily install the package if it is not present though, with "apt-get install fail2ban", or "yum install fail2ban"

Out of the box on CentOS (6 or 7), fail2ban comes with an ssh rule that is not enabled. To enable it do this:

cat <<EOFJAIL > /etc/fail2ban/jail.local
[DEFAULT]
# Ban hosts for one hour:
bantime = 3600

# Override /etc/fail2ban/jail.d/00-firewalld.conf:
banaction = iptables-multiport

[sshd]
enabled = true
EOFJAIL

Once that is done, (re)start fail2ban. For example, on CentOS 7

systemctl restart firewalld.service
systemctl enable fail2ban.service
systemctl restart fail2ban.service
sleep 5
fail2ban-client status

The sleep 5 is there to enable the fail2ban service to start up completely including checking log files. You should see output like this:

Status
|- Number of jail:      1
`- Jail list:   sshd

This command will show the fail2ban jails as firewall rules. At the end of that list you should see something like the output below.