Long Keys

Link

and restarting the SSH service to boot everyone off

This does not close existing connections; sshd takes pains to allow a daemon restart without nuking the existing sessions. (If systemd is involved then unexpected session kills may happen, but that's systemd being different from most everything else in unix.)

    $ ssh localhost
    ...
    gear$ doas rcctl restart sshd
    sshd(ok)
    sshd(ok)
    gear$ exit
    Connection to 127.0.0.1 closed.

If we assume for a moment, that the device this key is generated on, keeps this key for its lifetime or until there is a known compromised state, then this can potentially be a very VERY long time. This means that updates to best practices can be years in the making (for my desktop, decades), but is that really a problem?

Maybe. Is forward secrecy involved? If not, is someone saving all your encrypted traffic in the hope that they can decrypt it in the future? More importantly, do you remember how to generate and rotate the keys? If it's something you do somewhere between years to never, you'll forget, and may do it poorly, or not at all. Periodic rotations help keep you in practice on how to rotate the keys—rather than a company going "dunno, too complicated", keeping old keys around, and, then, somehow, hacked!—and doing the rotation may help you discover new options or algorithms as they come out (assuming you review the manual or changelog whilst rotating the keys and try to think up ways things could be improved or streamlines or better documented, and you are not just trying to survive to the weekend). E.g. maybe favor Ed25519 over RSA? Or write some scripts to make key rotation easier? Or are the scripts now using an outdated option? Is there some fancy new keystore thing to try out?

Or maybe an attacker has found an old key from an old backup; do you know if the keys got backed up to some cloud thing, and all the security that may entail, or anywhere else the backups might have gotten to? Rotating keys may be a good thing, even if the keys can, in theory, last for a long time.

Speaking of which, I probably need to rotate the DKIM signing keys, which involves messing around with the DNS web interface thing. Ugh. Maybe I should run my own DNS servers, or really server, again. Or maybe they have an API so the web thing can be avoided? This sort of friction can lead to a drift away from best practices—frequent enough key rotation so that the rotations are known and practiced and can be improved on—and if the drift goes on long enough you may end up with totally unrotated keys, insecure environments, and totally ignorant workers—"that's how we've always done things!".

    #!/bin/sh
    TAG=`date +%Y%m%d`
    rspamadm dkim_keygen -s "$TAG" -d thrig.me -k "$TAG".key
    chmod 0440 *.key
    chown root:_rspamd *.key
    echo put public foo into DNS
    echo "cp $TAG.key thrig.me.key"
    echo "update /etc/rspamd/local.d/dkim_signing.conf with $TAG"

Key rotations with manual steps probably should be scheduled via a cron job or calendar event, ideally with a link to the wiki or other such documentation. With a team you will probably want to rotate who handles the rotation so that more than just one person knows the routine, and any problems with the documentation (my own documentation is easy for me to follow, but maybe not for others) can be ironed out. There are risks from key rotations, such as DNS breaking when DNSSEC goes poorly, but with more frequent rotations folks should be more in practice with the process, and any issues can be caught and handled before that one person retires who knew anything about the system.