Live data from Hacker News

Signing in to websites with SSH

vtllf.org

91–100 of 169 posts

Re: Signing in to websites with SSH

#91
post #15

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 awarenes…

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

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

Re: Signing in to websites with SSH

#92
post #73

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.

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?

Re: Signing in to websites with SSH

#93

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 rathe…

>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 ridicul…

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.

Re: Signing in to websites with SSH

#94
post #88

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 th…

[deleted]

Re: Signing in to websites with SSH

#95

Earlier quoted context omitted.

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.

Yet again, there is already a mechanism for this. Add your fingerprints to DNS (they can be obtained using ssh-keygen -r ) Set the SSH option VerifyHostKeyDNS to "yes" (or "ask" if you want to confirm, with a notice about if the DNS entry matches).

That's not a secure option without DNSSEC. Given that we're unlikely to see significant DNSSEC adoption, serving the fingerprint over HTTPS (or another option altogether) would be preferable.

Re: Signing in to websites with SSH

#96
post #95

Earlier quoted context omitted.

Yet again, there is already a mechanism for this. Add your fingerprints to DNS (they can be obtained using ssh-keygen -r ) Set the SSH option VerifyHostKeyDNS to "yes" (or "ask" if you want to confirm, with a notice about if the DNS entry matches).

That's not a secure option without DNSSEC. Given that we're unlikely to see significant DNSSEC adoption, serving the fingerprint over HTTPS (or another option altogether) would be preferable.

So use DNSSEC for SSHFP lookups. The Debian package for example (openssh-client) added support for DNSSEC in its lookups, almost 5 years ago (April 2010)

Re: Signing in to websites with SSH

#97
post #91

Earlier quoted context omitted.

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

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

Probably because the analogy breaks down so fast.

"And to prove he sent the package, he locks it with his key and then you use your copy of his lock to open it so that you know it's from him!"

It's a useful analogy for one specific use of public/private keys. But it doesn't capture the full spirit, which may lead to more confusion than just using no analogy.

Re: Signing in to websites with SSH

#98
post #5

I like alternative two, except that I'd have it be ssh @ 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 no…

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.

Re: Signing in to websites with SSH

#99

"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…

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 bas…

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.

Re: Signing in to websites with SSH

#100
post #73

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.

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.

Post reply on HN