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
