On Sunday, 17 July 2022 21:10:52 CEST Grant Taylor wrote: > On 7/15/22 11:42 PM, J. Roeleveld wrote: > > True, properly done automation is necessary to make our lives easier. > > #truth > > > I tried this approach in the past and some levels of automation still > > use this, but for being able to login myself, I found having different > > keys become cumbersome and I ended up never actually replacing them. > > I'm curious what you found to be cumbersome.
If I have 1 desktop and 1 laptop, that means 2 client machines. Add 5 servers/vms. That means 10 ssh-keys per person to manage and keep track off. When a laptop gets replaced, I need to ensure the keys get removed from the authorized_keys section. Same goes for when the ssh-keys need refreshing. Which, due to the amount, I never got round to. I actually have more then the amount mentioned above, the amount of ssh-keys gets too much to manage without an automated tool to keep track of them and automate the changing of the keys. I never got the time to create that tool and never found anything that would make it easier. > I make extensive use of the client SSH configuration file > (~/.ssh/config) such that I don't need to worry about which key is used > for which host. This means that anything that uses ssh / sftp / scp > /just/ /works/ (tm) using the contents of the configuration file. When hosts can get added and removed regularly for testing purposes, this requires a management tool. > > The goal is to have whichever authentication system used, the > > passwords/keys to be replaced often with hard to brute-force > > passwords/keys. I can currently replace all passwords on a daily > > basis and not have a problem with accessing any system. > > I agree in concept. Though I question the veracity of that statement > when things aren't working normally. E.g. system is offline for X hours > do to hardware failure or an old version restored from backup that is > now out of sync with the central system. Down due to hardware issues means the password-refresh fails for this host. Backup-restore scripts have a step added to update the passwords updated to whatever is in the vault before the system is brought back online. I actually considered these and made sure it can handle this. The most common issue is a network link being down due to ISP issues. > > For normal use, most systems don't need to be logged into a shell. For > > the few where this is needed, individual accounts exists. But, no > > individual account is a member of "wheel". For admin access, there are > > admin accounts on the machines. (they are all named individually and > > you won't find the same admin-account-username on more then 1 system) > > I've wondered about having the account for UID / GID 0 be named > something other than root. But the testing that I did showed that there > were too many things that assumed "root". :-/ You could put "root" without a valid password, making it impossible to "su -" into and add a 2nd uid/gid 0 account with a valid password. I know of 1 organisation where they had a 2nd root account added which could be used by the orgs sys-admins for emergency access. (These were student owned servers directly connected to the internet) > Though I did find that I was able to successfully convert a test VM to > use something other than root and the proof of concept was a success. > It's just that the PoC was too much effort / fragile to be used in > production. > > I find that the wheel group is mostly for su and a few other commands. > But the concept of you must be a member of a group or have special > permissions applied directly to your account is conceptually quite > similar to being a member of the wheel group. As such I don't think the > abstraction makes much difference other than obfuscation. I expect the "wheel" group to only be for changing into "root", that's what it's advertised as. > > True, but this needs to run from the client. Not the server. Which > > means it will need to be triggered manually and not scheduled. > > The algorithm could be refactored such that it is run from the server. > E.g. if you can ensure that the old key is replaced with the new key, it > can safely be done server side. I did this for a few colleagues that > had forgotten the passphrase for their old private key and needed their > new public key to be put into place. Still needs the clients to be actually running when the server runs the script. Or it needs to be added to a schedule and gets triggered when the client becomes available. This would make the scheduler too complex. > > I don't even have sudo installed on most systems, only where it's > > needed for certain scripts to work and there it's only used to avoid > > "setuid" which is an even bigger issue. > > I tend to prefer sudo's security posture where people need to know > /their/ password. Meaning that there was no need for multiple people to > know the shared target user's password like su does. I agree, but root-access is only needed for specific tasks, like updates. Most access is done using service-specific accounts. I only have 2 where users have shell-accounts. > If I was in a different environment, I'd consider Kerberized versions of > su as an alternative. I'd love to implement Kerberos, mostly for the SSO abilities, but haven't found a simple to follow howto yet which can be easily adjusted so it can be added to an existing environment. -- Joost
