1

To do SSH to any server we should create private key pair through which we encrypt the connection. Now in SSH we are just doing encryption and here we don't need to verify the server, that's why we are not using the certificate.

Now in TLS we also use the private/public key pair. Can we use the same key pair which we used for SSH? Like, can the same public key be placed in the CSR which can be signed by a signing authority?

Can the same private/public key pair be used for SSH and TLS? In SSH we just used keys as only encryption is required, and in TLS we use this for encryption and authentication of the server.

Improve this question
7
  • The keys are not used to authenticate the server in TLS. Ther certificate does
    – schroeder ♦
    Commented Feb 28, 2020 at 17:22
  • 1
    why would you want to reuse the keys?
    – schroeder ♦
    Commented Feb 28, 2020 at 17:22
  • I don't want to reuse the keys, I just want to know the concept, that these are the same keys and there is no difference in encryption technology of SSH and SSL/TLS with encryption point of view they both are same.
    – Shashank Kumar
    Commented Feb 28, 2020 at 17:54
  • Well, that's a different question, then
    – schroeder ♦
    Commented Feb 28, 2020 at 19:47
  • There can be a difference in the encryption used. But from the very generic sense, you are using public/private keys
    – schroeder ♦
    Commented Feb 28, 2020 at 19:51

2 Answers 2

Reset to default
1

In theory yes. Don't do this though. It may break one or both of your encryptions and increases the chances of security breach in other ways.

Also, you definitely do want to authenticate the server when using SSH!

Improve this answer
2
  • Could you elaborate on how reusing a private key could "break" the encryption?
    – yeerk
    Commented Sep 3, 2022 at 23:31
  • There is a lot of nuance when designing a protocol such as TLS/SSH. For example not using the same IV twice, resisting replay attacks etc. If you use the same key for two protocols, some of these considerations may not hold true anymore. The different protocols may use the same IV since they don't know of each other. One may inadvertantly sign something the other would interpret as valid data etc. I am not saying I know of a specific example in SSH/TLS combination, but reusing keys in general is dangerous for these reasons.
    – Peter Harmann
    Commented Sep 7, 2022 at 10:11
1

SSH server is always verified, see "SSH host keys".

SSH is often used with corporate certificates, this way there is no need to verify each server's key's fingerprint on first connection (or to just trust on first use) because the server's host key is signed by corporate CA. The same CA signs your client key and server trusts your key without adding it explicitly to ~/.ssh/authorized_keys.

SSH key exchange is FFDHE, ECDHE over P-256 and X25519 (ECDHE over Curve25519, this is the recommended method).

SSH host key can be DSA-1024 (deprecated), RSA with PKCS#1v1.5 with SHA1 (deprecated), RSA with PKCS#1v1.5 with SHA2 (most supported secure method), RSA PSS with SHA2 (I don't know how much support this has), ECDSA with P-256, Ed25519 (this is the recommended method).

SSH symmetric cipher can be 3DES, AES-CBC, AES-CTR, AES-GCM, CHACHA20-POLY1305.

SSH symmetric MAC can be AEAD (GCM, Poly1305) or HMAC or UMAC.

If you compare this to TLS, especially the modern options, you'll see they are the same. ECDHE over P-256 and Curve25519 is the same and the recommended key exchange in both. AES-GCM and ChaPoly are the recommended AEAD in both.

TLS is mostly stuck with RSA "host keys", with Ed25519 "Host keys" unlikely to become popular any time soon (they have to wait for HSMs with support for those keys to come out, and this won't happen before post quantum standardization, so they are basically waiting for that).

TLSv1.3 upgraded RSA from PKCS#1v1.5 to PSS while SSH mostly didn't, because they upgraded to Ed25519. Both upgraded legacy PKCS#1v1.5 from SHA1 to SHA2, but at different times.

The algorithms are basically the same, but the ecosystems are different, and this leads to the upgrades being deployed at different rates.

We can add IKEv2 for IPSec to the comparison, and we will see that in the space too, the exact same conclusion holds.

Improve this answer
4
  • Do any services actually store TLS 'host keys' in HSMs? I had the impression that although HSMs are often used for CA certificate keys, they aren't nearly fast enough to be used for storing end server certificate keys... and even if the CA must use a HSM it's still possible to have an Ed25519 certificate signed by a RSA-based CA.
    – grawity
    Commented Jul 28, 2020 at 16:03
  • Some sites store leaf certs in HSMs. HSM is not a ubikey, it can be a hardened PC, it can have good perf. Which trusted CA will sign an ed25519 leaf cert for your site today?
    – Z.T.
    Commented Jul 28, 2020 at 16:33
  • None because CAB won't permit them to do so. Many are already signing P-256 certificates however, which isn't that far off.
    – grawity
    Commented Jul 28, 2020 at 18:18
  • Cloudflare has had free ecdsa certs for years. I trust cloudflare and Google with ecdsa, but I think it's not a good option. EdDSA is much better.
    – Z.T.
    Commented Jul 28, 2020 at 18:21

You must log in to answer this question.

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