Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

To make setting up passwordless SSH easier on new machines and environments, is there any reason why the id_rsa.pub file (just the public half of the key pair) could not be published somewhere on the web? For example in a dotfiles GitHub repository.

I'm aware that:

  • the id_rsa file (the private half of the the key pair) must be carefully guarded and
  • the key pair should be protected with a passphrase

But my searches haven't turned up any explicit advice that this is allowed or encouraged.

Out of curiosity, would the same advice hold for a keypair without a passphrase?

share|improve this question
2  
While it might be safe in the general case (assuming a properly generated key), flaws have existed in the past (the famous Debian OpenSSH bug) that severely restricted the keyspace and left the private key guessable based on the public key. So there is always that risk - how do you know that your SSH keygen doesn't suffer from a similar flaw? –  Bob Mar 26 at 0:44
2  
One mechanism for this already exists: ssh-import-id –  MikeyB Mar 26 at 1:06

4 Answers 4

up vote 22 down vote accepted

RSA is specifically designed to allow you to share that public key, so yes, you can publish it. This is pretty similar to how x.509 (and SSL) with RSA certificates works.

Before publishing the file, actually look at it; the only things that need to be in there are the keyword "ssh-rsa" and the base64-encoded key. You may want to keep it to that (I believe this is the default now).

This is true whether or not the key has a passphrase. A passphrase encrypts the private key and does not affect the public key.

Ensure, as always, that your key is sufficiently entropic and large. If it is generated by a broken PRNG it might be predictable. However, publishing this doesn't present much additional risk, since if the keyspace is that small an attacker could simply try with all the keys in the enumerated keyspace until they get the right one.

I suggest using a 4096-bit key (specify -b 4096), so that it will be more difficult than usual (the default is 2048) for someone to invert your public key into a private one. That is the only significant risk in doing this, and it isn't a very big one since the algorithm is specifically designed to make it impractical.

share|improve this answer

Yes, you can publish your SSH pubkey. And you can publish a fingerprint of the server using the SSHFP record in DNS! This could be really handly, for example, if you need to update / change a server's SSH key.

share|improve this answer

It already is. :) Just put ".keys" on the end of your Github profile URL, like so:

https://github.com/tjmcewan.keys

share|improve this answer
    
Thant's really interesting. What does GitHub expose this for? –  richardneish Mar 26 at 10:16
    
Convenience. :) It's a public key, after all - it's meant to be shared. It's now much easier to grab a new collaborator's key and add it to your servers. Saves the back and forth email. –  tjmcewan Mar 26 at 10:19
    
I didn't realize they did that. –  Zeb Mar 27 at 2:21
1  
+1 for the interesting finding on Github. –  Raymond Tau Mar 27 at 20:36

While as a rule I don't recommend putting your own specific configuration in public project repositories (assuming the repo is for everyone and your configuration is for you alone, it's just a little rude), the security implications are minimal.

The only reasonable attack vector is somehow using that public key to identify you in some malicious context. What that could be is beyond me, but the public key does uniquely identify the private key, though it doesn't give any hints as to its origin.

There's a corner case attack vector which probably doesn't apply, but if you'll recall the fiasco with Debian accidentally breaking the openssl PRNG, any ssh key generated on an affected system is easily predictable and can be identified by its public key. So in that case, publishing the public key could land you in trouble. Or more appropriately, using that key for anything could land you in trouble.

share|improve this answer
    
vector 1. how about fingerprint collision? it's much shorter than public key itself; vector 2 mim attack like "oops server had to be reinstalled it has a different key, but please log in anyway" and fake successful authentication for given user public keys (if that's possible, I'm not sure) –  qarma Mar 26 at 8:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.