Monday, December 9, 2013

How To: Requiring RSA keys for SSHD

Many organizations or individuals make a best effort to prevent hackers from gaining access to their systems. However, some don't consider what kind of damage can be done when someone has obtained their password, using the traditional or default SSH daemon configuration.

In the case you are using a key alone, or a password -- when someone obtains either piece of information they can access your account through SSH. You can use PGP to encrypt your private key or an encrypted password database for your password, and always use a password that is never stored to add an additional layer of security. However, with both methods of authentication you have an additional piece of information a hacker must obtain to gain access to sensitive information.

Ignoring security leaves a system at the greatest risk to the most severe attacks. A strict access control schema for systems with sensitive data is essential even for when only one person is accessing that system. Investments into proactive security far outweigh the losses that happen with a breach, and the result is an overall increased profitability. If you are running a server that allows access for your organization only then this is the ideal place to implement this SSH security schema.

You can configure your SSH to require RSA keys, in sshd_config:

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys


# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no


UsePAM no

This makes it virtually impossible to brute force your account. If your organization or personal best practice does not include key management on your systems then it may be time for an adjustment in your security posture. Out of date keys belonging to accounts which no longer require access, or have too much access can prove problematic. Key management policies should be robust and require keys to be rotated out and audited on a regular frequency to eliminate any out of date security credentials, and find any accounts with access that is no longer required.