Comment by jamiesonbecker | Hacker News Reader

Comment by jamiesonbecker | Hacker News Reader

I'm the co-founder of a startup that has developed a tool for this called Userify[1].

It creates and removes local accounts and manages the ssh keys and sudo permissions centrally, so you don't have to worry about not being able to get in if your LDAP/AD is down. (Our Enterprise edition, self-hosted in your VPC or in your DC, can optionally integrate with LDAP or AD for dashboard logins, MFA, etc.) We also have an AWS server edition in the AWS marketplace. When you remove someone in the dashboard, their account is removed across all of the servers they have access to, and their sessions are terminated, but their home directory is retained for archival or forensics.

Our primary foci are paranoid levels of security (hardened, all data encrypted at rest with X25519, in motion with TLS), flexibility, and speed: fast to deploy or integrate (w/ ansible, chef, puppet, terraform, cloudformation), and fast to install (milliseconds), with both SaaS/Cloud and self-hosted versions and open source python agent (we call it the 'shim').

We were founded in 2011 and serve thousands of servers and users in real time; I'm first.last at userify for any questions, and/or info at userify.

1. https://userify.com

  > paranoid levels of security

  > # paste this into your terminal
  > # and get started in seconds..
  > curl -# https://usrfy.io/signup | sudo -sE

:O

This brings up a more complex debate.

In order to be effective, signatures have to come from a root of trust. Where are you forming a trust basis for a signature in the curl? The GPG sigs built into your package manager are signed by the packager and form a cascading tree of trust, and the TLS certifcate authority system is also supposed to form a foundation for trust. (Sigs are on the file, but where do you get the packager's first signature in this place? curl from https piped into sudo doesn't decrease the CA trust model and a sig on the file as well doesn't add anything, since the sig would be easily replaced by anyone with the wherewithal to mod the original file.

Instead, that sig would be security theater, much like an EV-TLS cert. (Not that security theater can't still be valuable from a marketing perspective from people who think that checking sigs on an https site is still valuable.)

While there can be security value in sigs, it doesn't come into play in these circumstances without starting from a position of a signed sig from somewhere, and ultimately the smart and paranoid will still curl to a file and actually read the script. Actually, ultimately, if you are in a security sensitive situation, you are probably not in the cloud at all, or on dedicated instances, and then you should avoid SaaS and cloud software altogether and look at an on-premise solution like Userify Express/AWS/Enterprise, as then you will have that crucial foundation of trust in your initial purchase and you can tightly control that environment.

LDAP with caching using SSSD is a better solution. I just implemented it to replace using a configuration management tool. I use the configuration management tool to setup the LDAP server, and LDAP for authentication. But would take the configuration management tool over your toool. Your tool is too niche.

Fox pass has a nice hosted ldap solution which includes ssh key management.

I thought about doing something like this in the past, did you find this to be relatively profitable? Was it something that a lot of people wanted?

No, it's a terrible space. Pick something less noisy and with fewer competitors. Like log management. ;)

> their account is removed

Are you actually removing the unix account? How do you manage uids? How do you prevent reuse? How about over NFS?

Excellent question.. yes, we actually remove the account and pkill any existing sessions owned by the user. The OS might reuse UID's if it wishes. This will cleanly work over NFS as well. (On the server side as well, as long as the NFS server respects POSIX file locking semantics.) The agent (shim) is only a few hundred lines of readable Python that just scripts standard Linux commands, so it plays nicely with other tools -- even other logging or user management tools, PAM modules, etc. Also, the shim won't touch any user accounts that it didn't create (tagged in the comment field), so existing system or backup accounts are safe and won't ever be touched.

Here's the source code: https://github.com/userify/shim/blob/master/shim.py#L161

> The OS might reuse UID's if it wishes.

If the software doesn't manage UIDs internally then this is a recipe for disaster because keeping UIDs in sync is a PITA. It's a waste of time to do manually, but an even bigger waste of time to have to fight with the OS to get it right. If you're using NFS then you're screwed.

Usernames are one-for-one correlations with UID, so just don't allow users to personally owning files outside of their /home (they shouldn't according to FHS/LSB/POSIX/etc).

Can it verify or enforce that ssh secret keys are password protected?

This wouldn't be possible unless we generated or held the private keys. You cannot tell if the key is password protected from the public key alone.

Reply on news.ycombinator.com