Dear Lazyweb - Please help me keep passwords synchronised!
Dear LazyWeb... I'm in a password mess... please help.
I currently have a (relatively) large number of passwords for myself - for example :
- There are 4 internal Linux boxes at work - each with a unique 'david' user
- There are another 6 external Linux boxes of some shape or another, again with either a 'david' or 'palepurple' user.
- And then there are boxes I support for customers, which tend to rely on SSH public keys.
When adding / removing a member of staff, I currently have around 6 different hoops to jump through. This is a pain.
So, the other I thought I'd try and make my own life easier, by finally changing to use a new common password (thanks to pwgen) - I thought it would be better if I had one password that was updated more often than a number of distinct passwords on seperate boxes, which I'm less likely to change - as I have a crap-ish memory. [Yes, this may be flawed logic, as it's an all-or-nothing approach]
Although I do already use SSH public keys, I also still allow for normal password login via SSH (sometimes I'm away from home, and I've not gotten into the habit of carrying around a usb stick with a ssh public/private key on it) and some customers/users probably can't be converted anyway.
So, should I ....
- Stop using/relying on 'passwords' and move over to using SSH public/private keys 'properly' (although these don't help a lot if I ever need to sudo, or for logging in via gdm).
- Use some wonderful technology that can synchronise my passwords (is LDAP + replication with loads of computers being the 'slaves' the answer here?)
- .... <insert your suggestion in comments> ...
Thank you in advance for any helpful comments....
Technorati Tags:
I was going to suggest LDAP, but...
I was going to suggest LDAP, but this will be really tricky if the machines are on separate networks. LDAP-integration is, IMO, most reliable when you have your LDAP server on the same subnet as the servers it serves. This is because LDAP integration also integrates UIDs, GIDs and so on, in addition to passwords for authentication. I suppose you *could* try using LDAP slaves on the remote networks, but that might take a bit of effort to get working.
Perhaps try LDAP on your local machines first, then try extending it?
ldap is what i keep thinking of too...
LDAP :
1. It seems non-trivial to setup
2. If I don't use many slaves, then everything will break once one machine breaks/goes offline etc
3. I've seen many LDAP servers stuck/broken, due to their reliance on Berkley DB
Perhaps my issue is that I have two problems :
1. Password synchronisation across internal/development machines - which LDAP could probably fix
and
2. Password synchronisation between external servers - which could be dealt with by SSH public keys.
This a subject I keep
This a subject I keep whirling around every now and again. This is also part of the reason I decided to investigate Kerberos, LDAP and such like. On Windows, you have Active Directory and Domains, on Linux we have NIS, Kerberos and LDAP and have to decided what and how. I've not yet come a cross a model which seems suitable or described in enough detail for me to mimic, but I haven't searched very hard.
I, like you, would like a single set of users with synchronised uids/gids across machines, network mountable home directories, with auth information sent in an encrypted form and ideally be able to able to push configuration changes network wide, like resolv.conf, hosts files etc. Something like encrypted NIS backed by Kerberos and/or backed by LDAP. Perhaps I'm being naive, which I am on this subject. It would be nice to make it easy to pull users off a network of machines quickly.
As a quick fix, it might be worth using SSH public keys for remote logins, a single password for your david accounts on local machines and synchronise the uids across them. Don't know enough about LDAP, does it do encrypted transfer of logins credentials? Kerberos 5 does and this is why I've been playing with it, thats good enough for me to use in our server room, but I don't know if it is strong enough to survive travelling across the wild, wild Internet without a VPN or something.
I'll be watching this thread with intent.
LDAP can be tunnelled over SSL
If it helps, I know there is an ldaps protocol, which is LDAP over SSL.
I agree - being able to 'pull' people off machines easily would be a nice feature :-) and being able to easily administer them from a web interface would also be quite useful.
I've used NIS in the past, but obviously it's not very secure. I thought NIS+ fixed most of NISs problems, but also heard it was a PITA to configure/setup/get working..... hence I've always avoided it.
No doubt for our office, I could probably use NIS... but most office users also have accounts on external boxes (e.g. subversion access (http auth), ssh access (external servers) etc) so NIS wouldn't 'cut it' for this really.
LDAPS and Encryption
Yes, you can secure LDAP communication with OpenSSL (which becomes LDAPS) and that's usually strong enough encryption to survive in the wild. As for Kerberos5; ditto - haven't heard any horror stories about people getting h4xx0r3d because they ran that over the Wild Wild Web ;) However, under both models it's fairly "normal" to have a master server hiding somewhere in your infrastructure and slaves in each physical site - hosts in each site should query their local server, so its only server <-> server transmissions in the wild really...
If you're /really/ paranoid and running with a master+slaves architecture, setup encrypted GRE tunnels between the sites, or perhaps use a stunnel between the master <-> slaves and pipe everything over that in addition to the TLS/SSL encryption?
OpenID?
Is there any work to integrate OpenID into system level auth systems?
Other than that there is the usual, Kerberos, LDAP, NIS options....
Alex added the following in Facebook
My advice would be to avoid LDAP in your case; slaves not being able to synchronize with a master can be a right pain in the arse. Should DNS break down and your boxes be unable to resolve their 'local' LDAP server logins are going to be totally stuffed.
There's 5-6 little things which make life hell with LDAP, so unless you've got a *big* infrastructure and want 'Single Sign On' across a whole bunch of stuff (ie: Apache can use LDAP to authenticate, as can PHP applications) then I'd go with #1 :) Save you sanity.
... more in the next comment, Facearse doesn't allow big comments!
Message - Delete
Alex Howells (Leeds) wrote
at 3:50pm
As an aside, if you wish to maintain logins across multiple boxes and be able to 'easily' remove staff - take a peek at either Puppet (recommended) or CFengine (bit of an arse).... Maintain a master list of staff (inc. hashes) on one of your boxes -- every $period something like Puppet can check /etc/passwd, /etc/group and /etc/shadow on all your boxes. It can add staff who should be there and remove staff who should no longer have access. :)
Beware: do not just distribute /etc/passwd and /etc/shadow files, different distributions require different users/groups for services with specific uid/gids and this sometimes even changes between versions of ;) I found this one out the hard way and it wasn't at all pretty!
Copying over from Facebook
My advice would be to avoid LDAP in your case; slaves not being able to synchronize with a master can be a right pain in the arse. Should DNS break down and your boxes be unable to resolve their 'local' LDAP server logins are going to be totally stuffed.
(Addition: So yes, machines which don't have 24x7 internet access are probably a bad idea to LDAP!)
There's 5-6 little things which make life hell with LDAP, so unless you've got a *big* infrastructure and want 'Single Sign On' across a whole bunch of stuff (ie: Apache can use LDAP to authenticate, as can PHP applications) then I'd go with #1 :) Save your sanity.
As an aside, if you wish to maintain logins across multiple boxes and be able to 'easily' remove staff - take a peek at either Puppet (recommended) or CFengine (bit of an arse).... Maintain a master list of staff (inc. hashes) on one of your boxes -- every $period something like Puppet can check /etc/passwd, /etc/group and /etc/shadow on all your boxes. It can add staff who should be there and remove staff who should no longer have access. :) Just needs to tweak (add/remove/edit) the one line for each user.
Beware: do not just distribute /etc/passwd and /etc/shadow files, different distributions require different users/groups for services with specific uid/gids and this sometimes even changes between versions of ;) I found this one out the hard way and it wasn't at all pretty!
puppet ...
Can be found : http://reductivelabs.com/trac/puppet
A quick browse of it's website indicates that it could probably do what i want - i.e. keep things in synchronisation.... so it's something to consider.
Another option:
Another option: http://directory.fedoraproject.org/
I looked at it a while ago but it asked me too many questions while I was setting it up that I didn't know the answer to. There are VMWare images floating around somewhere.
Puppet does sound interesting.
FDS
It's important to note that FDS is just a more-nicely packaged LDAP solution...
Post new comment