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

[Grant Taylor]

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.

> 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 assume the same is true for most people.

Yes.  It depends what security posture you / your organization want.

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

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

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



-- 
Grant. . . .
unix || die