1

I'm configuring an ssh server for an embedded device. This device already has an x.509 certificate and a pair of public key and private keys stored in it that is used for its HTTPS server. Is it safe to just use same pair for the SSH server too?

Edit

The SSH server that I'd be using is not OpenSSH, it's a proprietary SSH implementation that comes with the embedded OS. It doesn't automatically create server keys and it asks to be provided with a pair.

The reason I'm considering this is because in our device it takes about 4 minutes to generate a pair of keys. The first boot after factory already has increased 4 minutes for generating one pair for http server. It would just be better if we didn't have to increase it another 4 minutes.

Moe
  • 21
  • 3
  • I don't know what this was down-voted. It's a perfectly valid security question. – Xander Mar 01 '19 at 01:58
  • And not exactly an answer but a general rule of thumb: Different keys for different purposes. – Xander Mar 01 '19 at 02:00
  • Sharing a secret key for multiple purposes should always be avoided. You can make the key generation a background task or even better not use RSA at all. – eckes Mar 02 '19 at 01:01
  • avoiding RSA and using what instead? – Moe Mar 02 '19 at 02:19

3 Answers3

3

Just let the SSHD create some random keys for you.

  • If either of the server software or the protocols reveals to be vulnerable in a way that could leak the private key, that would compromise both SSH and HTTPS.

  • You don't benefit from using the same private key and certificate as SSH doesn't provide public key infrastructure like TLS in browsers. The SSH server doesn't send a signed certificate, but the client can compare a hash of the public key with the known keys:

     debug1: Server host key: ecdsa-sha2-nistp256 SHA256:8R95weyGWpfk9q9u3OTP...
 ECDSA key fingerprint is SHA256:8R95weyGWpfk9q9u3OTPRZYAttMFy27GW2anDQxRTYY.

    SSH key hashes could be published on (DNSSEC signed) SSHFP DNS records (RFC 4255). These can be automatically validated using ssh -o VerifyHostKeyDNS=yes.

     debug3: verify_host_key_dns
 debug1: found 8 secure fingerprints in DNS
 debug1: matching host key fingerprint found in DNS

    This would require a DNS name with a valid DNSSEC chain of trust (and a validating DNS resolver), just like getting a valid signature for TLS requires a verification from a trusted CA. As this is an embedded device, it's not likely on the public Internet having a public FQDN.

  • As you won't be using the default configuration, you could mess something up that might become a security problem. While some other implementations (your emdebbed device doesn't probably use) do, OpenSSH doesn't support extracting data from x.509 certificates, but the keys are stored in ASCII armored files.

     HostKey /etc/ssh/ssh_host_rsa_key
 HostKey /etc/ssh/ssh_host_ecdsa_key
 HostKey /etc/ssh/ssh_host_ed25519_key
Community
  • 1
Esa Jokinen
  • 16,100
  • 5
  • 50
  • 55
  • I think the first item should be rephrase to something like: "separating the keys between services that have different permissions creates another layer of defense. An attacker compromising one service doesn't compromise the other." – Jonathan Allon Mar 01 '19 at 13:16
  • As I said in my edit to the question, I don't have to move from default configuration to provide the keys, my implementation doesn't generate server keys by its own. – Moe Mar 01 '19 at 17:54
2

What's important in this situation is that devices must not share RSA keys with each other -- each device should have its own RSA keys. This way, extracting the key material from one device will not compromise the keys used by any other device.

Sharing RSA keys between an SSH server and a web server is unusual, but I don't believe there's any inherent risk to doing so, so long as they are only shared on that individual device.

Modern versions of OpenSSH have dropped support for DSA authentication, so there shouldn't be any DSA key material on your device.

  • So, why the dropped support for DSA keys in key-based authentication or they dropped it for server keys too? – Moe Mar 01 '19 at 17:58
0

This hinges on your definition of "safe", and what the purpose of the keys are. If you're expecting the keys to identify the system as a whole then you might, but this has some drawbacks.

While it's tempting to think of the SSH keys as "system" keys (since you typically use it to administer the system), sshd is merely another application, just like your http server. If you have issues with a keys, you would be obliged to revoke/distrust them, affecting all applications using them applications. Additionally the http server has a different attack surface to sshd, so the threats to the keys are different. Mixing them may needlessly expose your ssh keys to disclosure thanks to a flaw in your http service, or vice-versa.

In general there is little downside to using distinct keys per application, except a bit more overhead in keeping track of which keys to trust. Assuming a) you're probably not using PKI for your ssh authentication and just trusting the rsa public key directly while b) your http server's certificate probably is issued by a trusted pki, this would not an issue in any case.

Liam Dennehy
  • 587
  • 2
  • 8