Hacker News Reader

Comment by jpgvm | Hacker News Reader

Single point of compromise. :(

I wish people would just stop with these things. The appropriate way to be able to manage many users is called LDAP, it's been LDAP for decades and it's unlikely to change.

These days it's super easy to use SSH keys with LDAP, still using the standard openssh-lpk schema but now not requiring any patches to OpenSSH itself, just need to use the AuthorizedKeysCommand and an appropriate helper (which normally ships with distro).

By forgoing the above gateway style thing you now have central key management without a single point of compromise. Revoking a key is as simple as deleting it from LDAP or disabling that users account.

View on HN

"These days it's super easy to use SSH keys with LDAP"

Are there any articles that go in to detail on exactly how to do this?

Digital Ocean has a ton of systems management guides aimed at developers first, but they're pretty reasonable for small scale setups and when you have no clue where to start. https://www.digitalocean.com/community/tutorials/how-to-auth...

FreeIPA has provided this for a while:

https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_...

More recently the AuthorizedKeysCommand patch has made it's way into Ubuntu's sshd, similarly allowing sshd to call script that looks up a user's authorized keys from LDAP.

More correctly AuthorizedKeysCommand is in mainline OpenSSH, thus every recent release of all major distros have it.

This is a great perl script that makes for an easy AuthorizedKeysCommand [1]. SSH with LDAP is definitely an easier way to distribute keys and manage permissions than logging into each box. It's also a single point of failure in a way, but you can at least keep it completely inside a private network, and LDAP is well-known and easy to secure.

1. https://github.com/AndriiGrytsenko/openssh-ldap-publickey

The IPA in FreeIPA stands for "Identity, Policy, and Audit". Yet on the Roadmap page (http://www.freeipa.org/page/Roadmap), enjoy this statement:

"The audit component of the project will remain deferred until further notice. You can see the reasoning in the About page."

Therefore, for enterprise purposes, I can't see why anyone would take FreeIPA seriously.

Some people use Kerberos instead of LDAP but there's far less people that have actually rolled out a Kerberos implementation that's not related to Active Directory than LDAP. Either way, LDAP and/or Kerberos are just re-inventing wheels that have not a whole lot of value in re-inventing / "innovating" partly because disparate identity and authorization management systems are an immense pain to deal with scaling beyond a small to medium size company and everyone would rather use what's well known first before they think they're smart enough to roll their own. This is pretty typical with developers versus systems management folks though culturally though I'd gather. It just pisses me off when I have to fix something some smartass thought "simpler = better" meant that he should roll his own thing instead of learning how people do it first and THEN rolling his own.

Kerberos is also acceptable, it is however much more complicated than LDAP for the average sysadmin to understand.

You also need to teach your users how to get kerberos tickets and setup keytab etc. Chances are if you are using kerberos you also have LDAP however.

The thing about kerberized ssh that I've wondered, do you really want your kerberos session to open up ssh access to all the boxes in the enterprise you have an account on?

I'm not quite sure what you mean with this concern but Kerberos is really flexible and a Kerberos realm could act a lot more like roles than by domains (which is the typical correlation). Most enterprise networks I've worked with are extremely fragmented from decades of competing business units rolling their own thing and so the default in most enterprise networks is already quite restricted in many respects, and that is ironically a bit of a help for security by reducing the impact crater of an intrusion. Also, we have plenty of different accounts used by one physical user all the time, so nothing keeps administrators from requiring different accounts for different roles on top of realms. I don't necessarily mean that you need to create user1.support and user1.dev in the same domain but Kerberos solves a lot of problems that ssh alone just doesn't answer, which is a big reason why I reach for that after I have an ok ssh setup.

Nothing says you can't put resources in multiple Kerberos realms either. Then you can establish a digraph of trust chains across Kerberos realms to transfer tickets across realms based upon some business rules.

There's many reasons that Active Directory (LDAP + Kerberos + some magical bits of quirks and features) is the gold standard for large corporations and the reason is not "nobody got fired for buying Microsoft."

The thing about keybox is that it's nice and fast to get better. For someone that doesn't have an ops team, or even an ops person, it is a neat solution.

Yes you need to be careful with it, I ran it on an internal VM, with only 2 users who had access to the admin console.

I'd love to see something as simple to use as keybox based around LDAP, I've had a google and can't see anything.

If you're a very small operation, using a configuration management tool to provision users with SSH keys is pretty simple.

IIRC the ”original” SSH server (from SSH Communications Security Oyj) can handle key management. Is there anyone who has tried it and want to share their experiences?

Reply on news.ycombinator.com