Generating an SSH Key in Linux

[scottalanmiller]

Generating your own SSH key is actually very simple and is a task the majority of Linux administrators will find themselves doing on a very regular basis. If you have never made SSH keys before this might be a little less than intuitive. There are actually different SSH packages available but Red Hat Linux, and all popular distributions, ship with the bullet-proof, field tested OpenSSH. OpenSSH is the big player in the industry and is completely open and free. It is available for pretty much every platform you can imagine and is the final word is SSH interoperability. I would never recommend using any other product for SSH, nothing is more battle tested and trusted.

OpenSSH is also the most documented and widely understood SSH implementation. Since all major UNIX variants ship with OpenSSH, you can be sure that every UNIX admin, regardless of their background, is familiar with supporting OpenSSH.

To generate our OpenSSH key for our current user we can simply use the following command:

ssh-keygen -t rsa

This command alone is enough to produce a perfectly acceptable SSH key. The default RSA key length is 2048 bits which is rather secure for most purposes. SSH allows us to choose RSA or DSA here but DSA is limited to a key length of 1024 and is generally considered not secure enough for use and is generally avoided. We will ignore it here.

When running the above command we will be asked for a passphrase. Adding a passphrase to an SSH key adds a lot of security since to use the key one much both possess the private key of the pair as well as know the passphrase used to unlock it. Unfortunately adding this level of security is cumbersome at best and, in many cases, completely defeats the purpose of having the keys at all. It is a rare person looking to use SSH keys for the purpose of additional security rather than for convenience – if that is you, kudos – go ahead and add in the passphrase. If you are like most people, the goal with keys is to allow for rapid, password free logins between machines – often for the purpose of system or task automation. So to skip the passphrase, just hit “enter” and you won’t be bothered by that again.

If you want to increase the bit depth of your RSA key for added security you can easily do so using the “b” flag. On today’s CPU rich computers, computing deep bit depth keys is rarely a concern. Doubling the bit depth to 4096 bits would look like this:

ssh-keygen -t rsa -b 4096

When the command completes you will be left with two keys, a public and a private key. As the name suggests, the public key is designed to be handed out rather freely – you can even publish it to a website or make available through whatever easy means you have available to you. The private key, however, is meant for you to keep very, very secure as it identifies you to people who are holding your public key.

By default, OpenSSH places keys into your home directory ~/.ssh/ which is hidden. Your private key will be called id_rsa and your publicly key will be id_rsa.pub.

The other main SSH tool on the market is Tectia, which from using it myself I cannot recommend against it enough. It is costly, cumbersome and has been unstable in environments where I have seen it – cumbersome and unstable are enemies of security and costly is the enemy of good business. I’m not aware of any advantages to Tectia but I am acutely aware of many disadvantages. I’ve spoken to departments that have chosen this product but have never had one been able to produce their reasoning for making the decision so I would be left with nothing but speculation.

Unlike OpenSSH which uses a “user centric” model for keys (users make them, users store them), Tectia approaches keys from an administrator standpoint and has the administrator make keys and distribute them on behalf of the users. This can create a lot of extra overhead for administrators and makes testing keys rather cumbersome. So unlike the above OpenSSH examples which are performed by the user themselves, these are performed by the administrator.

/SSHTectiaDirectory/util/generate_keys username

This command will generate the keys and place them into a central repository /etc/SSHTectiaDirectory/keys/username/ in which you will find the same public and private keys.

Initially it may seem beneficial to have key management handled by a central authority and there is an argument to that effect but, in reality, SSH keys are not designed to be an authentication system on their own and the existing authentication mechanisms should provide the correct resources for power users to manage their own keys. Keys do not grant any access that does not already exist via other means – they simply make it more convenient. So blocking the easy distribution of keys can often lead towards the same results as any over the top security practice and leave you with users working hard to “work around” the security systems rather than using them as intended.

Originally found on my Linux blog at: https://web.archive.org/web/20140823021548/http://www.scottalanmiller.com/linux/2011/04/04/generating-an-ssh-key/