In this post I will walk you through generating RSA and DSA keys using ssh-keygen. Public key authentication for SSH sessions are far superior to any password authentication and provide much higher security. ssh-keygen is the basic way for generating keys for such kind of authentication. I will also explain how to maintain those keys by changing their associated comments and more importantly by changing the passphrases using this handy utility.
Generating Keys
Generating public keys for authentication is the basic and most often used feature of ssh-keygen. ssh-keygen can generate both RSA and DSA keys. RSA keys have a minimum key length of 768 bits and the default length is 2048. When generating new RSA keys you should use at least 2048 bits of key length unless you really have a good reason for using a shorter and less secure key. The key length for DSA is always 1024 bits as specified in FIPS 186-2. Because DSA key length is limited to 1024, and RSA key length isn’t limited, so one can generate much stronger RSA keys than DSA keys, I prefer using RSA over DSA. Another reason for not using DSA is that DSA is a government standard and one may wonder if the key length was limited deliberately so it will be possible for government agencies to decrypt it.
To generate a pair of public and private keys execute the following command:
ssh-keygen -t rsa -b 2048
You can use “dsa” instead of the “rsa” after the -t to generate a DSA key. The number after the -b specifies the key length in bits.
After executing the command it may take some time to generate the keys (as the program waits for enough entropy to be gathered to generate random numbers). When the key generation is done you would be prompted to enter a filename in which the key will be saved. The public key will have the same filename but it will end with .pub. You should make sure that the key can only be read by you and not by any other user for security reasons.
Next you’ll be prompted to enter a passphrase. Each generated key can be protected by a passphrase. When a key is generated with a passphrase, the key can’t be used without the passphrase, so by using a passphrase one can prevent others from using his private keys without first guessing the passphrase. A good passphrase should be at least 10 characters long. One should stay away from English sentences as their entropy level is just too low to be used as a safe passphrase. I usually use a randomly generated passphrase, as this kind is considered the most secure. If you intend to use the key for accessing a remote machine from inside an automated script you may wish to enter an empty password, so the script won’t need user interaction. In this case just press <ENTER> twice.
If you create a passphrase-less key just make sure you only put it on trusted hosts as it may compromise the remote machine if the key falls to the wrong hands.
After entering you passphrase twice the program will print the key fingerprint, which is some kind of hashing used to distinguish different keys, followed by the default key comment (more on key comments later). After printing the key information the program will terminate. Congratulations, you’ve just created you own public key using ssh-keygen.
Comments
Adding comments to keys can allow you to organize your keys more easily. The comments are stored in end of the public key file and can be viewed in clear text. For example:
cat id_rsa2.pub
ssh-rsa <pre lang=B3NzaC1yc2E<pre lang=BIwAAAQEAyyA8wePstPC69PeuHFtOwyTecByonsHFAjHbVnZ+h0dpomvLZxUtbknNj3+c7MPYKqKBOx9gUKV/diR/mIDqsb405MlrI1kmNR9zbFGYAAwIH/Gxt0Lv5ffwaqsz7cECHBbMojQGEz3IH3twEvDfF6cu5p00QfP0MSmEi/eB+W+h30NGdqLJCziLDlp409jAfXbQm/4Yx7apLvEmkaYSrb5f/pfvYv1FEV1tS8/J7DgdHUAWo6gyGUUSZJgsyHcuJT7v9Tf0xwiFWOWL9WsWXa9fCKqTeYnYJhHlqfinZRnT/+jkz0OZ7YmXo6j4Hyms3RCOqenIX1W6gnIn+eQIkw== This is the key's comment
As you can see the comment is appended in clear text to the end of the public key file. To alter the comment just edit the public key file with a plain text editor such as nano or vim.
To add a comment to the public key file when generating the key add to the key generation command -C "you comment". For example to generate 4048 bit RSA key with “home machine” as a comment you will do the following:
ssh-keygen -b 4048 -t rsa -C "home machine"
Notice that each copy of a public key can have its own comment and you cannot retrieve the comment from the private key.
Passphrases
Passphrases allow you to prevent unauthorized usage of your key by meaning of protecting the key itself by a password. Although your ssh directory holding the private keys should be unaccessible to other users, the root user of the system, or anyone who can achieve is privileges can access your key and copy it. In this case the passphrase will prevent him from using it.
To add a passphrase to a key just type it when prompted during the key generation process. Keep in mind that the password must be at least 5 characters long. A good passphrase, as I said before, should be at least 10 characters long, and consist of random upper and lower case letters, numbers and symbols.
While the passphrase boosts the security of the key, under some conditions you may want to leave it empty. Leaving the passphrase empty allows you to use the key from within scripts, for example to transfer a file via scp. While passphraseless keys are very useful for scripts just remember to only use them at trusted machines.
You can change the passphrase of key after it’s been created, and you should do it at least annually. To change the passphrase execute:
ssh-keygen -p
After this you will be prompted to enter the location of your private key and enter twice the new passphrase. If you don’t want a passphrase just enter empty one.
End Notes
Feel free to share your public key, as its name suggests, it should be public. Keep in mind that your private key should be kept private. If someone gets hold of your private key, change it imediatly, even if it’s passphrase protected.
hi….have gone thru the doc….think its not helpful for beginners….
–I think there shud be something like “Going thru this doc req. basic knowlege of xxxx”
perfect;
takes the fluff out;
just what a practitioner needs;
Running this command requires knowledge of keyboard usage:
ssh-keygen -t rsa -b 2048
Thanks for this 😉
Thank for this information. I has all the basic information required to generate ssh key.
Thanks Guy. I need the quick howto and the description of DSA vs. RSA made it simple and clear which to use.
Hello! I tried to generate the key without passphrase but when I try to connect to another pc OpenSSH asks for the passphrase… i just press enter and it works…
but why does OpenSSH ask for the passphrase if I didn’t set it?
I’m working on an Ubuntu PC but I think it should be the same thing on another Linux distribution, am I right?
Thank you.
I never came across such problem, it looks like there is something weird in the your ssh configuration. Take a look at /etc/ssh/ssh_config and see maybe it something you can tweak.
Hi,
good stuff. I’d appreciate a simple comment outlining the usage of the generated keys e.g. can I include them in my keychain and use them to encrypt and sign emails with the maill.app on a Mac Os X?
Thanks.
Hi Hans,
Unfortunately I don’t have any experience with the mail app on Mac, so I can’t instruct how to use the generated keys with it.
Good article – very clear and concise. It’s also good to understand the advantage of using rsa over dsa which I’d never read before.
I like the way the information is provided. Indeed the information gives a very clear understanding.
I have two questions.
1. DSA – govt Standard ,does it mean RSA cannot be decrypted?
2. Can I use rsa and dsa? Are they going to conflict each other?
thank you,
Palanikumar
1. The government doesn’t disclose any information about what they can do with it. Both are widely used so I think they should be good enough.
2. RSA and DSA are completely different algorithms. You can’t use both for the same key.
is it possible to use ssh-keygen in mainframe
It should be possible, as it is available with most *NIX distributions. However, I don’t know if it’s a good idea security wise, as someone might have tampered with the program. I think it is best to use it on a computer which only you use.
I think this article was great. First article I found that gave detail on the purpose/use of the passphrase. Thanks!
Yikes! ALWAYS encrypt your private key!!!
http://techdebug.com/blog/2008/05/08/always-encrypt-your-ssh-private-key/
Tanks for this
Is it possible to require users to enter a passphrase prompted during the key generation process?
As far as I know it isn’t possible directly with ssh-keygen. You could write a wrapper around it. Note, that you can’t know if someone is using a passphrase protected private-key or not from his public key.
Cheers Guy, thats a big help
I have generated successfully (passwordless) the private and public keys in local host(/home/MyLocalUser/.shh folder), created authorized_kes in remote host (/home/MyRemoteUser/.ssh folder) but when i try to connect(batch mode: sftp -b file.cmd MyRemoteUser@RemoteHost), i got permission denied:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: remaining preferred:
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /project/cssapp/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering public key: /project/cssapp/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,password,keyboard-interactive).
Connection closed
Try running the sshd daemon in debug mode and see its output. OpenSSH is pretty picky about the permissions applied for the ~/.ssh direcory, it could be simply that.
Make sure you run the “debug” sshd daemon on a different port along the regular one, so you won’t lose access to your machine.
It’s worth mentioning that FIPS 186.3 supercedes 186.2 and includes provisions for 4096 bit and larger DSA keys.
I want to use an RSA public/private key pair with SSH-2 to create an SSH tunnel from my Android phone to my router. I have it set up and working already. However, I initially used a 1024-bit key. Apparently, this is not enough (although many say it is). Would using a larger key (2048 or even 4096 bits) increase overhead? This is a phone, after all.
I used -f to specify output keyfile (id_rsa2) so it won’t overwrite existing one being used by an app. However, sftp only recognized the standard name id_rsa. How to make it recognize id_rsa2 on sftp?
One of the best tutorials ever!!!!! I’ve been searching how to setup SSH encryption :O
Thanks a lot! 😀
Hi, could you tell us first what is ssh-keygen? I write it on my windows 7 and it doesnt recognize the command… Thanks
I have what I already know is a stupid question. How many printed characters do the various key lengths correspond to? I’m not the SFTP tech in this particular case, only a lowly project manager. I have a public key that is 202 characters and the project manager receiving it (also not an SFTP tech) is saying “it’s not as long as our other keys”. In my understanding, that should not be a problem as long as the key is valid and meets the specification. Is there some common length that (for example), 768, 1024 and 2048 correspond to in the generated key? Is it possible that one system is setup not to accept keys shorter than X even if they are valid under the standard?