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:

Try the demo out yourself (source code). If you successfully sign in your reward 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

That took just three paragraphs to describe. There is no need for, say, your email provider to vouch for your identity like with Persona. There are no hidden iframes for key provisioning or JavaScript shims. If it weren’t for the spinning globe, the demo could work without JavaScript at all.

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.

Is this actually an improvement?

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 we’ve invented since passwords has been an improvement in terms of both usability and deployability (though some federated schemes come close). Instead we focused in on minor advances to security.

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:

Not easy-to-learn

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 ssh-agent.
• 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 -T flag to suppress a somewhat confusing warning.

Not server-compatible

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.

Usability for real people

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 address 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 authentication with all the same usability nightmares.

A case could be made for use on niche developer-focused sites like Travis or GitHub where users already have SSH keys. But that misses the point. Developers are the ones who already use password managers to generate 40-character-long strings of random symbols for every website. Right now we need tools that are usable by a wide variety of people, not just for the tiny fraction who grew up while using a command line.

Anyway, I hope you enjoyed the demo but it appears that passwords aren’t in danger of being superseded just yet.