On 31/01/2020 15:37, Michael Str?der wrote:> (BTW: yubikey is slow. So if you have admins accessing many machines in > one go you will get a notable latency during first SSH connection.)I meant using a single Yubikey as the CA sign the certificates. I'm thinking of an organization where the number of admins is in the low tens.? The end-game of having daily keys and certs loaded directly into ssh-agent is very appealing, but I'm not sure we're ready to jump right there yet.? Getting people over to certs and starting to rip out ~/.ssh/authorized_keys is an important first step. As for the freshness of the CRL file: this is something we can easily monitor and alert on in prometheus. Regards, Brian.
On 1/31/20 5:21 PM, Brian Candler wrote:> On 31/01/2020 15:37, Michael Str?der wrote: >> (BTW: yubikey is slow. So if you have admins accessing many machines in >> one go you will get a notable latency during first SSH connection.) > > I meant using a single Yubikey as the CA sign the certificates.Ah, I've misread that. Just using temporary key/cert files makes things easier at the client side.> I'm thinking of an organization where the number of admins is in the low > tens.? The end-game of having daily keys and certs loaded directly into > ssh-agent is very appealing, but I'm not sure we're ready to jump right > there yet.? Getting people over to certs and starting to rip out > ~/.ssh/authorized_keys is an important first step.I'm not sure I get your reasoning why having longer cert validity period makes things easier for the user. IMHO the opposite is true. If your installation just works on all required OS platforms (client and server) it's pretty easy to teach people how to use it to get a short-term user cert once or twice a day. Anyway they have to be capable to do this at any time no matter how long the cert validity period is. Ciao, Michael.
On 31/01/2020 16:47, Michael Str?der wrote:> I'm not sure I get your reasoning why having longer cert validity period > makes things easier for the user. IMHO the opposite is true.I wasn't saying it was easier for users - only as part of a potential migration strategy. Today, people use private keys stored on their hard drives, and ~/.ssh/authorized_keys on remote host.? So the plan I currently have in my head is: Step 1: turn on cert authentication with an offline manual CA. Start using it for automated processes.? (My primary driver for rolling out certs is to avoid installing an ansible master key in /root/.ssh/authorized_keys on all servers; instead I will roll out TrustedUserCAKeys) Step 2: give end users a manually-issued medium-lifetime cert to sit alongside their existing private key. Step 3: start ripping out ~/.ssh/authorized_keys, and deal with the breakage (e.g. finding hidden automated processes which rely on static keys, and replace them with certs) Step 4: build and roll out the infrastructure for issuing short-lived user keys and certs dynamically Somewhere along the line: do the signing of host keys.? (Probably as part of step 1, as I have to push out the new ssh configs anyway).