4 ms·

> and if you have multiple admins, if they don't each get their own account You really should have your own account on each machine. Deploy them via some push

> and if you have multiple admins, if they don't each get their own account You really should have your own account on each machine. Deploy them via some push method like ansible, or some pull method like a daily cronjob. You can push a .vimrc out with them too.

kbenson 8y ago
You state that as if it's a given, but I find that any increase in deployment complexity should be carefully considered. Rarely have I found "we can do this, so let's do it." a useful strategy in the end. As a very simple example of one of one possible downside of multiple accounts, consider an admin team with a high level of account additions and/or deletions (this does not mean quick turnover, it's also easily achieved through a large enough team). How robust are your routines for removing accounts when unused? How easy is it to check that every server is in a clean state? How much does it complicate and reporting of accounts on servers that have shells assigned to them or allow login? Simplicity has it's own benefits. Sometimes additional features are well worth the complexity cost, other times they are not. This is basically the same theme I initially stated with regard to Vim customization itself. Another way to look at it is as the Waterbed Theory of Complexity.[1] 1: https://en.wikipedia.org/wiki/Waterbed_theory https://en.wikipedia.org/wiki/Waterbed_theory
- isostatic 8y ago
  > How robust are your routines for removing accounts when unused? For our main corporate server list (about 1000 servers and 50 users), disable account in ldap and password authentication no longer works (so they lose sudo). Takes about 5 minutes to replicate I believe. If they have a .ssh key they can still log on until the local account is disabled, which runs daily. The 100 or so servers outside the corporate walled garden, with 10 users, simply have to wait for a day for the account to be disabled - or run a bash script from rundeck to kick it off earlier. The CRL cache-time on their client certs is longer than that in any case so it's not top priority. I last did this 3 weeks ago. We didn't want central authentication for non-walled-garden machines as there's a good chance many of them may be used offline, both via ssh and local access. It's far easier and less error prone than having to change credentials and authorized_keys for generic accounts everytime someone leaves. You've also got the benefit of knowing who's logging in to each server, as I assume your auth.log is also fired off to syslog. How do you prevent an ex-employee logging in without a generic account, other than changing credentials and authorized keys? I'm assuming it was a mutual termination and you don't need to worry about backdoors (because if you do, you're screwed regardless) But forget nefarious purposes -- if you have a problem on a machine and you see that "admin" was logged on at the time the problem started, how do you know who "admin" was so you can work on the fix?
  - kbenson 8y ago
    > It's far easier and less error prone than having to change credentials and authorized_keys for generic accounts everytime someone leaves. You've also got the benefit of knowing who's logging in to each server, as I assume your auth.log is also fired off to syslog. I can write a system (and have, multiple times) that takes public keys from people in a file named by their users, aggregates them into a single authorized_keys file, and pushes it to the admin account on all the servers in a list in 5-10 minutes. Access removal is removal of their key and running a command that uses scp to upload a new authorized_key file for all servers. Using xargs and parallel jobs, than can complete within a minute or two even for 1000+ servers, errors are easily visible, any problem in the process is easily troubleshot, and if worse comes to worse and the system isn't functioning, you can manually update the authorized_keys on a few servers that need it ASAP. No LDAP config, requires, and anyone with basic SSH understanding can diagnose and understand what's required to fix an error within a minute or two. Give me another 30-60 minutes and it would support a config file with user groups and assigning group or individual access to servers. There are features you don't get with that, but it's dead simple and very robust. LDAP is good, but if all you need is to set up admin access to Linux/BSD servers, it also might be overkill and cause the occasional headache. There's a huge range between manually configuring every server for every change and using LDAP for account access. > But forget nefarious purposes -- if you have a problem on a machine and you see that "admin" was logged on at the time the problem started, how do you know who "admin" was so you can work on the fix? SSH allows environment vars to be passed along with the authorized key file. You can set your default EDITOR for example, but your push system can also append a specific variable that denotes who the actual user was that connected, and your login config can log it to a file as you connect. There are simple solutions for most things you would want in this space. Once there isn't a simple solution, then maybe the value of a centralized authorization system might show itself.
    - isostatic 8y ago
      > I can write a system (and have, multiple times) that takes public keys from people in a file named by their users, aggregates them into a single authorized_keys file, and pushes it to the admin account on all the servers in a list in 5-10 minutes. The modern way to do such a thing would be using ansible, which just as easily allows you to create/delete user accounts. While custom vim settings per user are nice to haves, the biggest benefit is AAA. I'm not sure what type of auditing you can realistically do with, you'd have to trace through machine logs to find the IP of origin for a given pts, and hope that the dhcp server still has.

kbenson 8y ago

You state that as if it's a given, but I find that any increase in deployment complexity should be carefully considered. Rarely have I found "we can do this, so let's do it." a useful strategy in the end. As a very simple example of one of one possible downside of multiple accounts, consider an admin team with a high level of account additions and/or deletions (this does not mean quick turnover, it's also easily achieved through a large enough team). How robust are your routines for removing accounts when unused? How easy is it to check that every server is in a clean state? How much does it complicate and reporting of accounts on servers that have shells assigned to them or allow login? Simplicity has it's own benefits. Sometimes additional features are well worth the complexity cost, other times they are not. This is basically the same theme I initially stated with regard to Vim customization itself. Another way to look at it is as the Waterbed Theory of Complexity.[1] 1: https://en.wikipedia.org/wiki/Waterbed_theory https://en.wikipedia.org/wiki/Waterbed_theory

isostatic 8y ago
> How robust are your routines for removing accounts when unused? For our main corporate server list (about 1000 servers and 50 users), disable account in ldap and password authentication no longer works (so they lose sudo). Takes about 5 minutes to replicate I believe. If they have a .ssh key they can still log on until the local account is disabled, which runs daily. The 100 or so servers outside the corporate walled garden, with 10 users, simply have to wait for a day for the account to be disabled - or run a bash script from rundeck to kick it off earlier. The CRL cache-time on their client certs is longer than that in any case so it's not top priority. I last did this 3 weeks ago. We didn't want central authentication for non-walled-garden machines as there's a good chance many of them may be used offline, both via ssh and local access. It's far easier and less error prone than having to change credentials and authorized_keys for generic accounts everytime someone leaves. You've also got the benefit of knowing who's logging in to each server, as I assume your auth.log is also fired off to syslog. How do you prevent an ex-employee logging in without a generic account, other than changing credentials and authorized keys? I'm assuming it was a mutual termination and you don't need to worry about backdoors (because if you do, you're screwed regardless) But forget nefarious purposes -- if you have a problem on a machine and you see that "admin" was logged on at the time the problem started, how do you know who "admin" was so you can work on the fix?
- kbenson 8y ago
  > It's far easier and less error prone than having to change credentials and authorized_keys for generic accounts everytime someone leaves. You've also got the benefit of knowing who's logging in to each server, as I assume your auth.log is also fired off to syslog. I can write a system (and have, multiple times) that takes public keys from people in a file named by their users, aggregates them into a single authorized_keys file, and pushes it to the admin account on all the servers in a list in 5-10 minutes. Access removal is removal of their key and running a command that uses scp to upload a new authorized_key file for all servers. Using xargs and parallel jobs, than can complete within a minute or two even for 1000+ servers, errors are easily visible, any problem in the process is easily troubleshot, and if worse comes to worse and the system isn't functioning, you can manually update the authorized_keys on a few servers that need it ASAP. No LDAP config, requires, and anyone with basic SSH understanding can diagnose and understand what's required to fix an error within a minute or two. Give me another 30-60 minutes and it would support a config file with user groups and assigning group or individual access to servers. There are features you don't get with that, but it's dead simple and very robust. LDAP is good, but if all you need is to set up admin access to Linux/BSD servers, it also might be overkill and cause the occasional headache. There's a huge range between manually configuring every server for every change and using LDAP for account access. > But forget nefarious purposes -- if you have a problem on a machine and you see that "admin" was logged on at the time the problem started, how do you know who "admin" was so you can work on the fix? SSH allows environment vars to be passed along with the authorized key file. You can set your default EDITOR for example, but your push system can also append a specific variable that denotes who the actual user was that connected, and your login config can log it to a file as you connect. There are simple solutions for most things you would want in this space. Once there isn't a simple solution, then maybe the value of a centralized authorization system might show itself.
  - isostatic 8y ago
    > I can write a system (and have, multiple times) that takes public keys from people in a file named by their users, aggregates them into a single authorized_keys file, and pushes it to the admin account on all the servers in a list in 5-10 minutes. The modern way to do such a thing would be using ansible, which just as easily allows you to create/delete user accounts. While custom vim settings per user are nice to haves, the biggest benefit is AAA. I'm not sure what type of auditing you can realistically do with, you'd have to trace through machine logs to find the IP of origin for a given pts, and hope that the dhcp server still has.