Hacker News Reader

Comment by patio11 | Hacker News Reader

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

View on HN

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

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.

'find_by_email' is what counts as a raw database query these days? I feel so old.

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

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

I'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.

What sort of validation? Either you provide a valid email address that exists and it works, or not.

I suppose when the args are both allowed to be arbitrary strings, the validation is already done, and the escaping is done by AR, so you can safely pass them unmolested. It just triggers my safety reflex to send ARGV elements on to the next layer without doing something to them.

My previous company had "read-only" credentials to production.

...however, this is obviously not an operation you could do with readonly access.

I was responding to this:

> DB queries, even through the ORM, is basically considered a raw database query, and is strictly forbidden

You can run raw DB queries against read-only credentials.

Ah, yes, that obviously should have been qualified as DB writes.

Reply on news.ycombinator.com