X.509 certificates and OpenSSH

[JCA]

I understand that recent versions of OpenSSH have support for X.509
certificates, in the sense that OpenSSH clients can extract the
relevant information from such certificates and use it in order to
carry out the usual public key-based authentication.

Having a quick look into the SSH RFCs, it would seem that this is the
only way in which OpenSSH supports X.509-based authentication. That
is, it all boils down to the client, not the server. The server just
gets a public key, as usual; it never knows whether it has been
extracted from an X.509 certificate, or from a run-of-the-mill OpenSSH
public key file.

Is this correct?
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Jan Pechanec]

On Mon, 13 Aug 2012, JCA wrote:

>I understand that recent versions of OpenSSH have support for X.509
>certificates, in the sense that OpenSSH clients can extract the
>relevant information from such certificates and use it in order to
>carry out the usual public key-based authentication.

no, OpenSSH supports its own PKI. X.509 support is available via
a publicly available patch though.

>Having a quick look into the SSH RFCs, it would seem that this is the
>only way in which OpenSSH supports X.509-based authentication. That
>is, it all boils down to the client, not the server. The server just
>gets a public key, as usual; it never knows whether it has been
>extracted from an X.509 certificate, or from a run-of-the-mill OpenSSH
>public key file.
>
>Is this correct?

no, it is not. The objective of a certificate is to bind an
identity to a public key to avoid the distribution of such keys. If I
give you a certificate and you can validate it, me having a private key
is a proof that I'm who I claim to be (unless I stole the key). However,
if I give an SSH server just a public key, me having a private key
proves nothing about me unless the server can find the public key in the
authorized_keys file of the user I'm trying to log in as.

that means that with X.509 authentication, you send over a
certificate, not just a public key, and the peer (client for server
authentication, server for user authentication) has to validate it using
a trusted anchor (usually a CA cert), map the cert to a username or a
hostname, and let the other side prove that it has a private key. That
is why X.509 authentication does not need files like known_hosts or
authorized_keys (but could fall back to them if the cert cannot be
validated).

in other words, both sides need to know about X.509, whether for
a server or user authentication protocol (or both).

the details on X.509 support in SSH are in RFC 6187, not sure
how supported that is (it's quite recent). draft-saarenmaa-ssh-x509-00
has been implemented in quite a few SSH apps out there, including the
Roumen Petrov's above mentioned patch.

J.

--
Jan Pechanec
http://blogs.oracle.com/janp

[JCA]

Thanks for your answer, which has indeed dissipated quite a few
doubts. Since I was unaware of RFC 6187 the Saarenmaa draft, I could
not understand how the SSH protocol suite could accommodate for
certificate exchange between client and server.

[Roumen Petrov]

JCA wrote:
> [SNIP]

> Thanks for your answer, which has indeed dissipated quite a few
> doubts. Since I was unaware of RFC 6187 the Saarenmaa draft, I could
> not understand how the SSH protocol suite could accommodate for
> certificate exchange between client and server.

It is in my todo list but I don't have time to implement new formats.

Roumen

--
Get X.509 certificates support in OpenSSH:
http://roumenpetrov.info/openssh/