9

So I'm getting conflicting information from members of my team. The premise is, if an attacker can keep requesting 64 kb chunks of memory from my server, they could get the entire memory footprint of my server, and thus get the private key I used out of memory.

So, is the private SSH key I used to log in stored in memory? Do I have to worry about my SSH keys?

Improve this question
6

4 Answers 4

Reset to default
12

No. OpenSSH uses a very limited subset of the OpenSSL library, and that subset does not include the code involved in the Heartbleed vulnerability (or any of the other SSL/TLS code, for that matter).

Additionally, the Heartbleed vulnerability doesn't permit an application to read memory outside of its address space, so, for example, a vulnerable web server can't reach out and grab keys from a SSH server.

Improve this answer
5

It cannot be repeated enough :-)

No But! If you run any other services on the host machine, OpenVPN for instance, wich uses OpenSSL, its vulnerable and can be exploited.

Improve this answer
2
  • Interesting note--our OpenVPN uses it's own static library for SSL so we were actually safe in that regard.
    – TerminalDilettante
    Commented Apr 10, 2014 at 13:14
  • 1
    Follow up: OpenVPN basically "lied" about which version of SSL it was using (someone changed the filename to make it seem like it was using an older version) and the vulnerability was discovered using a tool. We were not happy campers that night.
    – TerminalDilettante
    Commented Apr 30, 2014 at 19:49
3

When you log in with SSH, your client has the private key, and the server has the public key. Therefore, no vulnerability on the server can leak your private key, since the server doesn't have it.

The server cannot use Heartbleed to get the private key from your client, since that's an SSH implementation, and only OpenSSL SSL/TLS connections on version 1.0.1 to 1.0.1f are vulnerable. No other implementations of any type at all have this issue, including all SSH implementations.

Now, if the server has its own private SSH keys in memory somewhere, then deeper investigation would be called for.... but it would be cheaper to fix the vulnerability and then regenerate the server's SSH key pair, since there's no Certificate Authority to pay to sign SSH keys!

Improve this answer
3
  • So to be clear, the server never gets the private key? So what is the mechanism of authentication, then?
    – TerminalDilettante
    Commented Apr 10, 2014 at 13:14
  • 2
    @TerminalDilettante When your authenticating with SSH keys your private key isn’t sent, the server sends you some random data and challenges your client to encrypt it with your private key. It then verifies the encrypted data by decrypting it with the public key and checking if it matches the data originally sent.
    – phixr
    Commented Apr 10, 2014 at 21:02
  • Thank you! I was having trouble understanding that handshake process.
    – TerminalDilettante
    Commented Apr 12, 2014 at 4:44
1

Generally no, but it depends on how paranoid you are, and on the specifics of the vulnerable system.

Like others have said, openssh keys cannot be directly leaked by a heart-bleeding openssl server. But if information is leaked (like say an https user login) then perhaps an attacker could use that password to gain access to the system. From there, your user ssh private key is safe if it's not on the local file system. But if the attacker uses that information to gain root access a lot more trouble happens (of course). For example, they could now decrypt your ssh traffic and if you had an ssh agent enabled on the system, the attacker could now ssh to other systems as you, but not recover the original private key if it's not on that system.

Improve this answer

You must log in to answer this question.

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