SSH v3 specs?
Danny De Cock
godot at ulyssis.org
Mon Jan 6 16:07:12 EST 2003
I would be very interested in an ssh protocol which supports certificate
validation. what I mean is this: if one uses a smartcard to perform the
digital signature generation, the ssh client currently requires the
presence of a certificate in that card, but the certificate itself is not
used where it is designed for: the ssh server fetches the reference value
of the smartcard's private key's public key from its authorized_keys file,
but that's it.
I would be very happy if the user's certificate could be stored in the
authorized_keys file (or a similar file), and if the ssh server checked
the digital signature on the challenge during the client's authentication
using that certificate, and granting access to the user only if the
certificate itself has been found to be valid...
the ssh server could offer different validation mechanisms of the
certificate: using a local set of trusted (possibly self-signed)
certificates, fetching a certificate revocation list if necessary,
presenting the certificate to an external certificate validation service
(e.g., ocsp responder), etc.
the easiest way for the ssh server to obtain the client's certificate
could consist of the authorized_keys file, or the ssh client could push it
to the server after having it fetched from a local repository (such as the
does this sound reasonable to you, or pure nonsense? :))
On Sun, 5 Jan 2003 sshdev at rednu.com wrote:
> Has any thought toward a v3 protocol spec been discussed elsewhere,
> and if so what enhancements are being looked at. Is it too early to
> consider such things, or should we open the door to the new features a
> protocol update would bring?
> More specifically I have been investigating working toward a more
> enterprise-friendly hierichical authentication scheme, but I have
> quickly realized the magnitude of such a change. I have worked with
> LDAP/PAM, but there are parts of ssh that are not very interoperable
> with LDAP, such as pub/priv keypairs. These can be stored in a
> directory, but it is quite a kludge to do so at this point.
> Thoughts and comments appreciated.
More information about the openssh-unix-dev