This is something I've had the occasion to discuss before, and it's a good idea not because "it's ssh" or "it's decentralized" (those are just good benefits), but because it moves the authentication to an actual authentication protocol and, were it to catch on, would have to be done from the browser itself.
Does this ring a bell? That's right, it's BrowserID ladies & gents. I'll never let this go, Persona was a great thing for the web and its death is mourned.
I think I've seen ssh auth implemented before but this is the smoothest POC yet. Your next step: Make a firefox extension that integrates this, as a proof of concept for in-browser authentication.
I'd disagree. My personal opinion is, BrowserID/Persona was a bad thing for the web and it's a good thing it haven't hit any big. Sure, it was better than most popular protocols out there, but it was still wrong.
My opinion is that BrowserID had a very flawed core concept. I firmly believe that my identity is something that I [can] naturally define and possess. But everyone since OpenID had stolen this from the end-user and identities became something that you're provided with - and I find the very term "identity provider" unnerving.
With identity providers you're not you anymore, but merely your Facebook account or your email address or your domain name - a things you only temporarily lease from a third-party like an email provider or a domain registry. Sure, there's some common sense, legal protections and stuff, but I'm don't like merely relying on those. I think, in a sane world, at least personal (i.e. non-group) identities must be merely asserted, not provided - and they must originate from a person themself.
On the contrary, this login-with-ssh thingy and few other schemes (gpgAuth and WebID) are much closer to what the things should be like. While they don't yet completely resolve the distinction between an identity and a credential (it's really hard), they root your identity in something that you can actually define for yourself and handle without depending on anyone else - a key pair.
Normal people will lose key material. Systems administrators sometimes lose key material! In a sane world, it needs to be possible for someone with common sense to revoke and reissue your credential if you lose it. If this is categorically posisble, then your identity is leased, not owned.
Your SSH private key is not your identity, it's just some bytes. Your identity is determined by what public key is considered to be "you", i.e. what's in ~/.ssh/authorized_keys. Your infrastructure provider can usually change this, with or without your permission.
Unless you own the land where the hard disk public key -> account mapping resides, your identity is leased.
Absolutely. It's my credential. In a perfect system, we decouple those from identities - but that's hard. If you have some ideas about this or know a system that handles this - please share a link.
In a less than perfect system, we at least have to try to assure that credentials are self-sufficient and don't require a third party to just exist. That leaves us with either keypairs or pre-shared secrets (traditional passwords). Maybe something else but I don't know.
> In a sane world, it needs to be possible for someone with common sense to revoke and reissue your credential if you lose it
Well, yes. However, there is just no advancement at the moment - proposed general approach is just not better or worse in this regard. It's the same as if you've lost your password and email in a most traditional identity system out there. If you lose all credentials - your identity's lost and you can only talk to each consumer individually and negotiate whenever a recovery's (to a new identity) possible. This doesn't change.
However, in theory, you can set up a system in which your friends or someone you trust may help you to recover or revoke your key. I'm no crypto expert, but I heard we have fancy things like threshold signatures and secret sharing schemes (where k-out-of-n members quorum is necessary to recover a secret or generate a valid signature), so I believe there are some options for the future how we can improve things - in a ways more flexible and secure than things are now.
Here's an idea: you can designate "emergency contacts", other keypairs that can be used to recover your identity, perhaps those of your family members. They could declare the intention to recover your credentials, and then you would have 2 weeks to publish a signal that you still possess your keypair, to block the recovery. You could also revoke their designation at that point, if they are abusing it.
If two weeks pass without incident, then they can publish a new public key half which is considered yours, and presumably give the private half to you.
This. And maybe even use Shamir's secret sharing (or a similar scheme) to split the backup/recovery key among the family members or trusted close friends - so a single person won't be able to compromise your security.
Most of the world also abuses OAuth — which is for authorizing access to information on your behalf, and is completely orthogonal to identity and authentication — for login.
If we step back a bit and look at the problem, the main thing that sites should care about is proof. That is, I'm essentially a number (an opaque, abstract identity), and all the site should want is for me to be able to prove that I am that number. We should forget about email addresses, user names and passwords. A site should be able to request real-world identity information such as your name and address, but there's no need to comingle that with login. A site that isn't an e-commerce app generally has no business getting at that data in the first place.
Such a system would be a boon to implementors, too. As a developer, I would greatly appreciate not having to implement another damn account/login system just so that I can remember my visitors.
But nothing is going to happen until browsers implement such identity management natively, and the only way to get there is for the browser developers to collaborate on the tech.
Not true. I own my domain, and I own it in a very specific juridical sense.
It's not tangible, because domains aren't, but it's a lot more like owning a car than leasing a car. The ownership is stronger than for my phone number or my birth name, for example.
While the term identity provider might not sound well, it is necessary for a system where you have multiple identities. And I think it's pretty well established that that is a requirement for the modern web.
Maybe you do (as long as you pay, of course). Legal protection gives you recourse, but doesn't protect you from malicious adversaries. Shall something bad happen - you'll lose your identity and will have to seek it back in a court. It's a sort of insurance.
Also, that juridical sense isn't international. There are countries that seize or undelegate domains they can reach at whim. There are countries that block other zone domains, mandating Internet traffic filtering within a country. Legal sense doesn't mean a thing against rogue governments.
To put it security: I really don't want to trust any other entity but myself to be a source my identities, and find any concept of trusted authorities to be hazardous. Seriously, how come we designed the whole damned network that when I come to someone's place why I happen to need some landlord to confirm (why?) that I am who I am? Isn't this is only a matter between myself and whoever welcomes me on their site?
> Shall something bad happen - you'll lose your identity and will have to seek it back in a court.
That's true for every way to prove identity. For most use cases, it's a feature that you can get it back in court. See also "identity theft".
> that juridical sense isn't international. There are countries that seize or undelegate domains they can reach at whim.
In a way it's very international. It has never happened in the history of the Internet that one top domain organization has undelegated domains under another top domain.
It is true however that you are always subject to your country's laws. But this system is international in a way that none of your other identities are: You can easily get a domain in another country, and that ownership is exclusively managed by that country's laws.
> I really don't want to trust any other entity but myself to be a source my identities,
That doesn't make for very useful names.
I may assert that I am Barrack Obama. You will most certainly not agree. That limits the usefulness of self-asserted identitites. See also "Zooko's Triangle".
> It has never happened in the history of the Internet that one top domain organization has undelegated domains under another top domain
I also haven't heard of such thing. I have heard of few others, though.
US had seized a few .com domains, and I doubt they cared about citizenship of registrar.
Russian government had requested un-delegation of few .ru ones, and blocking any access (ISP-level) to many others across the world.
Australian .oz ccTLD was moved to .oz.au.
Yugoslavian .yu ccTLD is gone and doesn't exist anymore. It was once feared that .su would also begone, but it had survived for some weird reason, although - who knows - for how long?
I think a few email accounts I had registered in early '00s are long gone, some with the very email providers. But I still have my old private key I've created a decade ago. That's what I know about the credentials. YMMV, of course, and - sure - I know a few peers who had lost their keys.
> I may assert that I am Barrack Obama
Sure, and while I suppose it's not your name, I bet there is not a single Mr. Obama in this world. Zooko's triange is fine, identity system doesn't need unique names - a natural one doesn't have those anyway. We don't require worldwide login (username) uniqueness, right?
If for some reason we want to know it's real US President Obama who wrote a message or signed up on a site, we need an assertion on his identity from US Govt, don't see any issues with this. And, duh, I bet he has a few tamper-resistant tokens that hold some signed keys, to sign his mail and whatever. I would be very surprised if he doesn't.
Why is an IdP necessary for a system where you have multiple identities? Why can oneself provide the identity one wishes to use for the communication with the other party?
I do agree that Persona with a personal domain is a much better system, but why should it be necessary to have one to avoid being tied to a third-party IdP?
You don't trust your email provider? Today your email provider is already implicitly your underlying IdP for almost every website you visit that uses that email (if it has a "Forgot Password" button that sends you an email, your email provider is your IdP). All Persona attempts to do is make that implicit assumption an explicit part of that email's identity, and even tries to make it somewhat more secure than sending random tokens via often insecure/semi-secure SMTP channels, as most "Forgot Password" systems do.
Ultimately yes, if you want to sign in to a website with your email address you typically have to trust your email provider. This is true on the web almost universally with or without Persona.
Why is any IdP required by Persona? Identity protection and reuse across browsers are two big reasons. If I want to say that I am/use the email "wm@example.com", Persona tries to verify that I actually have access to that email (can sign in to my email provider, or can do the classic click a random token link in an email cycle if my email provider isn't supported).
It's a luxury those days, with email providers snooping over messages to show your advertisements and all sort of TLAs snooping just because they feel so. There is some buzz about end-to-end encryption out there for a reason, and the reason is a lot of people don't trust their email providers.
But I reasonably do. I'm hosting my email myself, on the hardware I own, located on my own premises. Although I may get hacked - one can't be ever sure they won't - most modern systems are too complex for any single human to grasp and sometimes bad things just happen.
But I don't trust my domain registrar and the network. DNS may get poisoned/spoofed, network may be tapped and traffic redirected, registry or nameservers may get hacked or subpoenae'd (ok, I'm not a criminal, but who has a protection from powerful authorities if they suddenly decide they want you?) and whatever else.
By the way, neither identity protection nor reuse across browsers does not strictly require IdP. In a strict sense, you don't need a trusted third party to transfer data between your devices or have a means to recover a lost key. If you have everything you need to prove your identity claims, you can decide how you handle those on your own, and whenever you want some TTP assistance or not.
And if you decide you do, the requirements are a lot more relaxed. With Persona you trust a very specific third party - some email provider. You trust it to behave and you trust it to serve and stay so for as long as you need your identity.
However, if - for example - you have an identity asserted by a keypair - you have way more possibilities, ranging from a key backup in a tamper-resistant HSM in a safe vault behind a blast-resistant doors in your basement, or setting up a secret sharing scheme where 3 out of 6 your close friends must get together to help you recover a lost key, to just uploading your key to Dropbox and not giving a damn. Isn't that a good thing?
And if the key's completely lost - it's the same as if the email provider's gone - you'll have to either give up or recover your accounts using some other ways (talking to a support and figuring out what would be a good replacement proof).
«By the way, neither identity protection nor reuse across browsers does not strictly require IdP.»
Technically correct, but it makes it a lot easier at a practical level, especially for non-technical users. Users have trouble remembering passwords, key management is seemingly beyond most users. So too are systems like the "web of trust" model of key identification much to complicated (and onerous and time consuming) for the average user.
IdP is the best bet we have of at least somewhat decentralizing trust decisions in a way that is user friendly.
«With Persona you trust a very specific third party - some email provider. You trust it to behave and you trust it to serve and stay so for as long as you need your identity.»
This is not a requirement of Persona. You can use any email you like with Persona and it's not a platform requirement that user accounts in a system be one-to-one with email addresses. It's certainly possible a site using Persona can very easily tie multiple identifying emails to your account. It may not be likely that a lot of sites would do it, as one email, one person is a rather generally accepted identity world at the moment, but it's also not far fetched that the replacement for the "Forgot Password" button in a hypothetical universe where Persona is the only option is a "Associate another email address to your account" button.
«However, if - for example - you have an identity asserted by a keypair»
But what good is this assertion? How do I as an application provider trust your assertion? At bare face value an "identity asserted by a keypair" is a fingerprint, a boring hexadecimal hash. I don't know very many people that associate themselves as "fe:02:aa:45:c3:d0". You could self-assert an email address or a name/pseudonym, fine, but as an application provider I can't make any assumptions about the contents of that email address or name/pseudonym and the only trust I have in it is "your word". You could use web of trust assertions, but again we get into the bootstrapping issue of "web of trust is hard" and "users don't want to have to do it".
The same goes for all of your hypothetical key management: yes, you can manage a key on your own cognizance in any number of ways. Ultimately, most people just don't want to.
On the flipside, Persona too has more options in this space for IdP management and key management than maybe you've given it thought: There's a Mailinator-based IdP that will sign any key request from Persona for pseudonymous identities (while even maintaining the application provider assertion that the email is valid and accessible to that user). There's the ability to do IdP delegation from a domain, using a file on my website to choose which IdP I trust right now, which can easily change over time. (Static HTTP sites on custom domains are cheap as free, including Github Pages as one option.) There are more ideas out there and you can reasonably approximate whatever half-finished idea you have for your own key management system with Persona given a little bit of time and elbow grease.
> Technically correct, but it makes it a lot easier at a practical level, especially for non-technical users.
So, let them put their unencrypted keys on, err, Firefox Sync or Dropbox or whatever, and not give a damn. It would be almost exactly the same security level - identity conveniently secured by an external service.
I just don't see a downside. Yes, the keypairs don't have a human-readable name - but they don't have to, they're just like passwords, except for they can be globally recognized (if user wants to). Yes, for non-paranoid users' convenience we need some sort of key escrow system with some trusted party that can take hold of a file - but that's well possible and I think every other user has some "cloud storage" those days.
> This is not a requirement of Persona.
Yes, you're right. I simplified it a bit. A requirement of Persona is that IdP is a very specific service identified by a domain name, not an email. But the rest of logic should still hold.
> How do I as an application provider trust your assertion?
Generally, you don't need to check assertions, unless you want to confirm that this specific user has some affiliation with this specific third party. Then you check a signature from that party.
If you don't need an information that your user is also a specific person on, say, Facebook, or, say, a representative of some company (verified by a notary) - you don't need to care about any assertions. You just take a key and that's it.
Seriously, an average service does not need any identity assertions. Do you need a passport to enter a restaurant or a store? It's the same thing here. (Ok, maybe you do if that's a gun or liquor store, or some private lounge that needs a membership.) Oh, and, sure thing, almost every store out there would just love to ask for a passport and have a very detailed and extensive tracking of their visitors.
> At bare face value an "identity asserted by a keypair" is a fingerprint, a boring hexadecimal hash. I don't know very many people that associate themselves as "fe:02:aa:45:c3:d0".
Neither do I, but I don't see why you thought about using fingerprints as identifiers for humans. Those are credentials, not identities, although they're tied because it's hard to separate the concepts. Users already have a lot of weird stuff but and don't care that they're username/pbkdf2_sha256$12000$6Q0D5rq4nz1m$xsAqY1hlIuFqY4sD+9Ia0dxNLooy+jmHFJCrBgByhHw=. Let us leave those details to computers. Hope you see the idea.
I agree with most of your logic but let's also be pragmatic - something that is better than everything else out there that's actually popular, and has a chance to hit big, is good for the web. Always pursuing the impossible perfection is one of the reasons we don't have ubiquitous https for example...
Well, yes, you're right. Seeking a perfection usually means never releasing anything. That's spot on.
Yet, I'm particularly against about the BrowserID adoption because it helps to cement the idea of leased identities. At the moment, we're still with in the "warring states" world, where no particular scheme had won. This could've changed with BrowserID embedded in the User-Agent, so I fear it would be at least a decade until we'll be able to talk about something else.
WebID, being a W3C WG, could've also hit big... It's not perfect, but from my understanding of the drafts it looked better than BrowserID to me. But no luck here.
It's an interesting moral line in the sand you are making.
Persona/BrowserID simply reuses the concept of email address as identity (and email host as identity provider). This is honestly already pretty heavily cemented in the web (I think the war has long since been lost): almost every website uses in some way emails as natural keys for identities and with the critical overuse of email as the medium for "Forgot Password" login schemes, email hosts are already everyone's de facto identity providers.
At least there is more personal choice involved in email hosts, and indeed sometimes direct ownership in paid email accounts, unlike the walled garden monopolies we see in Twitter/Facebook/Google "social" logins.
Yes, emails are currently required on almost every site. I draw this line because BrowserID/Persona (and similar efforts) are quite special - we jump from the pages to browser's chrome, making user-agent actually handle authentication.
I think that the first major standard to come - that'd be embedded in the browser - could change this game rules, because it must be (well - I don't know, I just think it is) a big thing. Even users who don't care would've bought secure yet seamless authentication, neat identity management and so on. But not something after this, because the momentum would be lost and there won't be enough incentive to switch.
So, the first standard must have something sensible as credential, or - I fear - it will be a long time before we can hope for any changes. Maybe I'm wrong here.
The thing that makes this particularly pertinent for me is that I try and avoid Facebook & Google+ and indeed most other identity providers for the sole reason that if one of them gives over (either legitimately by subpoena or by being hacked) access to my account, there is a handy pointer to every other service I have accounts for... I'd rather not leave a centralized paper trail of everything I do in one place.
I agree in principle, but in practice I don't care much if many of my accounts get hacked or subpoenaed. Sure, I'd like to keep my communication and financial information as private as possible. My code, maybe and my personal photos and documents, but if a hacker or government organization gets access to my chess.com account or my GrubHub, I really don't care. They'll find out that I have trouble against the Sicilian Najdorf and that I eat too much cheese cake (which as of this post is open record anyway :)
No! That is pointedly not what I'm saying. What I'm saying is that I don't need every detail of my life to be private. I prefer that nobody go in and start playing games on my chess.com account, but I'm willing to take a higher degree of risk with that specific account than I am with, e.g. my financial accounts.
It is possible to care about privacy and still accept a more convenient (less secure) way to access specific things.
Agree. However I think time is working against anyone that wants to do this though.
> I'll never let this go //Using this as an excuse
> Your next step: Make a firefox extension that integrates this
Do it while it is still possible, before Mozilla carries out their plan to lobotomize Firefox and bring it down to the level of Chrome like they have planned. :)
I'm amazed at how Chrome keeps taking market share from Mozilla. Those ads in google.com help an awful lot but still, it's kind of unnerving. I understand why your average user wouldn't mind using it but Chrome has taken a lot of power users from Firefox. Some people even seem to deem "uncool" to use Firefox instead of chrome, it's ridiculous. It's gotten to the point where some sites features don't work correctly (or at all) in Firefox but they do so in Chrome, as if we were back in the era of browser-specific sites.
As someone who has been switching back and forth: The ability to customize Firefox is nice, but:
Chrome has most features I need and makes up for missing ones with nicer implementations of others, or has them before Firefox does. Firefox freezes regularly for seconds, feels slower in many situations and degrades quicker if you open to many tabs (Chrome just eats ton of RAM, but can deal with many hundreds of open tabs otherwise). Oh, and faulty sites crash the entire Firefox instance instead of just a tab.
Firefox is about to get multiprocess feature in full releases, I hope this will fix many of these issues.
I switched to Chrome because its speed was a breath of fresh air compared to Firefox, and after trying it, I couldn't stand how slow Firefox was (or how one misbehaving tab could cause the whole thing to freeze).
What am I missing out on in terms of plugins/extensions that Firefox can do that Chrome can't? It's been a couple years, but I don't feel like I'm missing anything in Chrome..
I would've loved if I could just use a self-generated certificate to authenticate. Especially if they'd be on HSM like YubiKey/NitroKey. Heck, there's even <keygen> element in HTML5, so this could've been quite user-friendly hassle-free. I could consider paying someone to assert my identity, or get some assertions for free, or whatever - the possibilities could be limitless. However, there are few issues with this.
1. We're currently stuck with X.509 and those don't allow subkeys or multiple signatures.
2. Then, the problem is that, AFAIK, there's no way to tell in that we accept just anything in TLS. I think there were a lot of discussions about allowing spontaneous authentication (changing state machine to allow TLS client to send certificate without CertificateRequest) or adding hacks like DN=WebID, but none is here. My memory's blurry in this regard - I've read about this about an year or two ago, sorry. But I'm certain there were some issues here.
3. Then, the problem is, browser UI and UX for managing certificates are terrible. There weren't any changes in this area for decades, and everything about those is deep hidden. Then, there are no subkeys and no cross-browser sync or key escrow mechanisms (opt-in, absolutely), so it's very unlikely to be useable by average person. And so on.
So, format is not ready, protocol is not ready and browsers are not ready. Thus, sad but no, it's not going to work.
Public key authentication of clients (as opposed to servers), has been part of SSL since v1.0. This is just adding a misdirection, the underlying protocol is the same X.509 we've had since the late 1980s.
The main problems are:
1. Certificate authenticity -- the key has to be added to authorized_keys on the server. This includes certificate revocation and expiration, and re-establishing trust after certificate is lost.
2. Private key management -- how do I migrate keys to a new browser or a new machine? Where are the keys stored anyways? Absolute PITA in every existing implementation.
3. Key generation -- we need some more user-friendly tools if this is to catch up
The U.S. Military does a passable job of this with the Common Access Card (CAC). You insert it into a smart card reader and then visit the restricted-access website. Your browser/OS prompts you for a PIN which, I believe, is used to decrypt your private key. Your browser validates the remote site against a set of DoD-provided root certificates that you configure on your computer before hand. Then, some kind of key exchange happens--this has always been a bit fuzzy to me--and the keys on your CAC card are used to authenticate you to the remote site.
It's not perfect, of course. You can lose your CAC card and then you're screwed unless you have a way to get new one. It requires a smart card reader which is not standard on most computers. The cards themselves can get damaged by corrosive liquids or sweat (learned this the hard way). Still, it's not a bad way of authenticating and I feel much better about it than a SSH private key that hasn't been encrypted with a passphrase.
For example in Estonia, every citizen has an ID card, and every ID card is an ISO-7816 smartcard. So they can have this nationwide. Then again, that's a country of 1.3M, and you only get the card when you're 15yo. Foreign visitors obviously don't have one.
These examples illustrate rather the near impossibility to implement this kind of a scheme successfully, even when backed by a state.
We're working on solving a few of these SSH issues at Userify[1] (SSH key management) but I think you're right. Something like this could be even harder to spur adoption than SSL client certs, which browsers already support. (Here's an article[2] from 1998... almost two decades ago!)
The is a great idea, but the usability is probably not good enough to make it work.
What I like: I am authenticated by some proof of ownership, and, unlike with password authentication, the "thing I own" is never transferred over a wire or stored at the server. This is even better than what I have now (unique passwords for every site, managed with 1Password, and 2FA for important sites).
But the SSH callback would have to be automatic - Via a browser plugin, or even better, implemented by the browser itself. I don't think I want to start a terminal and past a string every time I log in to a site.
The "paste this into your terminal" also opens up a completely different can of worms - Social engineering!
So...basically you want SSL client certificates but with a slightly less sucky UI?
I mean, https already supports this, it's just that setting up servers to deal with client certs sucks and the UI for users is also pretty bad. But the infrastructure is already there without poorly reinventing the wheel over SSH.
Right, that's exactly what I want. Or something like BrowserID / Persona was supposed to be. It has to be slick and frictionless, otherwise it won't stand a chance.
You know, there is a reason nobody uses client certificates...
Aye in the end I don't think the protocol itself matters as much as the concept of doing (asymmetric) auth in the browser rather than layered over http. Yelling "but it already exists! client certs!" is kinda unproductive, like you said there's a reason nobody uses them.
I appreciate I'm a bit late to the party here, but..
Does anyone have any type of explanation of why the UI in browsers for client certs are so user-unfriendly?
I would really like to use client certs more, but with things the way they are that's impossible right now. It's just too hard for a normal person to use them.
A few of the CAs have in the past offered certificates tied to personal email addresses for cheap as free for years in the hopes that S/MIME catch on. Those are typically fine for HTTPS client certificates too, but the bootstrapping problem is essentially the same for both. To date no one has really managed to get certificates easy enough to use for the average lay person nor adoption common enough for a lay person to need to overcome the learning curve.
Neat idea, but I think there's a confused deputy(?) attack possible here.
Specifically, I think there's a missing binding between the SSH session used for authentication and a user's web session.
Let's say that Alice has an account on bob.com. Mallory sets up mallory.net and sets up demo-ssh.mallory.net as a DNS alias (or TCP proxy) pointing to demo-ssh.bob.com.
1. Alice visits mallory.net, which Mallory controls
2. Mallory visits bob.com and starts an authentication session.
5. Alice runs the command to authenticate to "demo-ssh.mallory.net". But this actually authenticates Mallory as Alice to bob.com!
6. Upon detecting a successful login, mallory.net accepts Alice's login to avoid raising suspicion.
The only sure sign that this has happened would be that demo-ssh.bob.com and demo-ssh.mallory.net would have the same host keys, but OpenSSH isn't designed to prohibit duplicate host keys.
However, this still relies on the user manually checking the origin of the challenge every single time, and users aren't very reliable. It might be better suited to a browser extension than to a manual copy-and-paste process.
I would argue that using a client certificate would be a much more practical way for web authentication. This would eliminate the need to start a SSH session when trying to login.
My university uses client certs for some services. It's a pain with tons of odd error cases. With a technical user base, this might actually have better worst-case experiences (but worse average-case, when client-side certs work and you always use one machine they are smooth).
It would be awesome if YubiKeys or other SmartCard-like devices were more widespread and better supported in browsers, because it would make client-cert workflows way easier. It's really mostly an UX issue.
I can agree with this, but I think the hardware tokens compared to regular client certificates have the same issue: better average case (if it works it much easier to use it on multiple machines) but worse worst-case (a missing driver will completely shut you out).
It should be possible to build tokens that work without special drivers, requiring "just" application support. (Many 2FA tokens emulate HIDs/keyboards)
Sure, but once the thing knows my ssh key, I don't have to bother with GitHub anymore. My ssh key is on all my computers, but I'm not always logged into GitHub.
I have lots of different ssh keys, and don't share them among different client devices. I do share them across different services, but it turns into N*M anyway because I haven't figured out a good way to upload a generated public key from a client device once and have that flow across to all the ssh-compatible services I use. It seems like there should be something for this, but what tool could e.g. speak to both EC2 and GitHub?
You could do this in theory with gpg by signing keys with a master key after generating them but there's no way to do it automatically with ssh (that I'm aware of)
to clarify- you're envisioning a tool that takes in a new public key you've generated, and adds it to your list of authorized keys on various servers/SaaS/etc?
I know, right? Not that it would be easy. ssh-copy-id is kind of an idea of how it could work, but that suffers from bootstrapping issues and doesn't seem to be supported except in very specific PaaS situations. A useful tool would have to dig into the idiosyncrasies of each service's auth policies, at least until it became popular enough that services would try to meet it halfway.
No, you could just grab anybody's public key to verify their login (when they use their private key).
SSH keys are asymmetric. Think of public keys as locks and private keys as ... well, keys. You hand out copies of the lock but you keep the key to yourself. Anyone can put a lock on a box and know you're the only one who can open it. You tell them what lock to use and then use your key to open it to show them you are who you claim to be.
So I like this. Here's how I see this working for the majority of people who don't know what SSH is:
1. Browsers support syncing between different devices using some type of cloud provider (think Google's sing into Chrome, Safari's iCould integration, etc.). This obviously would need some type of client side encryption to be secure. Could be achieved with a plug in as a stop gap.
2. Browser support for this type of auth. Basically, you'd do <input type="identity" protocol="ssh" nonce="abc">, which would render as a drop down with a list of identities the browser has (which correspond to your private keys). You simply choose one, then submit the form. The server sees your public key (which it may remember after registration), the nonce, and the nonce signed with your private key, verifiable against your public key (I am hand-waving the actual authentication here. This implementation is susceptible to at least replay attacks unless the nonce is remembered by the server.)
That's pretty much it. If you think about it, this is how LastPass works now, except instead of sending a one time signed nonce back to the server it sends a username and plain text password.
I experimented with an alternative HTTP authentication scheme (like basic or digest, using the "WWW-Authenticate" header) that used ssh keys to authenticate the client. Some of the idea was based on this Joyent blog [0] post about signing the date header, but more robust and meant for a user rather than scripted access. The idea was that the browser would interface with a specific ssh-agent with specific keys loaded for specific sites.
Unfortunately, I didn't get very far and stopped working on it a while ago, but one thing I did learn was that the source code for links was much easier to come up to speed on and use for rough experiments than the source code for a full-on graphical browser.
What I've always REALLY wanted to see with regards to SSH and the web is an implementation of the SSH Agent API over web sockets or something. That way if I had some Ansible scripts I wanted to run from a web UI (like something similar to Rundeck) I wouldn't need a key sitting on my server to run those commands. The program invoking Ansible would provide an appropriate value for SSH_AUTH_SOCK that would be connected to my browser and tada. Now, I'm not entirely sure it is feasible, but we've implemented enough crypto in the browser lately, I'd bet it is.
I wonder if you could "bypass" the browser by having a socket on your box that connected to a websocket server (?) that then forwarded your request to the remote box. I haven't had coffee so I'm probably missing something.
I've had this idea before, nice to see it implemented. The reason I've never pursued it as I'm not quite sure what the actual user experience or benefit over traditional 2FA systems is.
I wouldn't mind if my hosting providers offered this in lieu of password auth. All my servers are already pubkey-authentication only and I always have my keys/an SSH client handy
User experience is in the eye of the beholder. My gut tells me the relevant beholder is an actual user and ssh login seems like the sort of thing that could be tested to segment user/application pairs into buckets based on the degree of value it adds. I mean, two factor authentication that requires me to shift my focus from my laptop to my phone and back to my laptop isn't always great for flow...too much meat space involved.
None of which is to say that this is a better solution. I don't think ssh over the web is going to have wide application based on the fact that coordinating ssh is still a devops type of exercise.
I've been meaning to search for exactly this for 'personal production' use. I think it fits the bill in a great way.
Say you have a blog, or even some kind of small application, only you develop/administrate it, and only you ever will. SSHing in couldn't be simpler, but front-end authentication sucks. Everything available feels overkill to just authenticate that you are you. Most recently, I just used HTTP basic auth, resolving to see if there was a way to use SSH 'soon'.
This is as easy and usable by normal people as would be "web login by signing a string with your PGP key". No way.
The solution for this kind of thing is still something like OpenID, however simpler, so everyone can implement everywhere they want, even using custom SSH-OpenID servers, and normal people can use with their Google emails.
Does this ring a bell? That's right, it's BrowserID ladies & gents. I'll never let this go, Persona was a great thing for the web and its death is mourned.
I think I've seen ssh auth implemented before but this is the smoothest POC yet. Your next step: Make a firefox extension that integrates this, as a proof of concept for in-browser authentication.