Signing in to websites with SSH

by blfr • 11 years ago

382 161 11 years ago

justinsb• 11 years 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• 11 years ago

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

wazari972• 11 years 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• 11 years 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• 11 years 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• 11 years 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.

duncankl6• 11 years 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• 11 years 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 ) 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• 11 years 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• 11 years ago

What I thought, exactly.

brutos• 11 years 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

icebraining5• 11 years ago

But how is this solution any better?

derefr• 11 years 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.)

nodata• 11 years ago

Because client certificates have been around for donkeys years and almost nobody uses them. Even technical people!

But technical people do use ssh keys.

IgorPartola6• 11 years ago

Feels like the case for that XKCD about standards.

stephenr15• 11 years ago

Even technical people can make stupid mistakes. Look at MongoDB and it's legion of fans.

xtracto• 11 years ago

We use client certs in the company where I work to authenticate into all internal pages. Once the infrastructure was in place (an easy way to generate a certificate to any new colleague) it has been a breeze to setup and use.

Server side, it is 3 or 4 Nginx lines. Client side, people only have to get the cert, click it to open, and install it on Chrome. After that, they are happy they don't have to remember any password for our different services.

I think we could implement it for our users if we gave the option to "login using cert" and "send me a new cert" (to the email they used for signin). People need minimal training but they don't have to be computer literate to do it (half of our company are not, and they found it better than passwords once the system was in place).

scott_s2• 11 years ago

Yes, the author clearly has, because he talks about it in his conclusions. The exercise, then, is one of re-discovering why things are the way they are.

prateek_mir• 11 years 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• 11 years 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.

icebraining5• 11 years 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• 11 years ago

I have an SSH key and use it routinely. I've never used SSL client certs.

geocar• 11 years 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

stephenr15• 11 years 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.

nothrabannosir2• 11 years ago

And please, please, please add the fingerprint to that:

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.

stephenr15• 11 years 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).

ams61102• 11 years 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• 11 years 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• 11 years 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• 11 years 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• 11 years 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_s2• 11 years ago

If you read to the end, you'll discover the author comes to the same conclusion.

swadworth6• 11 years ago

Yet, if you call a public key/private key a lock/key respectively, then a lot more people would immediately get the concept.

"You send him a copy of your lock which he uses to lock a package and return it to you. Then only your key can open it!"

You immediately fix the problem of people sending their key, because people know keys are important and shouldn't be handed out to just anyone.

The PKI people are brilliant. Their communication skills, not so much.

aikinai• 11 years ago

I've always wondered why we couldn't just call public keys locks. That would avoid so much confusion for first-time users.

jamiesonbecker• 11 years ago

I've seen this too. I've literally had (otherwise very smart!) people email me their PPK files (Putty Private Keys)! (Userify does help a lot with this now, however.)

jerinaw• 11 years ago

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

Sarien4• 11 years 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.

nly4• 11 years 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• 11 years 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

Sarien4• 11 years ago

@nly How does this system prevent me from setting up a website that looks like Paypal and giving you the address of my ssh server?

kolodny• 11 years ago

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

davea37• 11 years 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• 11 years 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

swadworth6• 11 years 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• 11 years ago

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

nacs2• 11 years 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• 11 years ago

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

mkorfmann2• 11 years ago

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

jasonkester• 11 years 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.

IgorPartola6• 11 years 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• 11 years ago

I'll second to that :)

vbezhenar3• 11 years 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• 11 years 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__• 11 years ago

It's still a nice SSH client

gambiter• 11 years 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.

peeters2• 11 years ago

I'm sensing a bit of ignorance or at least unrelated aggression toward .NET and Java developers. I'd actually say that ignorance of SSH is more related to application vs server developers, and since Java is one of the most popular server platforms, it seems unfounded to even bring up Java developers in your diatribe.

ubertaco• 11 years ago

Yeah, the Windows-based alternatives (RDP, VNC, or even shudder something like GoToMyPC) are waaay better for quick dead-simple system administration. /s

SSH works great for systems that didn't have to have networked multi-user support hacked in later in their lifecycle. Systems that let you actually get stuff done without having to paint a whole GUI environment to do it.

I can automate running "git pull && mvn clean package && deploy-tool-of-choice" across N servers. I can't really automate "Okay, wait for the GUI to paint and then be sent across the wire, then click Start, then click on the GUI Git tool start menu entry, wait for it to load, then click the 'sync' button, then wait for it to finish, then open a GUI(!) command prompt (in my GUI environment!) and cd to the right directory, then type 'mvn clean package' and wait for it to finish, then click Start, then click on the deploy tool start menu entry, then wait for it to load, then click 'deploy'".

The fact that there are a number of tools that try to hack that sort of behavior in by emulating pixel-scrapeable virtual displays and mice/keyboards is a testament to how shoddy the alternative to SSH is.

Gurkenmaster• 11 years ago

It's possible to forward an X server over ssh via putty to Xming on Windows.

neaanopri• 11 years ago

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

yock• 11 years 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.

duncankl6• 11 years 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.

IgorPartola6• 11 years 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.

icebraining5• 11 years 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.

IgorPartola6• 11 years 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?

swadworth6• 11 years 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.

IgorPartola6• 11 years ago

MITM is a real threat, not some theoretical thing. Dismissing it is sort of the definition of an NSA shill. Sorry, but you are wrong.

ddebernardy• 11 years 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.

IgorPartola6• 11 years ago

Surely you passphrase protect your id_rsa!

mkorfmann2• 11 years ago

Back to entering passwords (or passphrases for that matter)... Yay!

fideloper• 11 years 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)

duncankl6• 11 years ago

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

xnyhps• 11 years 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.

nly4• 11 years 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_Pinn...

comex• 11 years 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• 11 years 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• 11 years ago

use <keygen>[1] and generate a client side certificate for authentication?

[1] https://developer.mozilla.org/de/docs/Web/HTML/Element/keyge...

nacs2• 11 years ago

English version of parent: https://developer.mozilla.org/en/docs/Web/HTML/Element/keyge...

eatonphil• 11 years 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?

swadworth6• 11 years ago

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

timtadh• 11 years 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.

duncankl6• 11 years 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/

jwise0• 11 years 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.

ams61102• 11 years ago

as programmer, I would love it if I could auth to github et. al with SSH keys

Um, you can?

zymhan• 11 years ago

Maybe they mean logging into the web portal by authentication with an SSH key?

adamtj• 11 years 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.

stephenr15• 11 years 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?

e12e2• 11 years 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• 11 years ago

You can do this with google products:

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• 11 years ago

It's works a bit different than 'releasing a key': http://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido...

wampus• 11 years 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.

hamburglar6• 11 years 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• 11 years ago

We use a philosophically similar solution at Spotify: 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

BrainInAJar• 11 years ago

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

patio112• 11 years 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.)

nzealand• 11 years ago

You use vanilla ssh to authorize the ghost of a customer account?

patio112• 11 years 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

tedchs• 11 years ago

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

hughes2• 11 years 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• 11 years ago

I'm sure that tracking services and ad companies would love signed requests.

hughes2• 11 years 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• 11 years ago

https://pilif.github.io/2008/05/why-is-nobody-using-ssl-clie...

duncankl6• 11 years ago

Thanks for the link! I added it to the article.

scott_karana• 11 years 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?)

tomjen3• 11 years ago

That features has been in substantially every browser for years, I am pretty sure IE 5 had it.

The problem is that the UI for client side certificates is of-putting, inconsistent and terrible in every single browser (also people expect to be able to use your web service from more than one computer).

vertex-four• 11 years ago

but why don't web browsers make signed requests, just as web servers make signed responses?

They can. The WebID people at the W3C are trying to make a standard out of this, that would allow for federated authentication in which you can securely share data with websites you visit. (They're not getting terribly far - huge portions of the stack are missing around the subject of "tell a server you own that another server can access <these bits of data>, where the other server is identified using a WebID".)

The downsides? Basically, the UI sucks and is inconsistent between browsers, up to and including failing to let you log out or have multiple accounts on a website.

e12e2• 11 years ago

You can use client side (x509) certs for auth over ssl/tls (and also for ssh - in theory at least. I've never tried that). Cacert.org uses client certs for authentication in the web app/page for generating certs for example. I believe the rest of the session is handled similarly to regular ssl/tls (in essence negotiating a shared secret to use as a session key for symmetric encryption, along with some kind of signature to build an authenticated cipher -- if a symmetric authenticated cipher can't be negotiated).

My bank used x509 certs for a while -- but in the end it proved too hard both on users/support and on developers (catering to all browsers - as cert management has to be integrated in the browser ui/chrome -- and so is different for every browser).

Another thing people seem to miss here is tha ssh also has its own cert scheme. So you could advertise a server cert in dns - and the client would only need to trust the CA cert (a single cert for an entire organizations ssh servers).

jrochkind1• 11 years 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• 11 years 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• 11 years ago

You don't need to edit a hidden config file to remove an old known_host entry, just run:

  ssh-keygen -R <host>

duncankl6• 11 years ago

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

vbezhenar3• 11 years 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.

stephenr15• 11 years 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)

vbezhenar3• 11 years 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.

Signing in to websites with SSH

Related Stories