40

Does the recent Heartbleed bug affect the ssh keys I've generated and use to push/pull code with Github, Heroku, and other similar sites?

Do I need to replace the keys I've been using?

47

No, Heartbleed doesn't really affect SSH keys, so you probably don't need to replace the SSH keys you've been using.

First, SSL and SSH are two different security protocols for two different uses. Likewise, OpenSSL and OpenSSH are also two completely different software packages, despite the similarities in their names.

Second, the Heartbleed exploit causes the vulnerable OpenSSL TLS/DTLS peer to return a random 64kB of memory, but it's almost certainly limited to memory accessible to that OpenSSL-using process. If that OpenSSL-using process doesn't have access to your SSH private key, then it can't leak it via Heartbleed.

Also, you typically only put your SSH public key on servers you use SSH to connect to, and as the name implies, a public key is a key you can publicize. It doesn't matter who knows it. In fact, you want the public to know your correct public key.

Thanks to @Bob for pointing out that the vulnerability can affect client apps that use vulnerable versions of OpenSSL as their client-side TLS/DTLS library. So if, for example, your web browser or your SSL-based VPN client used a vulnerable version of OpenSSL, and connected to a malicious server, that malicious server could use Heartbleed to see random snippets of that client software's memory. If that client app for some reason had a copy of your SSH private keys in memory, then it could leak via Heartbleed.

Off the top of my head, I'm not thinking of any software besides SSH that could have a copy of your unencrypted SSH private key in memory. Well, that assumes you keep your SSH private keys encrypted on disk. If you don't keep your SSH private keys encrypted on disk, then I suppose you could have used some OpenSSL TLS-using file transfer or backup program to copy or back up your home directory over the network (including your ~/.ssh/id_rsa or other SSH private key), then it could have an unencrypted copy of your SSH private key in memory. Then again, if you were backing up your unencrypted SSH private key to a malicious server, you've probably got bigger worries than Heartbleed. :-)

  • 3
    Note that the public comment really is irrelevant - Heartbleed affects both clients and servers. But you are correct in that SSH is different and not affected by this particular vulnerability. – Bob Apr 9 '14 at 2:09
  • 1
    @Bob Thanks, the Heartbleed writeups have been so server-focused that I hadn't realized the client-side ramifications. I've updated my Answer to better address that. I still think people are very unlikely to have left an SSH private key somewhere that a Heartbleed-vulnerable process might be able to leak it. – Spiff Apr 9 '14 at 3:02
  • 1
    One should mention that SSH does use the OpenSSL library for encryption. As you pointed out, however, ssh is not affected by the heartbleed exploit since it is a different protocol. – psibar Apr 11 '14 at 20:14
1

"Second, the Heartbleed exploit causes the vulnerable OpenSSL TLS/DTLS peer to return a random 64kB of memory, but it's almost certainly limited to memory accessible to that OpenSSL-using process. "

if the machine gets compromised then how can you trust anything on it, including ssh? from heartbleed.com

" What leaks in practice?

We have tested some of our own services from attacker's perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication. "

someone might have put a private key, with no passphrase, on a server they assumed wasnt malicious... but turned out to be. b/c SSL bug allowed a user's password out, a user who had 'sudo'... its probably not an issue.... but...

people do crazy stuff sometimes

http://blog.visionsource.org/2010/08/28/mining-passwords-from-public-github-repositories/

  • I think that quote is referring to a man in the middle attack using the stolen TLS keys. An attacker shouldn't be able to access memory from other programs otherwise that highlights a security problem in the operating system. – Matthew Mitchell Apr 10 '14 at 18:10
  • If a user has been putting his unencrypted private SSH key on servers, then he's beyond our help. Send him a link to piv.pivpiv.dk . – Spiff Apr 10 '14 at 21: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.