I'm introducing a new device in my network, and want to give it access to my account on a server.
Given I don't use SSH passwords regularly but only public keys, the procedure
for setting up devices involves generating a private key, transferring that to
my workstation by whichever means is currently practical, and editing the
server's .ssh/authorized_keys file to include the file body.
Compared to having a password, that's cumbersome.
The server could offer another authentication method I'd call "third party". When the method is chosen, the server generates a random token similar to the server key fingerprint.
The client displays the token (mandating VisualHostKey and/or the PGP word list here seems like a good idea, and ), and the server contacts me (ie. someone who is allowed to accept connections by any other means) with a message saying that someone is trying to log in with that token, and whether that should be allowed. Until that is confirmed, the incoming connection is put on hold.
A number of ways seem feasible:
A local graphical interface. Only works for machines with displays, obviously.
XMPP with some form of authentication. I really wish that there were an OpenID server to provide that.
Signed EMail.
A web page.
SSH agent forwarding with additional texts, as can be done for PAM / sudo with libpam-ssh-agent-auth and ssh-agent-filter. (Note to self: Publish How-To).
Note that all of those require having established your identity in some other way. This is no scheme for bootstrapping authentication, only for extending it to other systems.
Any of that could be implemented in a dedicated application for smartphones as well; bonus points for additional means of transporting the token. (QR code scanner, NFC and USB gadget mode come to my mind).
SSH connections time out when challenges are open for too long. Possibly, this can be remedied by having a keep-alive in the authentication mechanism. It should still timeout at some point, otherwise resource usage could be built up.
Clients that use this feature might want to provide options to "Remember me on this server", with on-demand private key generation.
Clients may want to limit their capabilities in advance by sending a
restrictive command. A server / agent might want to have a "always allow" even
for those cases, which would require the client to send an SSH public key along
in the request, which the server would then store with the allowed command in
authorized_keys on behalf of the agent.
Didn't check carefully yet. git-annex might have a comfortable way.
Just an idea scribbled down. Some basic research on existing solutions should
be done. Prototype for console login might get away without client support
("Hash ${HASH}.\nPress return after accpting remotely." as a password prompt,
and only accept the empty password if the actual agent confirmed). Would need
integration with GVFS and KIO
(or whatever they use these days) to become actually practical.
--chrysn 2015-03-08
This page is part of chrysn's public personal idea incubator; go up for its other entries, or read about the idea of having an idea incubator for more information on what this is.