Re: [gentoo-user] Any way to automate login to host and su to root?

[J. Roeleveld]

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