The issue

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.

Possible solution

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.


Establishing contact with an authorized entity

A number of ways seem feasible:

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.

Existing solutions

Didn't check carefully yet. git-annex might have a comfortable way.

Incubator status

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.