111–120 of 169 posts
What does "PTY allocation request failed on channel 0" mean?
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…
You use vanilla ssh to authorize the ghost of a customer account?
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
exitI 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…
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.
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.
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…
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.
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 integ…
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.
Earlier quoted context omitted.
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.
If you're writing for a lay audience that doesn't care about things like modular arithmetic, there's no reason to conflate the two operations. Just say encryption is like keys and locks, and signing is like... well... a signature.
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 k…
https://pilif.github.io/2008/05/why-is-nobody-using-ssl-clie...
Earlier quoted context omitted.
You use vanilla ssh to authorize the ghost of a customer account?
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
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.
Earlier quoted context omitted.
>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.
Of course I can MITM something without CAs if you're on public wifi, provided I intercept the very first connection, so it's a valid question for defending againt less sophisticated attackers.