4 ms·
It is actually pretty useful to require SSH as a two-factor authentication method for internal services, particularly extraordinarily sensitive internal service
by 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 agoYou use vanilla ssh to authorize the ghost of a customer account?
- patio11 12y agoI'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 agoWith 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'find_by_email' is what counts as a raw database query these days? I feel so old.
- hamburglar 12y agoAt my company, using an interactive shell on prod to invoke DB queries, even through the ORM, is basically considered a raw database query, and is strictly forbidden. It's untested code coming straight from your fallible fingers and manipulating the prod database. I don't see why this should be treated as any different than a raw db query. You can do some pretty powerfully destructive stuff with an ORM.
- tedunangst 12y agoIf there's anything destructive about that interactive session, it's likely to be the 'authorize_ghosting!' call. Somehow, I find it hard to believe sticking it in a one line script would make it less destructive, but let's see. User.find_by_email(ARGV[0]).authorize_ghosting!(ARGV[1]) Oh, yes, so much better. patio11 should totally switch to using this. And then pay me my $1000 consulting fee.
- hamburglar 12y agoI'm going to go out on a limb and suggest that it shouldn't just be turned into a one-liner that shoves ARGV elements directly at the database, but should actually do some validation of input. Even your one-liner is safer than raw irb since you can't make a typo and call the wrong method, but if you add validation, then yes, I think it's much, much less destructive.
- deleted 12y ago[deleted]
- tlrobinson 12y agoWhat sort of validation? Either you provide a valid email address that exists and it works, or not.