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

[J. Roeleveld]

On Friday, 15 July 2022 18:32:52 CEST Grant Taylor wrote:
> On 7/15/22 1:53 AM, J. Roeleveld wrote:
> > I agree, but that is a tedious process.
>
> Yes, it can be.  That's where some automation comes into play.

True, properly done automation is necessary to make our lives easier.

> > I have multiple machines I use as desktop depending on where I am. And
> > either I need to securely share the private keys between them or set
> > up different keys per desktop.
>
> I /currently/ use unique keys /per/ /client/ /system/.
>
> I am /planing/ on starting to use unique keys /per/ /client/ /per/
> /server/.  Meaning that each client will use a different key for each
> remote server.  I think that this combined with location restrictions in
> the authorized_keys file will mean that SSH keys (or certificates) can't
> be used from anywhere other than their approved location or for anything
> other than their intended purpose.

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 assume the same is true for most people.
>
> Yes.  It depends what security posture you / your organization want.

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.

> > Never mind that access to the servers needs to be possible for others
> > as well.
>
> I assume that other users will use their own individual accounts to log
> into the target systems with a similar configuration.
>
> E.g. I log into remote systems as "gtaylor" and you log into remote
> systems as "joost", and Neil logs into remote systems as "neil".  We
> would all then escalate to root via "su -" with the automation providing
> the password to su.

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)

> > Either way, to do this automatically, all the desktop machines need
> > to be powered and running while changing the keys.
>
> No, they don't.
>
> You just need to account for current and prior keys.
>
> I've done exactly this on a fleet of about 800 Unix systems that I
> helped administer at my last job.  You do something like the following:
>
> 1)  Log into the remote system explicitly using the prior key.
> 2)  Append the current key to the ~/.ssh/authorized_keys file.
> 3)  Logout of the remote system.
> 4)  Log into the remote system explicitly using the current key.
> 5)  Remove the prior key from the ~/.ssh/authorized_keys file.
> 6)  Logout of the remote system.
>
> This can be fairly easily automated.

True, but this needs to run from the client. Not the server. Which means it 
will need to be triggered manually and not scheduled.
 
> You can then loop across systems using this automation to update the key
> on systems that are online.
>
> You can relatively easily deal with systems that are offline currently
> later when they are back online.  --  There are ways to differentiate
> between offline and bad credentials during day to day operations.  So
> when you hit the bad credentials you leverage the automation that tries
> old credentials to update them.
>
> You end up bifurcating the pool of systems into different groups that
> need to be dealt with differently.  Online and doing what you want;
> online but not doing what you want; and offline.
>
> > Changing passwords for servers and storing them in a password vault
> > is easier to automate.
>
> I disagree.
>
> Using passwords tends to negate things like authenticating to sudo with
> SSH keys / certificates, thus prompting the use of NOPASSWD:.

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.

--
Joost