openssh unix dev - Aug 2012 - X.509 certificates and OpenSSH

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?

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