9 ms·

Web login using SSH

203 points by levosmetalo 11y ago

mbrock 11y ago
Sweet. You can fetch keys from GitHub by username without authenticating, so that could be a convenient way to avoid having to paste keys.
- talleyrand 11y ago
  I'm confused. Would this mean I could just grab anybody's public key and log in - as them - to a service that supported this?
  - brutos 11y ago
    No, you would need to have their private key.
  - pluma 11y ago
    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.
- espadrine 11y ago
  If you assume a GitHub account, you might as well offer GitHub logins.
  - mbrock 11y ago
    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.
    - jessaustin 11y ago
      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?
      - mbrock 11y ago
        Sounds like a good idea for an open source project!
        jessaustin 11y ago
        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.
      - mh- 11y ago
        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? e.g.: ~/.ssh/authorized_keys api.github.com/user/keys iam.amazonaws.com/?Action=CreateAccessKey and so on? (edited for formatting)
        jessaustin 11y ago
        Yes that would be ideal. b^) The thinking is that we never want to move a private key, but public keys can go anywhere.
      - swiley 11y ago
        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)
- im_dario 11y ago
  I think you could use Keybase as reference too.
jamescun 11y ago
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.
- aroch 11y ago
  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
- brudgers 11y ago
  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.
rdancer 11y ago
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
- jamiesonbecker 11y ago
  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!) 1. https://userify.com https://userify.com 2. http://www.ibm.com/developerworks/lotus/library/ls-SSL_client_authentication/ http://www.ibm.com/developerworks/lotus/library/ls-SSL_clien...
- chrissnell 11y ago
  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.
  - 11y ago
joopxiv 11y ago
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.
- detaro 11y ago
  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.
  - joopxiv 11y ago
    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).
    - detaro 11y ago
      It should be possible to build tokens that work without special drivers, requiring "just" application support. (Many 2FA tokens emulate HIDs/keyboards)
themckman 11y ago
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.
- voltagex_ 11y ago
  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. Edit: https://github.com/mcavage/node-ssh-agent https://github.com/mcavage/node-ssh-agent is interesting. You could have a browser extension that connects back to a local daemon.
struppi 11y 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!
- merijnv 11y ago
  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.
  - struppi 11y ago
    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...
    - scrollaway 11y ago
      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.
  - ZeroMinx 11y ago
    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.
scrollaway 11y ago
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.
- reitanqild 11y ago
  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. :)
  - scrollaway 11y ago
    Sandboxed/restricted extensions are a good thing. AFAIK Mozilla has no plan to get rid of the "dangerous" extension api...
    - detaro 11y ago
      Timeline for deprecating everything that isn't using the new WebExtensions API is 12 to 18 months: https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...
  - rpgmaker 11y ago
    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.
PinguTS 11y ago
So, what is the advantage over just using Client Certificates, which are supported by all major browsers? This is how you authenticate with StartSSL.com for example.
fiatjaf 11y ago
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.
IgorPartola 11y ago
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.
j_s 11y ago
This topic (not this project) was last discussed 5 months ago with 150+ comments: https://news.ycombinator.com/item?id=8970402 https://news.ycombinator.com/item?id=8970402 There has also been mention of a few other SSH + browser ideas: http://sshkeybox.com/ http://sshkeybox.com/ https://www.minaterm.com/ https://www.minaterm.com/
dlitz 11y ago
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. 3. bob.com presents an SSH challenge to Mallory ssh demo-ssh.bob.com -l 7d7662f63f70de7714 -p 2222 4. Mallory forwards the challenge from bob.com to Alice, optionally substituting their own hostname: ssh demo-ssh.mallory.net -l 7d7662f63f70de7714 -p 2222 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.
- dlitz 11y ago
  One potential way to solve this would be to include the origin in the challenge, which the server could check: ssh demo-ssh.bob.com -l 7d7662f63f70de7714 -p 2222 https://www.bob.com Mallory's attack then would have the possibility of being detected: ssh demo-ssh.mallory.net -l 7d7662f63f70de7714 -p 2222 https://www.bob.com 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.
thwarted 11y ago
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. I still have notes for it... somewhere. [0] http://joyeur.com/2012/01/03/a-bit-more-about-the-new-joyent-cloud-api/ http://joyeur.com/2012/01/03/a-bit-more-about-the-new-joyent...
OJFord 11y ago
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'.
SixSigma 11y ago
With OpenBSD the pf packet filter can block any port unless there is an active Ssh connection from you too.

203 points by levosmetalo 11y ago

Sweet. You can fetch keys from GitHub by username without authenticating, so that could be a convenient way to avoid having to paste keys.

talleyrand 11y ago
I'm confused. Would this mean I could just grab anybody's public key and log in - as them - to a service that supported this?
- brutos 11y ago
  No, you would need to have their private key.
- pluma 11y ago
  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.
espadrine 11y ago
If you assume a GitHub account, you might as well offer GitHub logins.
- mbrock 11y ago
  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.
  - jessaustin 11y ago
    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?
    - mbrock 11y ago
      Sounds like a good idea for an open source project!
      - jessaustin 11y ago
        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.
    - mh- 11y ago
      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? e.g.: ~/.ssh/authorized_keys api.github.com/user/keys iam.amazonaws.com/?Action=CreateAccessKey and so on? (edited for formatting)
      - jessaustin 11y ago
        Yes that would be ideal. b^) The thinking is that we never want to move a private key, but public keys can go anywhere.
    - swiley 11y ago
      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)
im_dario 11y ago
I think you could use Keybase as reference too.

jamescun 11y ago

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.

aroch 11y ago
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
brudgers 11y ago
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.

rdancer 11y ago

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

jamiesonbecker 11y ago
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!) 1. https://userify.com https://userify.com 2. http://www.ibm.com/developerworks/lotus/library/ls-SSL_client_authentication/ http://www.ibm.com/developerworks/lotus/library/ls-SSL_clien...
chrissnell 11y ago
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.
- 11y ago

joopxiv 11y ago

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.

detaro 11y ago
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.
- joopxiv 11y ago
  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).
  - detaro 11y ago
    It should be possible to build tokens that work without special drivers, requiring "just" application support. (Many 2FA tokens emulate HIDs/keyboards)

themckman 11y ago

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.

voltagex_ 11y ago
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. Edit: https://github.com/mcavage/node-ssh-agent https://github.com/mcavage/node-ssh-agent is interesting. You could have a browser extension that connects back to a local daemon.

struppi 11y 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!

merijnv 11y ago
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.
- struppi 11y ago
  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...
  - scrollaway 11y ago
    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.
- ZeroMinx 11y ago
  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.

scrollaway 11y ago

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.

reitanqild 11y ago
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. :)
- scrollaway 11y ago
  Sandboxed/restricted extensions are a good thing. AFAIK Mozilla has no plan to get rid of the "dangerous" extension api...
  - detaro 11y ago
    Timeline for deprecating everything that isn't using the new WebExtensions API is 12 to 18 months: https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...
- rpgmaker 11y ago
  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.

PinguTS 11y ago

So, what is the advantage over just using Client Certificates, which are supported by all major browsers? This is how you authenticate with StartSSL.com for example.

fiatjaf 11y ago

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.

IgorPartola 11y ago

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.

j_s 11y ago

This topic (not this project) was last discussed 5 months ago with 150+ comments: https://news.ycombinator.com/item?id=8970402 https://news.ycombinator.com/item?id=8970402 There has also been mention of a few other SSH + browser ideas: http://sshkeybox.com/ http://sshkeybox.com/ https://www.minaterm.com/ https://www.minaterm.com/

dlitz 11y ago

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. 3. bob.com presents an SSH challenge to Mallory ssh demo-ssh.bob.com -l 7d7662f63f70de7714 -p 2222 4. Mallory forwards the challenge from bob.com to Alice, optionally substituting their own hostname: ssh demo-ssh.mallory.net -l 7d7662f63f70de7714 -p 2222 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.

dlitz 11y ago
One potential way to solve this would be to include the origin in the challenge, which the server could check: ssh demo-ssh.bob.com -l 7d7662f63f70de7714 -p 2222 https://www.bob.com Mallory's attack then would have the possibility of being detected: ssh demo-ssh.mallory.net -l 7d7662f63f70de7714 -p 2222 https://www.bob.com 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.

thwarted 11y ago

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. I still have notes for it... somewhere. [0] http://joyeur.com/2012/01/03/a-bit-more-about-the-new-joyent-cloud-api/ http://joyeur.com/2012/01/03/a-bit-more-about-the-new-joyent...

OJFord 11y ago

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'.

SixSigma 11y ago

With OpenBSD the pf packet filter can block any port unless there is an active Ssh connection from you too.