15 ms·

Signing in to websites with SSH

382 points by blfr 12y ago

justinsb 12y ago
An SSH key is equivalent to a (self-signed) SSL client certificate. I would love to see an easy way to use your SSH key as a client certificate - either an external tool or the browser itself could support this.
- a3_nm 12y ago
  There is a related project to connect the web of trust of OpenPGP keys, SSH keys, and SSL certificates: http://web.monkeysphere.info/ http://web.monkeysphere.info/
wazari972 12y ago
I love the idea, I think I'll implement something like that to automatically log into the few services I host on my webserver: on machine boot and every hours `ssh webserver echo $SOURCE_IP > token`, and on the web app, if token is not too old in source address == $(cat token), then auto login.
mjn 12y ago
Interesting; this could potentially solve a pain point for me. I run a small set of services for some research collaborators and have been phasing out passwords, so users are authenticated solely via their public keys. That works for most classic "Unix server" stuff. But for the use-case of a remote GUI for scientific computing, the classic solution of network-transparent X is gradually losing out to a more iPython-style solution of a browser front-end. In which case I need to authenticate the same people in their browsers, and it'd be nice to do it via the same public keys.
erikano 12y ago
I like alternative two, except that I'd have it be ssh <token>@<host> auth This feels more natural to me and makes it easier to support other commands in the future should one wish to do so. Regarding the part where he said: >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. That's not a problem. Your server got the host header over HTTP. When you generate the token, just tie the token to that host name.
- petercooper 12y ago
  Yeah, this was what I came here to suggest and had to see if anyone else had beaten me to it ;-) Using the username as the token means no "command" of ambiguous intent is being copy pasted but resolves many of the usability issues.
- duncankl 12y ago
  Good point about the <token>@<host> format, I like it much better too. You're right about tying tokens to host names, that would work. But you'd have to justify whether the extra complexity of multiple web servers preregistering tokens with a SSH front-end was worth it. Another approach would be embedding a static host identifier in the username as well. Although my knowledge of the SSH protocol isn't complete, a related issue appears to be that servers prove their identity before clients send their usernames. That means servers sharing the same IP/port would also have the same host fingerprint. It could be acceptable if all the services were run by the same organisation, but on a platform like Heroku it would be more of a challenge.
  - epaulson 12y ago
    It wouldn't be too hard to extend the SSH protocol to include something like the HTTP Host-request header. In the protocol exchange section of the SSH RFC ( https://tools.ietf.org/html/rfc4253#section-4.2 https://tools.ietf.org/html/rfc4253#section-4.2 ) the format described is: SSH-protoversion-softwareversion SP comments CR LF In the comment section of the message, you could add something like "X-Host: hostname.wherever.org" and a smart SSH server could proxy the connection to the correct host. This happens before the key exchange occurs, so you'd still get strong authentication from having the right key. I checked through the OpenSSH and Paramiko code, and both essentially ignore the comment section of the version exchange - everything between the first space and the CR/LF at the end. They does hold on to it for part of the DH key exchange, but they never try to interpret the bytes, so a modified client could keep sending the X-Host extension and stock OpenSSH would just ignore it.
slyley 12y ago
Wow. I just have one question for you: why? Have you ever heard of TLS and client certificates? Every browser and every decent web server supports TLS with a client certificate for auth.
- Galanwe 12y ago
  What I thought, exactly.
- brutos 12y ago
  Have you ever used that? The user experience is horrible. Here [1] are a few more reasons why client certificate right now are just plain bad. [1] http://www.browserauth.net/tls-client-authentication http://www.browserauth.net/tls-client-authentication
  - icebraining 12y ago
    But how is this solution any better?
  - derefr 12y ago
    So why are people trying to replace the algorithm, when what we need to do is to replace the UX? Patches could be submitted for both Chromium and Firefox to give them a better client-cert flow, but I don't see anyone working on the problem; just a constant parade of restyling on tab-strip and toolbar and notification banner UX. I mean, ideally, a client cert would be treated pretty much exactly like a cookie: generated on first connection to a website and automatically stored by the client; synced across browsers; etc. And, I mean, you could treat a client cert like a permanently logged-in account credential, but it'd be much better to just treat it as essentially an unforgeable browser fingerprint+session ID: something that just "pairs" the client and the server, but where you still have to log in after that pairing process, but only once. (As long as the cert gets synced to another browser, that browser is now logged into the site, because it's now sending the fingerprint of a "session" that's logged into the site.) With such a setup, you would be able to just "clear" the client cert (like a cookie) to log out, and then get issued a new one and log in again on that one, if you wanted. You wouldn't have to worry about losing your cert. You'd be able to have multiple devices with multiple client certs that are each separately logged into the same account, if you wanted. But, since each client cert would be associated with an account, and vice-versa, you'd be able to revoke a client cert's access to a particular account: to, effectively, log another device out remotely. The nice thing about this workflow, actually, is that each and every HTTPS site could always issue each visitor a client cert, just as we currently generate server-side session IDs for each visitor. It'd become a best practice to have client cert issuance on by default at the load-balancer level, like HSTS is now. (And load balancers can just translate client certs into a plaintext "browser fingerprint hash" HTTP header, that can be detected by anything further along the request chain that currently knows how to deal with cookie or URL session IDs.)
prateek_mir 12y ago
A brilliant Idea; as far as usability for a normal user is concerned, How feasible is it to modify a browser to take the command directly via the address bar, and internally a thread can handle the ssh part, redirecting the user directly to the newly generated link ?
- the8472 12y ago
  Would be feasible as a firefox addon since those have the same privileges as the browser process itself. Afaik chrome's extension APIs are too restrictive to allow for something like that.
- icebraining 12y ago
  Not that hard (I've written Firefox extensions that run external programs), but what would you gain over SSL client certs, which are already supported?
  - XorNot 12y ago
    I have an SSH key and use it routinely. I've never used SSL client certs.
    - stephenr 12y ago
      At some point in time you'd never used an SSH key, either. And then you did.
geocar 12y ago
No need for custom url formats. Keep it really simple: Use a <link rel="ssh"> and rely on browsers to prompt us to "log in with ssh". IF there's no public key, the browser could offer to run ssh-keygen for the user and save the results in the user's keychain. If we use switcher[1], we can even put ssh and https on the same hostname and on the same point. This would be a recommended configuration since it would get through most proxies. [1]: https://github.com/jamescun/switcher https://github.com/jamescun/switcher
- stephenr 12y ago
  The demo doesn't work for me - when I load the echo'd URL it shows up with "log out" on the left side but once the globe appears I get just "sign in with SSH to place a pin" again. However, the correct way to do this is the way browsers link to external protocols already: <a href="ssh://mars.vtllf.org">Open SSH connection</a> This is no different than a mailto: link, a skype: button, an ftp:// link, or any other link in a webpage that uses a protocol other than HTTP/HTTPS. Frankly, I don't want my browser talking to SSH servers. Because that means it has access to my SSH keys. If you don't think its a problem for your browser (that thing that runs javascript from anywhere on the planet) to have access to your SSH keys, the point of my comment will no doubt be missed. A browser should do one thing, and do it well: browse pages. Once you start adding SSH clients, RDP clients, etc, you are simply inviting security holes, and arguably missing the whole point of local apps.
- nothrabannosir 12y ago
  And please, please, please add the fingerprint to that: <link rel="ssh" data-fingerprint="8b:16:df:7b:11:7c:78:1c:4d:65:3f:50:71:2b:91:5d" > Or whatever your fancy, I don't care how, but please add that fingerprint. SSH displaying the user a fingerprint on first connect and allowing it to accept is its worst UI mistake.
  - stephenr 12y ago
    Yet again, there is already a mechanism for this. Add your fingerprints to DNS (they can be obtained using ssh-keygen -r <hostname>) Set the SSH option VerifyHostKeyDNS to "yes" (or "ask" if you want to confirm, with a notice about if the DNS entry matches).
ams6110 12y ago
I've worked in support of computing clusters that are widely used by researchers. By far the most common problem people had with using these systems was grokking ssh keys. Masters and PhD Computer Science people are routinely baffled by them, provide their private keys instead of their public keys, or provide both, etc. People in general just don't get public/private key pairs. Any solution that requires any awareness or handling of the keys by the user is a non-starter. Sorry to sound negative but after a couple of decades of observation I'm convinced this will never change.
- silon3 12y ago
  Yup, it's not really specific to SSH. The same problems occur using SSL X509 client certificates. Non-technical users will get confused unless they have a smart card/token that secures their private key.
- ZoFreX 12y ago
  > provide their private keys instead of their public keys I see this quite frequently from developers, as well. Hands down one of the worst design decisions of OpenSSH was to make private keys tab complete before public keys.
- tormeh 12y ago
  It could work, but it's a bit hard to wrap your head around public/private keys. Cryptographic keys has to either be an everyday encounter or something we never do. I don't think such a weird thing can be anything in between.
- loudmax 12y ago
  It will never change as long as using public/private key pairs is something exotic most people rarely use. I was baffled too when I first started using ssh keys, but today it's second nature. I get how they work, at least on a theoretical level. And I think most of us here on HN are like that. This isn't about being smart or of a mathematical bent, it just comes down to practice.
- scott_s 12y ago
  If you read to the end, you'll discover the author comes to the same conclusion.
jerinaw 12y ago
What about this solution? https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm
- Sarien 12y ago
  It's pretty much the same thing but using QR codes. One thing that SQRL has is automatic management of different keys for each site. It wouldn't be hard to add that to the ssh version, though. Using QR codes for getting the challenge is also nice because you can just read them with your phone on an untrusted computer.
- nly 12y ago
  SQRL is vulnerable to phishing and spoofing attacks due to the lack of mutual authentication. I can send you a phishing email with a link to a webpage that looks like PayPal, on mynastydomain.com, and then display an actual PayPal QR code to you. There's no complete solution to this all the time you're passing tokens with an unauthenticated association over an air gap. The IP binding proposal is a just a disaster for a number of reasons. This system provides mutual authentication and the ssh command (that the user will surely copy and paste) doesn't contain any tokens. The session token is produced after authentication has taken place.
  - themattrix 12y ago
    Care to expand on this a bit? I'm somewhat familiar with SQRL, but what was this IP binding proposal all about? Is this a use-case not discussed in the SQRL phishing page? https://www.grc.com/sqrl/phishing.htm https://www.grc.com/sqrl/phishing.htm
    - nly 12y ago
      It's there buried in the discussions somewhere. The basic (and old) idea is to shove the IP of the user (or spoof as the case may be), as seen by the web server, in to the QR code and then tie it to with the session token using a MAC. When the SQRL app passes the signed SQRL data back to the web server it passes this back as well. The server can then reverify the users IP (remember they're now using the app on another device). IP binding is worth doing but there's no way for the app to warn the user that the IP differs. You have to trust the server implementation of SQRL (which despite what Gibson claims, is actually fairly complex on the server-side) Other issues are discussed on the page you linked entitled "Details and Limitations of IP-based MITM detection"
kolodny 12y ago
I may be missing something but this seems highly susceptible to man in the middle attacks
- davea37 12y ago
  If the web page was served over HTTPS and provided the SSH server's fingerprint for the user to verify, wouldn't that get around the MITM risk?
skratlo 12y ago
This is brilliant. Here a full-fledged solution: the same way every OS supports users, it should support identities attached to the user account (~/.ssh). Upon OS installation / user creation, it would prompt the user to either generate new identity, or import existing one (from a flash drive, from a cloud, etc.). This would be the key pair. And the browser would automatically use this, without any terminal session or any such non-sense. Brilliant, right? No, because user accounts are commonly shared: here, can I check my mail on your computer? Yes, password won again :P
- swadworth 12y ago
  >Brilliant, right? No, because user accounts are commonly shared Gee, I guess only I can drive my car. If only there were some way to share my car with my spouse. Like having a second set of keys or something...
tux 12y ago
Very cool. This could be used to count linux users. Like http://linuxcounter.net/ http://linuxcounter.net/
- nacs 12y ago
  I remember that site from years ago but it seems awfully out of date at this point. Even the Ubuntu distro's opt-in share-my-desktop-stats system likely contains multiple times what Linux Counter is counting.
NietTim 12y ago
Never thought about it like this, this is pretty ingenious!
- mkorfmann 12y ago
  It's actually fairly simple, but not usable for 99% of web users.
jasonkester 12y ago
"SSH is near-universally loved among developers." Really? Which developers? SSH is one of those things you get forced to deal with a couple times a year for some irritating task, and it involves firing up Putty, figuring out where you left your key file, trying to remember how to actually load that key file, and a bunch of following steps on some website just to get connected to what you were trying to connect to. It is not something that I love. If you force me to use it just to log in to your website, I will decline to do so.
- IgorPartola 12y ago
  I think I found the Windows developer :). It is loved by pretty much everyone but Windows developers because it really is the best thing since sliced bread.
  - bogdansolga 12y ago
    I'll second to that :)
  - vbezhenar 12y ago
    Funny thing is that many windows developers and administrators like to use RDP, while *nix users generally don't like it at all (usually because RDP doesn't allow easy scripting to automate routine tasks).
- vog 12y ago
  Note that although PuTTY has a graphical user interface, it is hardly user friendly. Using the command-line ssh (with a decent shell) is much more comfortable.
  - k__ 12y ago
    It's still a nice SSH client
- gambiter 12y ago
  Just the fact that you think SSH equates to Putty is laughable, and shows your ignorance. .NET and Java developers, at least the ones who seem to think anything non-Windows is bad, don't understand SSH. When you don't understand it, you don't see the value of using it, which means it doesn't get installed on your servers, and you are left thinking it's only an 'irritating task' kind of thing. I use SSH on a daily basis. Right now, from work, I have five SSH connections open, one is tunneling, one is tunneling and providing an interactive shell on one of my personal machines, one is connected to the live environment for server monitoring, and two are connected to the development environment. I'm running everything from applications, to the command line to my IDE (vim) all in SSH sessions. Just because you personally don't understand a key bit of internet technology doesn't mean it's the same for everyone else. There are those of us who see a valuable tool and use it properly.
neaanopri 12y ago
What does "PTY allocation request failed on channel 0" mean?
- yock 12y ago
  On the surface, it means SSH tried, and failed, to initiate an interactive session. In context, it means that either the developer has disabled new users, or this is simply broken at the moment.
- duncankl 12y ago
  When SSH clients first connect they ask the server for a pseudo terminal (PTY), to enable terminal colors, clearing the screen etc. In this case the SSH server declines that request because it simply wants to send back one line of text. The client falls back to text mode and works fine, but issues the warning anyway. You can suppress it with `ssh -T mars.vtllf.org` like I did in the demo video.
IgorPartola 12y ago
I am not sure about this. First, there is a built in MITM attack here. First time you connect to sshd, the server has no idea who you are. I suppose this could be mitigated by using HTTPS as the out-of-band channel for verifying client and server fingerprints. Second, ssh keys are somewhat limited. You can only have one public key for a private key. You cannot embed identity info in the public key. I would much rather see hog keys used for this. For developer types that should be just as easy. For real people the UI would still have to be developed but could actually include useful features, such as user identities.
- icebraining 12y ago
  First time you connect to sshd, the server has no idea who you are. That's not a problem if you signup by first connecting to the sshd and getting a custom signup URL.
  - IgorPartola 12y ago
    How do you know that the sshd you connect to is authentic and not a MITM? More importantly, how does the sshd know that the incoming connection is you and not a MITM?
    - icebraining 12y ago
      How do you know that the sshd you connect to is authentic and not a MITM? You'd need the server fingerprint on the site (served over https, of course). More importantly, how does the sshd know that the incoming connection is you and not a MITM? But that's the point, there is no "you" to authenticate, since you're signing up for a new account. The sshd generates a token URL and then stores your fingerprint with that token. Then you can use that token to login to the actual site and fill in your information. If you're MITMing someone, the server shouldn't care, it's the client's job to make sure it's talking to the right server. See above.
- swadworth 12y ago
  >I am not sure about this. First, there is a built in MITM attack here. This always sounds like a NSA shill argument to me. Sure, you can MITM, but then, you HAVE to MITM on the very first request of every user to make that work. That's much more expensive than vacuuming up passwords server side with gag orders. >Second, ssh keys are somewhat limited... You cannot embed identity info in the public key. That's ridiculous. Who would want to? You are looking for an authorization solution. SSH is for authentication.
ddebernardy 12y ago
I'm suspicious that this is any better than TLS and client certificates. Plus, it's not entirely clear what's supposed to happen when your family and friends are using your computer, or when your laptop is simply stolen.
- IgorPartola 12y ago
  Surely you passphrase protect your id_rsa!
  - mkorfmann 12y ago
    Back to entering passwords (or passphrases for that matter)... Yay!
    - swadworth 12y ago
      That's a retarded retort. In the SSH case you have ONE password to remember. Not one per website. Furthermore, the password never leaves your machine. Log in to a hundred websites with SSL and a password and the NSA comes along, collects all your passwords server side, knows which ones you reuse, knows your password generation patterns, everything. You are completely nuts if you think these two things are the same.
      - icebraining 12y ago
        You have a good point. You're also completely over-the-top aggressive for a discussion about website authentication.
        swadworth 12y ago
        Sorry dad. You're right, it would be a real shame if the padded corners police came and modded down the intelligent posts. This site might just turn into a groupthink circlejerk if that happened :-/
fideloper 12y ago
Adding "-vvv" to the given SSH command, it looks like it uses the first SSH key given. I happen to have quite a few for various services. I suppose you could offer up one specifically by running ssh -o "IdentitiesOnly yes" -i ~/.ssh/id_whatever mars.vtllf.org (I use the IdentitiesOnly option because I often see ssh still offer other keys without it)
- duncankl 12y ago
  Thank you! I was looking for that option while writing the section on throwaway keys. I'll have to test it out.
deleted 12y ago
[deleted]
xnyhps 12y ago
So you have a situation where the client has already authenticated the server using TLS, and now the server wants to authenticate the client too. This solution wants to do that by setting up a new channel, authenticating the server /again/ and then also the client. Yeah, I don't think this is a good idea.
nly 12y ago
The only substantial advantage to this scheme is you get server id pinning for free (via your known_hosts file), but a combination of HTTP public key pinning[0] and client-side certificates will give you all the same advantages with far less user effort. [0] https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn...
- deleted 12y ago
  [deleted]
- comex 12y ago
  You get pinning... and absolutely no verification the first time you connect, so anyone who got lucky enough to MitM you the first time (or first time since you deleted your known_hosts file or reinstalled your operating system or switched computers) can log in as you, without having to compromise any PKI. Meh.
falcolas 12y ago
I love this idea, but I have some issues with their chart, particularly as related to authentication via email. A developer with a few minutes of thinking time could get around the "red" spots associated with email authentication, and fill in any missing dots pretty easily. And for better or worse, email is currently one of the better ways to create an identity for the masses, and it's also one of the few systems that your average user can justify the pain of setting up 2 factor auth on. The only thing better would be to use text messages, if you could come up with a way to lower the impedance for the user.
salzig 12y ago
use <keygen>[1] and generate a client side certificate for authentication? [1]: https://developer.mozilla.org/de/docs/Web/HTML/Element/keygen https://developer.mozilla.org/de/docs/Web/HTML/Element/keyge...
- nacs 12y ago
  English version of parent: https://developer.mozilla.org/en/docs/Web/HTML/Element/keygen https://developer.mozilla.org/en/docs/Web/HTML/Element/keyge...
eatonphil 12y ago
Would this become more usable if it was natively supported by the web browser? Couldn't the browser take care of generating the keys and whatnot?
- swadworth 12y ago
  <keygen> can generate client side keys. It's not very good, but it exists.
timtadh 12y ago
I want to thank the author for testing this out and doing an implementation. When Mozilla Persona came out I thought it would be cool to make an identity provider which support SSH based auth. I never had much time to work on it so seeing the various design problems was really great. I do think you can make some improvements when paired with a system such as persona but the fundamental challenge that SSH is not integrated into the web remains. Still, as programmer, I would love it if I could auth to github et. al with SSH keys. I would actually feel more secure doing that than with the password. Keep the 2 factor token either way. I completely agree with the author's assessment that this type of system would not work for the average web user.
- duncankl 12y ago
  Glad you liked it! I definitely echo the sentiment of wanting to use these sorts of power-user-only tools. But I think Moxie's recent post, They Live[1], does an excellent job of explaining why we shouldn't accept that the tools are too hard for everyone else, then just hoard them for our own use anyway. [1]: https://whispersystems.org/blog/they-live/ https://whispersystems.org/blog/they-live/
  - jwise0 12y ago
    Adding on to the praise, I wanted to also comment -- thanks for doing an analysis of the results. Having implemented it was neat, but the honesty in revealing that what you've built is an interesting experiment, but not necessarily an improvement on the status quo, is commendable. There is still lots to be learned from the work you did -- both the technical and the analytical. I think this is probably the most striking example I've seen recently of "negative results are results, too". Thanks for the writeup.
- ams6110 12y ago
  as programmer, I would love it if I could auth to github et. al with SSH keys Um, you can?
  - zymhan 12y ago
adamtj 12y ago
I love SSH, but I don't want to actually use SSH for this. That's not the important part. All I want is key-based authentication, and that doesn't need SSH. I want to be able to plug a security token into a USB port and be logged in, without even having to click a sign-in button. Reformat, reinstall, reboot, plug in security token, launch browser, type news.ycombinator.com and I'm already logged in.
- stephenr 12y ago
  I don't know if I'm missing something here, but it sounds like what you want is just SSL/TLS Client Certificates using PKSC#11 for the private key?
  - e12e 12y ago
    Which is also usable for authenticating to ssh (but needs to set up as such certs are different from ssh key and from ssh "native" certs).
- chubot 12y ago
  You can do this with google products: https://support.google.com/accounts/answer/6103523?hl=en https://support.google.com/accounts/answer/6103523?hl=en You just have to touch the USB security token to have it release the key. I believe the idea is that malware can't really trick you into touching it, so it's more secure.
  - Rafert 12y ago
    It's works a bit different than 'releasing a key': http://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-u2f-overview-ps-20141009.html#site-specific-public-private-key-pairs http://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido...
wampus 12y ago
The author makes a very good case for why this approach won't threaten password-based authentication, including: ...hard for first-time users to get right:... The private key being unlocked and available via ssh-agent. For this to be convenient for daily use, ssh-agent is essential, and that could expose naive users to compromise. I know enough to disable ForwardAgent in my personal config by default and generate site-specific keys for hosts I can't trust, but that's beyond most ordinary users and even many of the technical professionals I deal with. It's a shame PGP was the target of so much persecution when it came out. Maybe by now we would have worked out the key exchange problem and would all be enjoying personally encrypted communication on the Internet. I sometimes feel that any attempt to move beyond passwords without realizing that ideal is doomed to failure.
- hamburglar 12y ago
  I think one solution would be for the browser (or an extension) to expose an SSH agent API through the DOM, but gate access to that agent with local UI that confirms operations. "Facebook.com would like to view your public identity information. Continue?" with an "always allow for this site" option. "Facebook.com is requesting a signing challenge to verify your public identity. Allow?" etc. It could even include an identity manager which would allow you to generate different identities to present to different sites on the fly. You could have the option of having the requests pass through to your SSH_AGENT_SOCK (still gated by UI though) if you want, or you could just let the browser maintain its own independent agent (or potentially a combination).
rohansingh 12y ago
We use a philosophically similar solution at Spotify: https://github.com/spotify/crtauth https://github.com/spotify/crtauth The difference with crtauth is that you don't need an SSH server running in tandem, everything is handled by the crtauth library. Our main use case for this is for bots that need to access secure services. Protocol spec: https://github.com/spotify/crtauth/blob/master/PROTOCOL.md https://github.com/spotify/crtauth/blob/master/PROTOCOL.md
BrainInAJar 12y ago
Why not just use HTTP Signature Auth ? ( https://datatracker.ietf.org/doc/draft-cavage-http-signatures/ https://datatracker.ietf.org/doc/draft-cavage-http-signature... )
deleted 12y ago
[deleted]
patio11 12y ago
It is actually pretty useful to require SSH as a two-factor authentication method for internal services, particularly extraordinarily sensitive internal services which you'll expose solely to technical employees. I use it for exactly one purpose: authorizing the "ghosting" of a customer account. ("Log in as this user.") Putting that behind SSH means that anyone authorizing a ghosting has both a blessed SSH key and the password to it. Even rooting my session on our admin app, via reflected XSS or stealing my unlocked laptop out of my hands, doesn't get you that. (Our admin app, by design, is less-than-all-powerful. A malicious admin session could do a heck of a lot of damage to our business but, critically, would be unable to access personally identifying data about customers' clients.)
- deleted 12y ago
  [deleted]
- nzealand 12y ago
  You use vanilla ssh to authorize the ghost of a customer account?
  - patio11 12y ago
    I'm not sure I understand the question. Here's what gets typed: ssh foo.example.com #uses private/public key per conf file *enter password* cd app ruby script/console irb > u = User.find_by_email "customer@example.net" irb > u.authorize_ghosting! "Reason for log goes here." * you'll want to incognito mode the URL returned here* irb > exit exit
    - cat9 12y ago
      With all due love and respect: This is something I would wrap a simple CLI around, and then kick myself in the tukhus for having ever used the language's interactive client to make raw database queries and edits on the production server.
      - tedunangst 12y ago
tedchs 12y ago
Why not use client-side SSL certificates in the browser?
hughes 12y ago
This question might be hilariously naive... but why don't web browsers make signed requests, just as web servers make signed responses? If I create an account on a website, then associate a public key with my account, shouldn't the browser be able to sign each request with my key? The website then wouldn't ever even have to deal with cookies or sessions as long as I was logged in to my browser. Or better yet, if my key is publicly known and trusted, couldn't a website know who I am before I even create an account? It could skip the signup process entirely.
- NathanKP 12y ago
  I'm sure that tracking services and ad companies would love signed requests.
  - hughes 12y ago
    Well, it could maybe be an opt-in feature, like when a site requests to use your webcam or microphone. A small prompt that the server is requesting to access your identity or something.
- gergles 12y ago
  https://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-certificates/ https://pilif.github.io/2008/05/why-is-nobody-using-ssl-clie...
  - duncankl 12y ago
    Thanks for the link! I added it to the article.
- scott_karana 12y ago
  This idea is exactly what I've always wanted, too. As others point out, it would definitely have to be opt-in, or it would be a great way to track. (It would be nice to have ephemeral keys per-site, too, a la Bitcoin: why have a publically unified identity?)
jrochkind1 12y ago
> You can see where this is heading—a half-baked reimplementation of TLS client authentication with all the same usability nightmares. Yeah, that's what I was thinking -- why would you do this instead of just using TLS client auth? TLS client auth is a usability nightmare -- but I'm not sure it's any _worse_ than what's in OP.
sparaker 12y ago
A beautiful simple implementation for signing into websites using SSH. I think this idea can be very helpful for developers, perhaps give them good scripts to hot reload a patch on production servers.
falsedan 12y ago
You don't need to edit a hidden config file to remove an old known_host entry, just run: ssh-keygen -R <host>
- duncankl 12y ago
  Thanks for the tip, I wasn't expecting that feature to be part of ssh-keygen.
vbezhenar 12y ago
That technique would useful when user wants to add public key into his github profile (or similar service). Instead of asking user to copy&paste his public key, site might ask him to enter `ssh github.com authtoken` in terminal.
- stephenr 12y ago
  So then you have two avenues for attack, if someone wants to inject their own public key into your account - the Web UI and some form of custom SSH server. Besides which you would need more than just "ssh github.com authtoken" - it doesn't identify who you are (thus knowing who to save the public key for)
  - vbezhenar 12y ago
    > So then you have two avenues for attack, if someone wants to inject their own public key into your account - the Web UI and some form of custom SSH server. That's correct. SSH misses PKI and github can't sign their ssh public keys with trusted authority. If someone intercepting your traffic, he can redirect your connection to 22 port to malicious ssh server and save his malicious public key to github. To prevent that, github must present ssh fingerprint into their web page and user must check that fingerprint with one he can see on terminal. Thanks for clarification. > Besides which you would need more than just "ssh github.com authtoken" - it doesn't identify who you are (thus knowing who to save the public key for) authtoken is supposed to be an unique identifier and github server knows that it's associated with your account.
    - stephenr 12y ago
      > github must present ssh fingerprint into their web page and user must check that fingerprint yet another case where DNSSEC secured SSHFP records would automate this. However, given that people currently commit and push passwords, private keys and who knows what else to places like GitHub, it seems unlikely these people would recognise why a connection might refuse (e.g. because of an invalid fingerprint) anyway > authtoken is supposed to be an unique identifier and github server knows that it's associated with your account ah sorry I thought "authtoken" was meant to be some command to run on the server. Frankly I think things like adding a public key (whether to GitHub or a system that allows SSH logins) over the internet, are probably safer behind a double factor auth system (e.g. password + otp or client cert + otp) - the people who need to use it can be shown how to copy their public key quite easily (if they can't open Terminal.app, type "cat ~/.ssh/id_rsa.pub | pbcopy" and then paste the result into a web form, can they really handle Git, or even SSH for that matter?)

382 points by blfr 12y ago

An SSH key is equivalent to a (self-signed) SSL client certificate. I would love to see an easy way to use your SSH key as a client certificate - either an external tool or the browser itself could support this.

a3_nm 12y ago
There is a related project to connect the web of trust of OpenPGP keys, SSH keys, and SSL certificates: http://web.monkeysphere.info/ http://web.monkeysphere.info/

wazari972 12y ago

I love the idea, I think I'll implement something like that to automatically log into the few services I host on my webserver: on machine boot and every hours `ssh webserver echo $SOURCE_IP > token`, and on the web app, if token is not too old in source address == $(cat token), then auto login.

mjn 12y ago

Interesting; this could potentially solve a pain point for me. I run a small set of services for some research collaborators and have been phasing out passwords, so users are authenticated solely via their public keys. That works for most classic "Unix server" stuff. But for the use-case of a remote GUI for scientific computing, the classic solution of network-transparent X is gradually losing out to a more iPython-style solution of a browser front-end. In which case I need to authenticate the same people in their browsers, and it'd be nice to do it via the same public keys.

erikano 12y ago

I like alternative two, except that I'd have it be ssh <token>@<host> auth This feels more natural to me and makes it easier to support other commands in the future should one wish to do so. Regarding the part where he said: >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. That's not a problem. Your server got the host header over HTTP. When you generate the token, just tie the token to that host name.

petercooper 12y ago
Yeah, this was what I came here to suggest and had to see if anyone else had beaten me to it ;-) Using the username as the token means no "command" of ambiguous intent is being copy pasted but resolves many of the usability issues.
duncankl 12y ago
Good point about the <token>@<host> format, I like it much better too. You're right about tying tokens to host names, that would work. But you'd have to justify whether the extra complexity of multiple web servers preregistering tokens with a SSH front-end was worth it. Another approach would be embedding a static host identifier in the username as well. Although my knowledge of the SSH protocol isn't complete, a related issue appears to be that servers prove their identity before clients send their usernames. That means servers sharing the same IP/port would also have the same host fingerprint. It could be acceptable if all the services were run by the same organisation, but on a platform like Heroku it would be more of a challenge.
- epaulson 12y ago
  It wouldn't be too hard to extend the SSH protocol to include something like the HTTP Host-request header. In the protocol exchange section of the SSH RFC ( https://tools.ietf.org/html/rfc4253#section-4.2 https://tools.ietf.org/html/rfc4253#section-4.2 ) the format described is: SSH-protoversion-softwareversion SP comments CR LF In the comment section of the message, you could add something like "X-Host: hostname.wherever.org" and a smart SSH server could proxy the connection to the correct host. This happens before the key exchange occurs, so you'd still get strong authentication from having the right key. I checked through the OpenSSH and Paramiko code, and both essentially ignore the comment section of the version exchange - everything between the first space and the CR/LF at the end. They does hold on to it for part of the DH key exchange, but they never try to interpret the bytes, so a modified client could keep sending the X-Host extension and stock OpenSSH would just ignore it.

slyley 12y ago

Wow. I just have one question for you: why? Have you ever heard of TLS and client certificates? Every browser and every decent web server supports TLS with a client certificate for auth.

Galanwe 12y ago
What I thought, exactly.
brutos 12y ago
Have you ever used that? The user experience is horrible. Here [1] are a few more reasons why client certificate right now are just plain bad. [1] http://www.browserauth.net/tls-client-authentication http://www.browserauth.net/tls-client-authentication
- icebraining 12y ago
  But how is this solution any better?
- derefr 12y ago
  So why are people trying to replace the algorithm, when what we need to do is to replace the UX? Patches could be submitted for both Chromium and Firefox to give them a better client-cert flow, but I don't see anyone working on the problem; just a constant parade of restyling on tab-strip and toolbar and notification banner UX. I mean, ideally, a client cert would be treated pretty much exactly like a cookie: generated on first connection to a website and automatically stored by the client; synced across browsers; etc. And, I mean, you could treat a client cert like a permanently logged-in account credential, but it'd be much better to just treat it as essentially an unforgeable browser fingerprint+session ID: something that just "pairs" the client and the server, but where you still have to log in after that pairing process, but only once. (As long as the cert gets synced to another browser, that browser is now logged into the site, because it's now sending the fingerprint of a "session" that's logged into the site.) With such a setup, you would be able to just "clear" the client cert (like a cookie) to log out, and then get issued a new one and log in again on that one, if you wanted. You wouldn't have to worry about losing your cert. You'd be able to have multiple devices with multiple client certs that are each separately logged into the same account, if you wanted. But, since each client cert would be associated with an account, and vice-versa, you'd be able to revoke a client cert's access to a particular account: to, effectively, log another device out remotely. The nice thing about this workflow, actually, is that each and every HTTPS site could always issue each visitor a client cert, just as we currently generate server-side session IDs for each visitor. It'd become a best practice to have client cert issuance on by default at the load-balancer level, like HSTS is now. (And load balancers can just translate client certs into a plaintext "browser fingerprint hash" HTTP header, that can be detected by anything further along the request chain that currently knows how to deal with cookie or URL session IDs.)

prateek_mir 12y ago

A brilliant Idea; as far as usability for a normal user is concerned, How feasible is it to modify a browser to take the command directly via the address bar, and internally a thread can handle the ssh part, redirecting the user directly to the newly generated link ?

the8472 12y ago
Would be feasible as a firefox addon since those have the same privileges as the browser process itself. Afaik chrome's extension APIs are too restrictive to allow for something like that.
icebraining 12y ago
Not that hard (I've written Firefox extensions that run external programs), but what would you gain over SSL client certs, which are already supported?
- XorNot 12y ago
  I have an SSH key and use it routinely. I've never used SSL client certs.
  - stephenr 12y ago
    At some point in time you'd never used an SSH key, either. And then you did.

geocar 12y ago

No need for custom url formats. Keep it really simple: Use a <link rel="ssh"> and rely on browsers to prompt us to "log in with ssh". IF there's no public key, the browser could offer to run ssh-keygen for the user and save the results in the user's keychain. If we use switcher[1], we can even put ssh and https on the same hostname and on the same point. This would be a recommended configuration since it would get through most proxies. [1]: https://github.com/jamescun/switcher https://github.com/jamescun/switcher

stephenr 12y ago
The demo doesn't work for me - when I load the echo'd URL it shows up with "log out" on the left side but once the globe appears I get just "sign in with SSH to place a pin" again. However, the correct way to do this is the way browsers link to external protocols already: <a href="ssh://mars.vtllf.org">Open SSH connection</a> This is no different than a mailto: link, a skype: button, an ftp:// link, or any other link in a webpage that uses a protocol other than HTTP/HTTPS. Frankly, I don't want my browser talking to SSH servers. Because that means it has access to my SSH keys. If you don't think its a problem for your browser (that thing that runs javascript from anywhere on the planet) to have access to your SSH keys, the point of my comment will no doubt be missed. A browser should do one thing, and do it well: browse pages. Once you start adding SSH clients, RDP clients, etc, you are simply inviting security holes, and arguably missing the whole point of local apps.
nothrabannosir 12y ago
And please, please, please add the fingerprint to that: <link rel="ssh" data-fingerprint="8b:16:df:7b:11:7c:78:1c:4d:65:3f:50:71:2b:91:5d" > Or whatever your fancy, I don't care how, but please add that fingerprint. SSH displaying the user a fingerprint on first connect and allowing it to accept is its worst UI mistake.
- stephenr 12y ago
  Yet again, there is already a mechanism for this. Add your fingerprints to DNS (they can be obtained using ssh-keygen -r <hostname>) Set the SSH option VerifyHostKeyDNS to "yes" (or "ask" if you want to confirm, with a notice about if the DNS entry matches).

ams6110 12y ago

I've worked in support of computing clusters that are widely used by researchers. By far the most common problem people had with using these systems was grokking ssh keys. Masters and PhD Computer Science people are routinely baffled by them, provide their private keys instead of their public keys, or provide both, etc. People in general just don't get public/private key pairs. Any solution that requires any awareness or handling of the keys by the user is a non-starter. Sorry to sound negative but after a couple of decades of observation I'm convinced this will never change.

silon3 12y ago
Yup, it's not really specific to SSH. The same problems occur using SSL X509 client certificates. Non-technical users will get confused unless they have a smart card/token that secures their private key.
ZoFreX 12y ago
> provide their private keys instead of their public keys I see this quite frequently from developers, as well. Hands down one of the worst design decisions of OpenSSH was to make private keys tab complete before public keys.
tormeh 12y ago
It could work, but it's a bit hard to wrap your head around public/private keys. Cryptographic keys has to either be an everyday encounter or something we never do. I don't think such a weird thing can be anything in between.
loudmax 12y ago
It will never change as long as using public/private key pairs is something exotic most people rarely use. I was baffled too when I first started using ssh keys, but today it's second nature. I get how they work, at least on a theoretical level. And I think most of us here on HN are like that. This isn't about being smart or of a mathematical bent, it just comes down to practice.
scott_s 12y ago
If you read to the end, you'll discover the author comes to the same conclusion.

jerinaw 12y ago

What about this solution? https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm

Sarien 12y ago
It's pretty much the same thing but using QR codes. One thing that SQRL has is automatic management of different keys for each site. It wouldn't be hard to add that to the ssh version, though. Using QR codes for getting the challenge is also nice because you can just read them with your phone on an untrusted computer.
nly 12y ago
SQRL is vulnerable to phishing and spoofing attacks due to the lack of mutual authentication. I can send you a phishing email with a link to a webpage that looks like PayPal, on mynastydomain.com, and then display an actual PayPal QR code to you. There's no complete solution to this all the time you're passing tokens with an unauthenticated association over an air gap. The IP binding proposal is a just a disaster for a number of reasons. This system provides mutual authentication and the ssh command (that the user will surely copy and paste) doesn't contain any tokens. The session token is produced after authentication has taken place.
- themattrix 12y ago
  Care to expand on this a bit? I'm somewhat familiar with SQRL, but what was this IP binding proposal all about? Is this a use-case not discussed in the SQRL phishing page? https://www.grc.com/sqrl/phishing.htm https://www.grc.com/sqrl/phishing.htm
  - nly 12y ago
    It's there buried in the discussions somewhere. The basic (and old) idea is to shove the IP of the user (or spoof as the case may be), as seen by the web server, in to the QR code and then tie it to with the session token using a MAC. When the SQRL app passes the signed SQRL data back to the web server it passes this back as well. The server can then reverify the users IP (remember they're now using the app on another device). IP binding is worth doing but there's no way for the app to warn the user that the IP differs. You have to trust the server implementation of SQRL (which despite what Gibson claims, is actually fairly complex on the server-side) Other issues are discussed on the page you linked entitled "Details and Limitations of IP-based MITM detection"

kolodny 12y ago

I may be missing something but this seems highly susceptible to man in the middle attacks

davea37 12y ago
If the web page was served over HTTPS and provided the SSH server's fingerprint for the user to verify, wouldn't that get around the MITM risk?

skratlo 12y ago

This is brilliant. Here a full-fledged solution: the same way every OS supports users, it should support identities attached to the user account (~/.ssh). Upon OS installation / user creation, it would prompt the user to either generate new identity, or import existing one (from a flash drive, from a cloud, etc.). This would be the key pair. And the browser would automatically use this, without any terminal session or any such non-sense. Brilliant, right? No, because user accounts are commonly shared: here, can I check my mail on your computer? Yes, password won again :P

swadworth 12y ago
>Brilliant, right? No, because user accounts are commonly shared Gee, I guess only I can drive my car. If only there were some way to share my car with my spouse. Like having a second set of keys or something...

tux 12y ago

Very cool. This could be used to count linux users. Like http://linuxcounter.net/ http://linuxcounter.net/

nacs 12y ago
I remember that site from years ago but it seems awfully out of date at this point. Even the Ubuntu distro's opt-in share-my-desktop-stats system likely contains multiple times what Linux Counter is counting.

NietTim 12y ago

Never thought about it like this, this is pretty ingenious!

mkorfmann 12y ago
It's actually fairly simple, but not usable for 99% of web users.

jasonkester 12y ago

"SSH is near-universally loved among developers." Really? Which developers? SSH is one of those things you get forced to deal with a couple times a year for some irritating task, and it involves firing up Putty, figuring out where you left your key file, trying to remember how to actually load that key file, and a bunch of following steps on some website just to get connected to what you were trying to connect to. It is not something that I love. If you force me to use it just to log in to your website, I will decline to do so.

IgorPartola 12y ago
I think I found the Windows developer :). It is loved by pretty much everyone but Windows developers because it really is the best thing since sliced bread.
- bogdansolga 12y ago
  I'll second to that :)
- vbezhenar 12y ago
  Funny thing is that many windows developers and administrators like to use RDP, while *nix users generally don't like it at all (usually because RDP doesn't allow easy scripting to automate routine tasks).
vog 12y ago
Note that although PuTTY has a graphical user interface, it is hardly user friendly. Using the command-line ssh (with a decent shell) is much more comfortable.
- k__ 12y ago
  It's still a nice SSH client
gambiter 12y ago
Just the fact that you think SSH equates to Putty is laughable, and shows your ignorance. .NET and Java developers, at least the ones who seem to think anything non-Windows is bad, don't understand SSH. When you don't understand it, you don't see the value of using it, which means it doesn't get installed on your servers, and you are left thinking it's only an 'irritating task' kind of thing. I use SSH on a daily basis. Right now, from work, I have five SSH connections open, one is tunneling, one is tunneling and providing an interactive shell on one of my personal machines, one is connected to the live environment for server monitoring, and two are connected to the development environment. I'm running everything from applications, to the command line to my IDE (vim) all in SSH sessions. Just because you personally don't understand a key bit of internet technology doesn't mean it's the same for everyone else. There are those of us who see a valuable tool and use it properly.

neaanopri 12y ago

What does "PTY allocation request failed on channel 0" mean?

yock 12y ago
On the surface, it means SSH tried, and failed, to initiate an interactive session. In context, it means that either the developer has disabled new users, or this is simply broken at the moment.
duncankl 12y ago
When SSH clients first connect they ask the server for a pseudo terminal (PTY), to enable terminal colors, clearing the screen etc. In this case the SSH server declines that request because it simply wants to send back one line of text. The client falls back to text mode and works fine, but issues the warning anyway. You can suppress it with `ssh -T mars.vtllf.org` like I did in the demo video.

IgorPartola 12y ago

I am not sure about this. First, there is a built in MITM attack here. First time you connect to sshd, the server has no idea who you are. I suppose this could be mitigated by using HTTPS as the out-of-band channel for verifying client and server fingerprints. Second, ssh keys are somewhat limited. You can only have one public key for a private key. You cannot embed identity info in the public key. I would much rather see hog keys used for this. For developer types that should be just as easy. For real people the UI would still have to be developed but could actually include useful features, such as user identities.

icebraining 12y ago
First time you connect to sshd, the server has no idea who you are. That's not a problem if you signup by first connecting to the sshd and getting a custom signup URL.
- IgorPartola 12y ago
  How do you know that the sshd you connect to is authentic and not a MITM? More importantly, how does the sshd know that the incoming connection is you and not a MITM?
  - icebraining 12y ago
    How do you know that the sshd you connect to is authentic and not a MITM? You'd need the server fingerprint on the site (served over https, of course). More importantly, how does the sshd know that the incoming connection is you and not a MITM? But that's the point, there is no "you" to authenticate, since you're signing up for a new account. The sshd generates a token URL and then stores your fingerprint with that token. Then you can use that token to login to the actual site and fill in your information. If you're MITMing someone, the server shouldn't care, it's the client's job to make sure it's talking to the right server. See above.
swadworth 12y ago
>I am not sure about this. First, there is a built in MITM attack here. This always sounds like a NSA shill argument to me. Sure, you can MITM, but then, you HAVE to MITM on the very first request of every user to make that work. That's much more expensive than vacuuming up passwords server side with gag orders. >Second, ssh keys are somewhat limited... You cannot embed identity info in the public key. That's ridiculous. Who would want to? You are looking for an authorization solution. SSH is for authentication.

ddebernardy 12y ago

I'm suspicious that this is any better than TLS and client certificates. Plus, it's not entirely clear what's supposed to happen when your family and friends are using your computer, or when your laptop is simply stolen.

IgorPartola 12y ago
Surely you passphrase protect your id_rsa!
- mkorfmann 12y ago
  Back to entering passwords (or passphrases for that matter)... Yay!
  - swadworth 12y ago
    That's a retarded retort. In the SSH case you have ONE password to remember. Not one per website. Furthermore, the password never leaves your machine. Log in to a hundred websites with SSL and a password and the NSA comes along, collects all your passwords server side, knows which ones you reuse, knows your password generation patterns, everything. You are completely nuts if you think these two things are the same.
    - icebraining 12y ago
      You have a good point. You're also completely over-the-top aggressive for a discussion about website authentication.
      - swadworth 12y ago
        Sorry dad. You're right, it would be a real shame if the padded corners police came and modded down the intelligent posts. This site might just turn into a groupthink circlejerk if that happened :-/

fideloper 12y ago

Adding "-vvv" to the given SSH command, it looks like it uses the first SSH key given. I happen to have quite a few for various services. I suppose you could offer up one specifically by running ssh -o "IdentitiesOnly yes" -i ~/.ssh/id_whatever mars.vtllf.org (I use the IdentitiesOnly option because I often see ssh still offer other keys without it)

duncankl 12y ago
Thank you! I was looking for that option while writing the section on throwaway keys. I'll have to test it out.

deleted 12y ago

[deleted]

xnyhps 12y ago

So you have a situation where the client has already authenticated the server using TLS, and now the server wants to authenticate the client too. This solution wants to do that by setting up a new channel, authenticating the server /again/ and then also the client. Yeah, I don't think this is a good idea.

nly 12y ago

The only substantial advantage to this scheme is you get server id pinning for free (via your known_hosts file), but a combination of HTTP public key pinning[0] and client-side certificates will give you all the same advantages with far less user effort. [0] https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn...

deleted 12y ago
[deleted]
comex 12y ago
You get pinning... and absolutely no verification the first time you connect, so anyone who got lucky enough to MitM you the first time (or first time since you deleted your known_hosts file or reinstalled your operating system or switched computers) can log in as you, without having to compromise any PKI. Meh.

falcolas 12y ago

I love this idea, but I have some issues with their chart, particularly as related to authentication via email. A developer with a few minutes of thinking time could get around the "red" spots associated with email authentication, and fill in any missing dots pretty easily. And for better or worse, email is currently one of the better ways to create an identity for the masses, and it's also one of the few systems that your average user can justify the pain of setting up 2 factor auth on. The only thing better would be to use text messages, if you could come up with a way to lower the impedance for the user.

salzig 12y ago

use <keygen>[1] and generate a client side certificate for authentication? [1]: https://developer.mozilla.org/de/docs/Web/HTML/Element/keygen https://developer.mozilla.org/de/docs/Web/HTML/Element/keyge...

nacs 12y ago
English version of parent: https://developer.mozilla.org/en/docs/Web/HTML/Element/keygen https://developer.mozilla.org/en/docs/Web/HTML/Element/keyge...

eatonphil 12y ago

Would this become more usable if it was natively supported by the web browser? Couldn't the browser take care of generating the keys and whatnot?

swadworth 12y ago
<keygen> can generate client side keys. It's not very good, but it exists.

timtadh 12y ago

I want to thank the author for testing this out and doing an implementation. When Mozilla Persona came out I thought it would be cool to make an identity provider which support SSH based auth. I never had much time to work on it so seeing the various design problems was really great. I do think you can make some improvements when paired with a system such as persona but the fundamental challenge that SSH is not integrated into the web remains. Still, as programmer, I would love it if I could auth to github et. al with SSH keys. I would actually feel more secure doing that than with the password. Keep the 2 factor token either way. I completely agree with the author's assessment that this type of system would not work for the average web user.

duncankl 12y ago
Glad you liked it! I definitely echo the sentiment of wanting to use these sorts of power-user-only tools. But I think Moxie's recent post, They Live[1], does an excellent job of explaining why we shouldn't accept that the tools are too hard for everyone else, then just hoard them for our own use anyway. [1]: https://whispersystems.org/blog/they-live/ https://whispersystems.org/blog/they-live/
- jwise0 12y ago
  Adding on to the praise, I wanted to also comment -- thanks for doing an analysis of the results. Having implemented it was neat, but the honesty in revealing that what you've built is an interesting experiment, but not necessarily an improvement on the status quo, is commendable. There is still lots to be learned from the work you did -- both the technical and the analytical. I think this is probably the most striking example I've seen recently of "negative results are results, too". Thanks for the writeup.
ams6110 12y ago
as programmer, I would love it if I could auth to github et. al with SSH keys Um, you can?
- zymhan 12y ago

adamtj 12y ago

I love SSH, but I don't want to actually use SSH for this. That's not the important part. All I want is key-based authentication, and that doesn't need SSH. I want to be able to plug a security token into a USB port and be logged in, without even having to click a sign-in button. Reformat, reinstall, reboot, plug in security token, launch browser, type news.ycombinator.com and I'm already logged in.

stephenr 12y ago
I don't know if I'm missing something here, but it sounds like what you want is just SSL/TLS Client Certificates using PKSC#11 for the private key?
- e12e 12y ago
  Which is also usable for authenticating to ssh (but needs to set up as such certs are different from ssh key and from ssh "native" certs).
chubot 12y ago
You can do this with google products: https://support.google.com/accounts/answer/6103523?hl=en https://support.google.com/accounts/answer/6103523?hl=en You just have to touch the USB security token to have it release the key. I believe the idea is that malware can't really trick you into touching it, so it's more secure.
- Rafert 12y ago
  It's works a bit different than 'releasing a key': http://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-u2f-overview-ps-20141009.html#site-specific-public-private-key-pairs http://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido...

wampus 12y ago

The author makes a very good case for why this approach won't threaten password-based authentication, including: ...hard for first-time users to get right:... The private key being unlocked and available via ssh-agent. For this to be convenient for daily use, ssh-agent is essential, and that could expose naive users to compromise. I know enough to disable ForwardAgent in my personal config by default and generate site-specific keys for hosts I can't trust, but that's beyond most ordinary users and even many of the technical professionals I deal with. It's a shame PGP was the target of so much persecution when it came out. Maybe by now we would have worked out the key exchange problem and would all be enjoying personally encrypted communication on the Internet. I sometimes feel that any attempt to move beyond passwords without realizing that ideal is doomed to failure.

hamburglar 12y ago
I think one solution would be for the browser (or an extension) to expose an SSH agent API through the DOM, but gate access to that agent with local UI that confirms operations. "Facebook.com would like to view your public identity information. Continue?" with an "always allow for this site" option. "Facebook.com is requesting a signing challenge to verify your public identity. Allow?" etc. It could even include an identity manager which would allow you to generate different identities to present to different sites on the fly. You could have the option of having the requests pass through to your SSH_AGENT_SOCK (still gated by UI though) if you want, or you could just let the browser maintain its own independent agent (or potentially a combination).

rohansingh 12y ago

We use a philosophically similar solution at Spotify: https://github.com/spotify/crtauth https://github.com/spotify/crtauth The difference with crtauth is that you don't need an SSH server running in tandem, everything is handled by the crtauth library. Our main use case for this is for bots that need to access secure services. Protocol spec: https://github.com/spotify/crtauth/blob/master/PROTOCOL.md https://github.com/spotify/crtauth/blob/master/PROTOCOL.md

BrainInAJar 12y ago

Why not just use HTTP Signature Auth ? ( https://datatracker.ietf.org/doc/draft-cavage-http-signatures/ https://datatracker.ietf.org/doc/draft-cavage-http-signature... )

deleted 12y ago

[deleted]

patio11 12y ago

It is actually pretty useful to require SSH as a two-factor authentication method for internal services, particularly extraordinarily sensitive internal services which you'll expose solely to technical employees. I use it for exactly one purpose: authorizing the "ghosting" of a customer account. ("Log in as this user.") Putting that behind SSH means that anyone authorizing a ghosting has both a blessed SSH key and the password to it. Even rooting my session on our admin app, via reflected XSS or stealing my unlocked laptop out of my hands, doesn't get you that. (Our admin app, by design, is less-than-all-powerful. A malicious admin session could do a heck of a lot of damage to our business but, critically, would be unable to access personally identifying data about customers' clients.)

deleted 12y ago
[deleted]
nzealand 12y ago
You use vanilla ssh to authorize the ghost of a customer account?
- patio11 12y ago
  I'm not sure I understand the question. Here's what gets typed: ssh foo.example.com #uses private/public key per conf file *enter password* cd app ruby script/console irb > u = User.find_by_email "customer@example.net" irb > u.authorize_ghosting! "Reason for log goes here." * you'll want to incognito mode the URL returned here* irb > exit exit
  - cat9 12y ago
    With all due love and respect: This is something I would wrap a simple CLI around, and then kick myself in the tukhus for having ever used the language's interactive client to make raw database queries and edits on the production server.
    - tedunangst 12y ago

tedchs 12y ago

Why not use client-side SSL certificates in the browser?

hughes 12y ago

This question might be hilariously naive... but why don't web browsers make signed requests, just as web servers make signed responses? If I create an account on a website, then associate a public key with my account, shouldn't the browser be able to sign each request with my key? The website then wouldn't ever even have to deal with cookies or sessions as long as I was logged in to my browser. Or better yet, if my key is publicly known and trusted, couldn't a website know who I am before I even create an account? It could skip the signup process entirely.

NathanKP 12y ago
I'm sure that tracking services and ad companies would love signed requests.
- hughes 12y ago
  Well, it could maybe be an opt-in feature, like when a site requests to use your webcam or microphone. A small prompt that the server is requesting to access your identity or something.
gergles 12y ago
https://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-certificates/ https://pilif.github.io/2008/05/why-is-nobody-using-ssl-clie...
- duncankl 12y ago
  Thanks for the link! I added it to the article.
scott_karana 12y ago
This idea is exactly what I've always wanted, too. As others point out, it would definitely have to be opt-in, or it would be a great way to track. (It would be nice to have ephemeral keys per-site, too, a la Bitcoin: why have a publically unified identity?)

jrochkind1 12y ago

> You can see where this is heading—a half-baked reimplementation of TLS client authentication with all the same usability nightmares. Yeah, that's what I was thinking -- why would you do this instead of just using TLS client auth? TLS client auth is a usability nightmare -- but I'm not sure it's any _worse_ than what's in OP.

sparaker 12y ago

A beautiful simple implementation for signing into websites using SSH. I think this idea can be very helpful for developers, perhaps give them good scripts to hot reload a patch on production servers.

falsedan 12y ago

You don't need to edit a hidden config file to remove an old known_host entry, just run: ssh-keygen -R <host>

duncankl 12y ago
Thanks for the tip, I wasn't expecting that feature to be part of ssh-keygen.

vbezhenar 12y ago

That technique would useful when user wants to add public key into his github profile (or similar service). Instead of asking user to copy&paste his public key, site might ask him to enter `ssh github.com authtoken` in terminal.

stephenr 12y ago
So then you have two avenues for attack, if someone wants to inject their own public key into your account - the Web UI and some form of custom SSH server. Besides which you would need more than just "ssh github.com authtoken" - it doesn't identify who you are (thus knowing who to save the public key for)
- vbezhenar 12y ago
  > So then you have two avenues for attack, if someone wants to inject their own public key into your account - the Web UI and some form of custom SSH server. That's correct. SSH misses PKI and github can't sign their ssh public keys with trusted authority. If someone intercepting your traffic, he can redirect your connection to 22 port to malicious ssh server and save his malicious public key to github. To prevent that, github must present ssh fingerprint into their web page and user must check that fingerprint with one he can see on terminal. Thanks for clarification. > Besides which you would need more than just "ssh github.com authtoken" - it doesn't identify who you are (thus knowing who to save the public key for) authtoken is supposed to be an unique identifier and github server knows that it's associated with your account.
  - stephenr 12y ago
    > github must present ssh fingerprint into their web page and user must check that fingerprint yet another case where DNSSEC secured SSHFP records would automate this. However, given that people currently commit and push passwords, private keys and who knows what else to places like GitHub, it seems unlikely these people would recognise why a connection might refuse (e.g. because of an invalid fingerprint) anyway > authtoken is supposed to be an unique identifier and github server knows that it's associated with your account ah sorry I thought "authtoken" was meant to be some command to run on the server. Frankly I think things like adding a public key (whether to GitHub or a system that allows SSH logins) over the internet, are probably safer behind a double factor auth system (e.g. password + otp or client cert + otp) - the people who need to use it can be shown how to copy their public key quite easily (if they can't open Terminal.app, type "cat ~/.ssh/id_rsa.pub | pbcopy" and then paste the result into a web form, can they really handle Git, or even SSH for that matter?)