Using GPG for user authentication in ssh

[Joel N. Weber II]

I've looked a bit at the question of how one would go about supporting
the use of GPG for user authentication in ssh.

It may be that using GPG for user authentication is of marginal value.
For authenticating hosts, the web of trust really is legitimately
useful; a single person, or a small group of people, can sign a host
key for a host which is used by many people.

On the other hand, for user authentication, you're generally going to
need to have someone manually add something to the authorized_keys
file for each user, and it seems to me that adding the fingerprint of
a public GPG key is about as much work as adding an ssh-rsa or ssh-dss
entry to your authorized_keys file.

I can see two potential advantages to supporting GPG for user
authentication:

1) With an ssh-rsa or ssh-dss key, you have to send mail to the user
you want to add to authorized_keys asking them for a copy of their
key, and wait for them to mail you a ssh-rsa or ssh-dss key signed
using their GPG key.  If you had the ability to just put their GPG
fingerprint in the authorized_keys file, if you know you trust that
GPG key, you save a round trip.

2) Being able to use subkeys might offer you a useful amount of
flexibility.  If putting a primary key in the authorized_keys file
means that any subkey of that primary key can be used for access to a
host, then you could put only the signing subkey on the machines you
actually run ssh clients on, and periodically generate a new signing
key.  When you have a new signing subkey, the ssh client will
automatically send the new subkey to the server as part of the ssh
protocol exchange, and you could also send revocation certificates for
subkeys in that fashion.

One question is how much random unauthenticated ssh clients should be
able to frob the server-side GPG keyring(s).  It seems that if a key
is on the acl, I should be able to authenticate using a new subkey
even if the client doesn't have any unexpired subkey that the server
had before the tcp connection was established.  So the server probably
needs do a --import of any key that's on the acl, whether or not
client causing the --import has successfully authenticated.  However,
I'm far from convinced that a server should allow any client to add
keys to its keyring.

A command line option that told gpg to act as if it had been given the
--dry-run flag if it didn't previously have the key on the keyring
might solve this issue.  So might always doing --dry-run, and then
doing --import again but without --dry-run if the key is not new.

If making it impossible for randoms on the net to fill up the disk on
the ssh server is a goal, then an option to prevent random signatures
from being imported might also be useful; this option ought to cause
revocation certificates and subkeys that are signed by the primary key
to get imported, but not signatures by other keys.

But maybe there are other ways of handling this and or looking at what
should happen, I'm not quite sure.  I think if I do write code to
support GPG user authentication, it likely won't be all that soon.