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?

2 Answers 2


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, 2014 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, 2014 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, 2014 at 20:14

"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


  • 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. Apr 10, 2014 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, 2014 at 21:21

You must log in to answer this question.

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