If you're managing a server the most crucial tool for managing your server remotely in a secure way is SSH and it often ends up left with defaults which aren't as secure as possible in plenty of cases. This needs to change.

Generating and using private/public key pair authentication

One of those defaults is most certainly ability to use password protected logins which is scenario which should be avoided whenever is possible due to various techniques to spoof those passwords.

Imagine having a key-logger installed by an attacker for instance?
Sounds funny? Most certainly not.

Password logins should be replaced by private/public key pair logins.
Private key (remains with you at all times and shouldn't be shared) serves to authenticate or 'match' the public key stored on remote computer you're trying to access.

Using only keys doesn't add much to security if they're accessible to 3rd parties and can be stolen. That way 3rd party would have free access to your server without even having to type in a password, of course, having in mind that they can guess the username which is always drastically less secure and easier to guess than password itself.

Some people actually still think that primary usage of SSH key pairs is to let you login remotely without having to type in the password (could that sound lazier?)

That's why keys should be protected with passphrase you'll have to enter each time you issue a SSH connection to your server. Look at it like a two-factor authentication method you can use to access Google for instance. Nothing is really 100% secure but having additional obstacle to attacker might save you from a lot of trouble and potentially from loosing your job.

To generate a decent key pair you'll have to issue this command (make sure to change 'secretpassphrase' to minimum 4 characters):

ssh-keygen -t rsa -b 4096 -N 'secretpassphrase' -f openssh.key

There are couple of key types which can be used (RSA, DSA, ECDSA) and some offer better performance/security over others but that's the other topic and out of scope of this tutorial. For this purpose we'll settle with industry standard, RSA. Also, keep in mind that number of key bits (key length) can affect performance if too long.

This is the rest of flags you can send to ssh-keygen:

-B — show the bubblebabble digest of key
-C — provide new comment
-D — download key stored in smartcard reader
-N — provide new passphrase
-P — provide old passphrase
-U — upload key to smartcard reader
-b — specify number of bits in key
-c — change comment in private and public key files
-e — export key to SECSH file format
-f — key file
-i — import key to OpenSSH format
-l — show fingerprint of key file
-p — change passphrase of private key file
-q — silence ssh-keygen
-t — specify the type of the key to create
-y — get public key from private key

You'll be presented with 2 key files in current working directory (openssh.key, openssh.key.pub). Private one, and public one, ending with .pub suffix.

Next, permissions of keys should be tighten up in order for other users (if multi user environment is used) not to have access to them and that only an owner has the right to use them.

chmod go-rwx openssh.key*

That being done, you're ready to copy your new public key to your server.
That can be done in multitude of ways, by using FTP, SCP, whatever.

For this purpose, we'll be using SSH's identity copy method (ssh-copy-id) provided solely for this purpose. ssh-copy-id copies the local public key to the remote host's .ssh/authorized_keys file.

ssh-copy-id -i ~/.ssh/openssh.key [email protected]

The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established. RSA key fingerprint is 2f:55:cf:d2:67:c8:a3:54:20:bf:84:c8:56:fb:53:94. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '111.111.11.111' (RSA) to the list of known hosts. *[email protected]'s password: [input your password here]* Now try logging into the machine, with "ssh '[email protected]'", and check in: ~/.ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting.

To login with your new pair of keys issue:

ssh -i openssh.key [email protected]

And you'll be presented with dialog to enter your passphrase. Enter it and start your SSH session:

Enter passphrase for key '/root/openssh.key':

Setting Restrictive Access Policy

As we turned successfully enabled ssh key authentication, smart would be to disable password authentication altogether so users would only have to use their keys to access the server.

Fire up your text editor to edit a SSH server config file:

vim /etc/ssh/sshd_config

Look for 'PasswordAuthentication', (uncomment if needed) and change to:

PasswordAuthentication no
PermitEmptyPasswords no
Pretty much self-explanatory.

Additionally change these options:

StrictModes yes
The option StrictModes specifies whether ssh should check user's permissions in their home directory and rhosts files before accepting login. This option must always be set to yes because sometimes users may accidentally leave their directory or files world-writable.

LoginGraceTime 120
LoginGraceTime specifies how long in seconds after a connection request the server will wait before disconnecting if the user has not successfully logged in.

PermitRootLogin no
This specifies whether root can log in using ssh. Never say yes to this option, rather use regular user to log in and use sudo/su to gain admin privileges.

IgnoreRhosts yes
This specifies whether rhosts or shosts files should not be used in authentication. For security reasons it is recommended not to.

Changing Default Ports

Other important thing about SSH is that it listens on default port 22 which is usually left that way for user's convenience. Bad thing about it is that it's predictable and that it can be used to exploit server setup further (brute-force attacks for example).

Changing port to some other, lesser known and predictable one can add additional layer of security to your box. Just to be clear, it can be found either way but just a little bit harder. If you make it hard enough for attackers, they might eventually leave you alone and pick some other, less secure box to play with.

Search for 'Port' line in your /etc/ssh/sshd_config (should be at the top) and change default 22 to say a 50904

Port 50904

Restricting Access to Groups

You can easily deny access to certain group of users (blacklisting) as well as individual users by setting:

DenyGroups groupname
or
DenyUser username

Also, you can choose to use whitelist approach to only let certain users access the server and block all others by using:

AllowUsers
or
AllowGroups

You can add new/modify existing users to add them to whitelisted/blacklisted group by issuing:

usermod -g groupname username

Wrapping it up

Upon modifying and saving changes to sshd config file you should restart the ssh service. On Debian this is done with:

service ssh restart

Consult your OS documentation on how to do it in your particular environment.

Also there ar certain umber of tricks to secure the protocol even more:

• fail2ban: firewalls brute force attempts
• TCPWrappers: white/blacklist connection to daemon
• iptables: to rate-limit incoming connections

You may now connect to your server via ssh with your new ssh key pair on port you defined above and enjoy a little bit more secure box.