I’m developing an application that runs over TLS. In addition to password-based authentication we’d like to be able to use SSH keys.

Is there any prior art in using SSH keys for authentication over TLS? Does anyone know of any potential problems with implementing such a scheme?

Thank you!

UPDATE: After a bit more research, I’ve got a fleshed-out concept:

RFC 5705 key material exports appear to serve the same role as SSH session identifiers. Thus, the following:

  1. C: Grab NN random bytes from TLS’s key export.
  2. C: Sign those bytes using the private key.
  3. C: Send the signature and the key in, say, an HTTP handshake.
  4. S: Verify the signature via the public key, and verify that the key is authorized.

Would this work, be resistant to replay attacks, etc.?

  • 3
    $\begingroup$ Why design it this way in the first place? There is an established mechanism for key based authentication of the client in TLS already in the form of client certificates. $\endgroup$ Jun 30, 2020 at 5:52
  • $\begingroup$ At least a couple reasons: 1) We don’t know how the client will authenticate at TLS time. 2) Maintenance of a CA seems a good deal more complex than the usual workflow for SSH public key authn. $\endgroup$ Jun 30, 2020 at 18:54

1 Answer 1



Although they could use the same set of cryptographic algorithms, SSL/TLS use ASN.1-encoded certificates, and recently raw keys (but still using ASN.1 OID algorithm identifiers), but SSH on the other side use its own application-specific format. So the biggest potential problem with your idea would be interoperability.

  • $\begingroup$ In this case we’ll control both endpoints, so interop isn’t a big concern. $\endgroup$ Jun 30, 2020 at 18:55
  • 2
    $\begingroup$ If you in fact "control both endpoints" this invalidates your earlier answer to Steffen Ullrich since you can in fact "know how the client will authenticate" because you control it. $\endgroup$
    – tialaramex
    Aug 3, 2020 at 5:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.