If you generate short lived certificates via an automated process/service then you don’t really need to manage a revocation list as they will have expired in short order.
Hmm. For user certs you can have the service sign them for, say an hour, so long as you can ssh to your server in that time then there’s no need for any other interaction.
Sure you need your signing service to be reasonably available, but that’s easily accomplished.
That sounds like a lot of extra steps. How do I validate the authenticity of a signing request? Should my signing machine be able to challenge the requester? (This means that the CA key is on a machine with network access!!)
Replacing the distribution of a revocation list with short-lived certificates just creates other problems that are not easier to solve. (Also, 1h is bonkers, even letsencrypt doesn't do it)
Honestly, we used to replace a lot of pam_ldap and similar sorts of awful solutions. With those, if your LDAP went down even for a heartbeat, you couldn't log in at all.
So I totally agree: if I had to do certificates and didn't have something like Userify, a 1 hour (or even shorter if possible) expiration seems quite worth chasing, especially with suitable highly available configuration. (Of course, TFA doesn't even bother mentioning revocation and expiration, which should give you a clue as to how much fun those are lol)
And for more normal, lower-security requirements or non-HA, 6 or 8 hours or so would probably work and give you plenty of time for even serious system outages before the certs expired.
Not to hard shill or anything (apologies in advance, just skip if you're not interested), but there are two significant security and reliability differences between standard SSH (with or without certificates) and Userify:
1. Userify Cloud updates by default every three minutes, and on-premise Userify Express/Enterprise updates every ten seconds, but it doesn't have to update at all; even if your Userify server goes offline forever, you can still log in because the accounts are standard UNIX accounts (literally created with `useradd`)
2. When accounts are removed, Userify also completely nukes the user account, removes its sudo perms, and totally kill -9 's any tmux/screen/etc sessions (all processes owned by the user are terminated across the entire enterprise within seconds), which is also not something that a certificate expiration would ever do.
It's a very rare race condition, odds are very low that you were impacted. If you were, you would have noticed (heavy builds with files being moved around where suddenly files are zero).
Another major stumbling block for train signals once you get the basics down is segment length. Signals indicate whether the next segment is occupied, not whether any given train will fit in there (and potentially block a segment or intersection behind it.)
I frequently set up tracks with segments as large as my longest train, but then end up having to add an intersection here or there, breaking up segments into smaller sizes. This is the root of most of my train woes (aside from LTN issues, which are a whole other issue!)
> Signals indicate whether the next segment is occupied, not whether any given train will fit in there (and potentially block a segment or intersection behind it.)
That's what chain signals are for. If a train waiting at a signal causes issues, replace the previous signal with a chain signal to prevent the train from problematically waiting at the signal.
The threat model for every lambda user having a password manager does not cover breaking and entering[0]: they should write down their master password and keep it at home in their bedroom drawer.
Use biometrics where possible (e.g. bitwarden on Android has that option)
[0] maybe it does for you, working on some DoD-confidential docs, but your computer-illiterate aunt doesn't.
As for bio-metrics they are not possible on all devices, and some software will require you to enter the master password once in a while even if it's activated.
But even if it was not the case, if you loose your device, you need to setup the new one, and for that, you need the master password or have backups.
It's only now added as an interactive step in the install script. It has ~always been possible to create a crypto device with the install medium by dropping to a shell: https://www.openbsd.org/faq/faq14.html#softraidFDE
Unless you actually hit the maximum your building can sustain (heat, volume). Building datacenters is incredibly expensive, so reusing existing infrastructure and packing it with more is actually important.
Is that yet another problem that I need to solve with syncthing?
https://man.openbsd.org/ssh-keygen.1#KEY_REVOCATION_LISTS