I've set up my VPS'ssh server to accept only key-based identification: I disabled password-based connection.

As a consequence I am connecting from home with an RSA key generated prior to password disabling on my VPS. Of course I've copied the public key into the ~/.ssh/authorized file before that.

Now I want to do the same thing from work, generating a new key pair (I've read it is clearly better to generate a new key pair, one for each source of connection). I guess the best thing to do is to generate the key from my workplace. But then I am facing the issue of transferring the public key from my workplace to the VPS.

Since I disabled the password-based connection, I won't be able to transfer it directly from work.

I could re-enable password authentication just before returning to my workplace. And disable it from my workplace once I am able to connect into my VPS.

But then I would like to know: is it secure to send the public key by email to myself?


The public key is public, meaning that everybody can know it without endangering security. No problem in putting it in an email, then.

The potential issue would be an active attacker modifying the email while in transit, to replace your public key with his public key. To guard yourself against such attacks, compute a fingerprint of the file you are about to send by email (use the ubiquitous md5sum utility on it), and write the hash value on a piece of paper (which you keep in your wallet). When you are back at home, recompute the hash over the received file, and compare it with the value on the paper. If they match, then everything is fine.

| improve this answer | |
  • Nitpicking & not downvoting for it, but since this is security.SE I think SHA would be more appropriate, especially since most *nix'es have them by default now & the cost isn't really relevant for a pubkey file. :) – TC1 Feb 25 '13 at 0:51
  • 1
    @TC1 In this particular case, md5 works as well as any of the SHA algorithms. – user10211 Feb 25 '13 at 1:14
  • 6
    @TC1: I just knew someone would have the reflex of "MD5 IS BAD BAD BAD". I used MD5 because its output is shorter; output length is important when you have to write it by hand on a piece of paper. For the usage described here, we work on second preimage resistance for which MD5 is still perfectly fine. – Thomas Pornin Feb 25 '13 at 12:36

MD5 works perfectly fine for ensuring a file hasn't been altered. Where it (and SHA) is "bad bad bad" is for hashing passwords. The reason? MD5 and SHA are designed to be fast, which makes them easy to brute force with a GPU. For passwords, use a slow hashing algorithm like bcrypt with a random per user salt.

In my use case, I am granting access to someone else on the other side of the country. So after I get his public key, I'll hash it and call him and read the first 5 or 6 letters over the phone. If the content has been altered even slightly, the hash will be totally different so even the first 5 or 6 letters won't match.

| improve this answer | |
  • If I recall correctly, MD5 does have theoretical collision vulnerabilities, although it remains highly infeasible that such a collision could be crafted from a valid private SSH key. – StockB Dec 5 '16 at 21:14
  • Why recommend the md5sum over sha256 (much better) or sha512 (best of these 3), when all 3 utilities are included on modern Linux distributions, so obtaining any of those checksums is super easy to do? – Gabriel Staples Feb 5 at 4:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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