I always need a reminder of how to create an ssh key - it being something you don't do all that often. The best simple starting point is probably https://help.github.com/articles/generating-ssh-keys/ . Their basic example is this:
$ ssh-keygen -t rsa -b 4096 -C "firstname.lastname@example.org"
The most commonly used command line switches:
- -t <type> - specify which type of key to create, one of "rsa1" (RSA version 1), "dsa", "rsa" (RSA version 2), "ecdsa" (Elliptic Curve Digital Signature Algorithm - recent addition), or "ed25519" (on some Linux systems, not on my Mac)
- -b <keysize> - specify the key size in bits. Read the man page: there are several very specific limitations depending on key type.
- -C "<comment>" - A string comment that's visible on the public key
- -f <filename> - specify the filename of the generated key file
Descriptions of the various signature algorithms are available on Wikipedia: it's heavy duty technical reading. There are extensive arguments online about which is the most secure. From what I've gleaned, "rsa1" is the least secure and "rsa" is both the most generally compatible and the least likely to be compromised. Regarding compatibility, I know from personal experience that "ecdsa" doesn't work with OpenWRT's dropbear (ssh) server.
I have to disagree with github's opinion that you should go with defaults on the naming of the keyfile, although - like so many things - it depends on circumstance. If you expect to have separate keys for different hosts, managing the keys and remembering which is which is much, much easier with descriptive names. I recommend having several keys for different purposes: I have to use and store my github key on several machines at work, which means that I don't want to use that same key for my private machines as I consider it less secure. Use the "-C" comment as well to distinguish between files, and add something more than just the email address.
They key size affects several things: the key generation time, encryption time, decryption time, and the amount of time required to brute-force the key. This last seems to be considered the primary measure of "security." With modern computers, the time for encryption/decryption doesn't seem to be a significant factor even for relatively large keys such as RSA/4096, so go to town.
It's possible - in fact easy - to generate keys without a passphrase: just hit enter when you're asked for the passphrase. Don't do this unless you've thought about the security implications A LOT. Keys without a passphrase have a place in automated scripts, but their authority (ie. what account(s) they can access) should be limited to read-only access for automated purposes.
With all that in mind, my revision looks only slightly different than where we started:
$ ssh-keygen -t rsa -b 4096 -C "<description of key purpose>" -f <purpose>
Linux now has a command for moving IDs to another machine: ssh-copy-id - that's not yet available on Mac. It's fairly simple:
ssh-copy-id -i <new_key> <user@hostname>
Obviously you have to have access to the target account already. If you don't have ssh-copy-id available, you'll have to go through the slightly more tedious process of copying the new_key.pub file to the target account and adding it to ~/.ssh/authorized_keys by hand.
- http://security.stackexchange.com/questions/39279/stronger-encryption-for-ssh-keys - about key structure and why it is how it is, with a bit of detail about passphrases
- http://security.stackexchange.com/questions/5096/rsa-vs-dsa-for-ssh-authentication-keys - second answer also includes interesting commentary on ecdsa and ed25519
- http://blog.patshead.com/2013/09/generating-new-more-secure-ssh-keys.html - the security of the encryption on the private key itself: different than the key encryption type