Bugzilla – Bug 2739
smart card PKI/X.509 authentication
Last modified: 2019-02-28 09:39:41
You need to
before you can comment on or make changes to this bug.
Currently we do smart card authentication using SSH's normal public key
authentication, but keeping the private key on the smart card. This is not how
smart cards are meant to be used as it completely ignores the certificate.
The "correct" way is to use a PKI scheme. In that scheme, the client sends over
the certificate instead of the user name and authenticates by proving it has
the matching private key (i.e. the same way SSH's public key auth. works). The
server must then figure out which user the certificate maps to, and that the
certificate is valid for this server.
The validity is done by verifying the issuer (CA) signature on the certificate.
The server must have a list of issuer keys it trusts. It usually also checks
with some central database that the certificate hasn't been revoked.
Mapping to a user is implementation defined. Microsoft requires the certificate
to include the user name, and Novell stores the mapping in eDirectory.
OpenSSH doesn't currently have any support for PKI. There is a hackish patch
floating around, but it is very crude and doesn't use public interfaces like
PKCS#11, so it is not suited for our needs. We would most likely have to
implement everything ourselves.
To aid us, Mozilla's NSS library contains all the certificate handling we need.
It can check signatures, revocation lists and all such menial tasks. There is
also a draft RFC for how the PKI handshake should be done over SSH. It is an
expired draft, but it is still better than inventing something new ourselves.
http://roumenpetrov.info/openssh/ might be useful.
Time est. is just a wild guess. This project has too many unknowns to make a
We also need to replace Putty with OpenSSH as it would be really wasteful
making this gigantic effort on both implementations.
This effort has now been resurrected at the IETF and it seems to be very close
to be properly standardised:
It's now a formal RFC!
Somewhat related, red hat is pushing a patch to be able to put authorized_keys
in more dynamic places: