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
