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).
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
