Create a new RSA keyfile for SSH

When you consider creating a new RSA or DSA keyfile, you do it with the knowledge that it will provide increased security when logging into a server using SSH. Requiring a RSA key as a security credential in the SSH authentication process is a more secure access management policy. Properly managing your credentials to maintain access and security can prevent problems, and increase profitability. 

There are at least three potential security related problems with traditional SSHD configuration.

1. Credential loss/theft
2. Potential Bruteforcing
3. Out of date access

We also discussed some solutions for eliminating and minimizing the risk of these problems.

1. Encrypted credentials (PGP encrypted username, password, key file)
2. Requiring a key, as well as a username and password
3. Rotating keys, audits

For those of you who are new to ssh keys, you can create a create a new key easily using the ssh-keygen command. This command allows the generation, management, and conversion of authentication keys. You only need to enter the ssh-keygen command to create an RSA keyfile, where the -t flag is used to specify the type of key to be generated, e.g.

ssh-keygen -t rsa
ssh-keygen -t rsa -f ~/.ssh/id_rsa         (default location)

When creating a new RSA key you can choose to leave the passphrase blank; press enter when asked to put in a passphrase. This will allow you to log into an SSH server without entering a passphrase. For stronger security add a second factor of authentication on the private keyfile and choose a passphrase.

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

and

# 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

and

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.