Home / server / Questions / 587414
In Process
Olly
Asked: 2014-04-09 02:11:49 +0800 CST

Do I Need to Replace Keys for OpenSSH in Response to Heartbleed?

  • 772

I've already updated my servers with the patches.

Do I need to regenerate any private keys with respect to OpenSSH? I know that I have to regenerate any SSL certificates.

EDIT: I didn't word this accurately enough. I know the vulnerability is in openssl, but I was asking how this impacts on openssh, and whether I need to re-generate the openssh host keys.

ssh

4 Answers

  1. The vulnerability does not affect openssh it affects openssl.
    Which is a library used by many services - including openssh.

    At this point in time it seems clear that openssh is not affected by this vulnerability, because OpenSSH uses the SSH protocol, not the vulnerable TLS protocol. It is unlikely that your ssh private key is in memory and readable by a process that is vulnerable - not impossible but unlikely.

    Of course you must still update your openssl version.
    Note that if you updated openssl you also need to restart all services which are using it.
    That includes software like VPN server, webserver, mail server, load balancer, ...

    • 6

  2. So it seems that SSH is unaffected:

    Generally, you're affected if you run some server where you generated an SSL key at some point. Typical end-users are not (directly) affected. SSH is not affected. The distribution of Ubuntu packages isn't affected (it relies on GPG signatures).

    Source: ask ubuntu: How to patch CVE-2014-0160 in OpenSSL?

    • 1

  3. OpenSSH doesn't use the heartbeat extension, so OpenSSH isn't affected. Your Keys should be safe as long as no OpenSSL process which make use of heartbeat had them in their memory, but that is usually very unlikely.

    So if you are/need to be a bit paranoid replace them, if not you can sleep relatively well without doing so.

    • 0

  4. In difference from what others have said here Schneier says yes.

    Basically, an attacker can grab 64K of memory from a server. The attack leaves no trace, and can be done multiple times to grab a different random 64K of memory. This means that anything in memory -- SSL private keys, user keys, anything -- is vulnerable. And you have to assume that it is all compromised. All of it.

    It is not that ssh (any type) was directly affected, but that ssh keys may be stored in memory and the memory can be accessed. This goes for just about anything else stored in memory that is considered secret.

    • 0