Signing in to websites with SSH
SSH is near-universally loved among developers. It’s used for sending commands to servers, transferring files and tunneling internet traffic.
Instead of remembering many passwords for different servers, you can generate a single SSH key which gets stored on your computer and authenticates you without typing out a password each time.
Could regular websites offer SSH as a sign-in option? Yes, it is indeed possible, but after making a proof-of-concept I can see why it hasn’t caught on. More about that later, first a demo:
Source code is available if you’d like to try it out yourself (the demo has since been archived). Your reward for successfully signing in is choosing where on Mars your favorite place is. Ridiculous, I know, but then again the demo for Mozilla’s Persona was My Favorite Beer so no judging.
Behind the scenes
Both a web server and an SSH server are running in tandem. Unlike a regular SSH server which only allows sign-ins from users it already knows, this one allows everybody in. It will accept any public key you give it.
The SSH server records your public key for later and prints back a temporary sign-in URL into the terminal, closing the connection once it’s done. No shell access is provided.
Upon opening this link in a browser, the web server uses the random token within the URL to retrieve your public key. An account is automatically created if this is your first time signing in. Finally, a session cookie is sent to your browser and you’re signed in to the website.
Piggybacking off SSH
By piggybacking off the SSH protocol we have avoided rolling our own crypto entirely (though there is still plenty of room for error in mishandling sessions, tokens, authorization etc.)
A slightly different approach
Always striving for maximum convenience and minimum keystrokes, here’s a different version where the random token gets pasted into the terminal. This additional “command” is sent to the SSH server along with the user’s public key.
Meanwhile the web browser keeps a connection open and listens for a signal indicating that the user signed in. No links are sent back through the terminal, the page refreshes itself in the background.
This variation is a bit quicker to use and also doesn’t result in a second tab being opened. Ultimately I abandoned it because encouraging users to paste snippets into their terminals is not very responsible.
The Quest to Replace Passwords by Joseph Bonneau, Cormac Herley, Paul C. van Oorschot and Frank Stajano is an excellent paper. The centrepiece is a huge table comparing the security and usability of various attempts to replace passwords.
Take a look at the sea of red flowing down the table’s left-hand side. Nothing since passwords has been an improvement in terms of both usability and deployability (though some of the federated schemes come close).
Here’s how I scored SSH, assuming the private key is password protected:
That’s about equivalent to combining the poor usability of hardware tokens with the modest security gains of a password manager. I think two factors stand out in particular:
SSH is disastrously unusable for normal people. Those demo videos make it look easy, but there are a bunch of prerequisites that would be hard for first-time users to get right:
- Already being familiar with a terminal and having one handy.
- SSH installed and a key pair previously generated.
- The private key being unlocked and available via
- Ensuring SSH agent forwarding is disabled.
- Port 22 not blocked by a restrictive ISP or employer.
- Verifying the server’s fingerprint successfully (which wasn’t shown).
- Knowing to use the
-Tflag to suppress a somewhat confusing warning.
Running a custom SSH server along side a web server is not convenient. There is no good equivalent to the HTTP
Host header so hosting multiple SSH servers on a single IP address doesn’t work well.
You must also ensure the host key never gets compromised ever because rotating it will cause every existing user to see a Very Scary warning. That’s the downside of relying on a purely “trust on first use” model for key verification. In the future this may be less of an issue as OpenSSH 6.8 introduces the possibility of rotating host keys gracefully.
Some of the usability problems could be addressed by using a custom SSH client specifically designed for web sign-in. It could even register a protocol handler with browsers (like sqrl://) and eliminate the need for a terminal. By going down the custom client route we may as well fix the deployability problems by running the protocol over HTTP. And also link the server’s identity to their TLS certificate so users don’t have to manually perform an extra verification step.
You can see where this is heading—a half-baked reimplementation of TLS client certificates with all the same usability nightmares.
Maybe on developer focused sites SSH sign-in could be an interesting experiment, but I don’t think this path is going to bear much fruit for becoming a widely-used authentication mechanism. I hope you enjoyed the demo but it appears that passwords aren’t in danger of being superseded just yet.