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

[Grant Taylor]

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.

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.

> 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.

> 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".  :-/

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.

> 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.

> 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.

If I was in a different environment, I'd consider Kerberized versions of 
su as an alternative.



-- 
Grant. . . .
unix || die