Do I have to mind something specific when using public keys and SSH? Well of course, I have to keep my private key secret (and therefore I should choose a strong pass phrase). But is there something else? When running ssh-keygen is it a good idea to use the default options? The 2048bits are a good choice? I read somewhere that 4096 would be recommendable nowadays. Can I use a better random generator (e.g. user input)? Do I have to renew my key pair regularly just for the case that somebody else stole it without my knowledge? In what cases a validity interval should be used?

These are many questions, but I don think it would be usefull to split them up into several questions. I'm interested in the question what to look for, when dealing with SSH/public keys (also if there are aspects I haven't mentioned yet).

Related questions:

1 Answer 1


You should trust the default options of ssh-keygen and not try to fiddle with random sources and so on. These are delicate matters. You can rely on the OpenSSH developers for having done things correctly -- you can rely because you already rely on them for having done a proper, leak-free implementation of the OpenSSH protocol, something which is far from easy.

For RSA, DSA, ElGamal, Diffie-Hellman, and similar algorithms, 2048-bit keys are enough. Estimating the strength of such algorithms in a meaningful way is not easy, because the best known attack algorithms rely on an awful lot of raw CPU power but also memory, storage, data bandwidth, and applicability of parallel computing of linear algebra on huge spare matrices. So such estimates must guess how future computing architectures and envisioned specialized circuits will fare against a number of more-or-less orthogonal scales, and the whole thing is more about divination than scientific prediction. Nevertheless, some have tried to establish guidelines, see this site for a compendium of existing rulesets that have been published. For instance, NIST states that 2048-bit RSA or DSA keys are fine until at least year 2030; note that the same NIST says that 1024-bit RSA keys should not be used beyond 2010, and yet we are now in 2012 and nobody still knows how to actually crack a 1024-bit RSA key (current record is for a 768-bit RSA key).

You are right in protecting your private key storage. This does not necessarily calls for a passphrase, though: in some contexts, the private key may reside in a desktop systems which is physically protected, and that could be deemed secure enough. Yet, strong passphrases are a nice reflex to have, and I can only encourage them.

As for key renewal, I would rather advise against it. Key renewal is a relatively complex operation because you have to transport the public keys to all relevant places (the .ssh/authorized_keys on the servers to which you want to connect); if you forget one, then you will have to engage in a recovery procedure later on, and recovery procedures are, by definition, breaches of security. Controlled breaches, but breaches nonetheless. So you should renew your key only insofar as it helps you sleep at night, but key renewal is likely to be overdone. Remember that if an attacker can obtain your private key once, then he can plant his own public key in all the servers himself: changing your key will not stop him. So key renewal has relatively little impact on security anyway.

  • 1
    Thanks for your detailed and well explained answer! But you didn't convince me to refrain form key renewal. I could just keep my old private key, then there would be no need for a recovery procedure? (if the key is valid forever) But I didn't think about the attacker's possibility to plant his own public key in my system, that's a good hint. It means I'd have to check known_hosts very carefully on key renewal.
    – lumbric
    Commented Jan 12, 2012 at 15:53
  • When you create a new pub/private key pair for ssh you can (and should) always make a backup of the old ones. Just rename the files id_rsa and id_rsa.pub (if you use RSA) in ~/.ssh/. Then (after creating new keys) you will still be able to log in to sites that do not have the new key yet. You would only need to do ssh -l user -i ~/.ssh/id_rsa-2008 hostname or whatever where id_rsa-2008 and id_rsa-2008.pub are your old keys. That could also be written to ~/.ssh/config (per-Host settings) if you do not want to replace the keys on the servers.
    – Ned64
    Commented Jan 25, 2017 at 22:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .