Some systems like to have a CA supply short-lived certificates to ssh clients. The basic idea is that servers enable certificate authentication, clients authenticate to the CA out of band, and the CA issues client certificates that are valid for a short enough time that users don't want to manually drop them into ~/.ssh or otherwise think about them. There are a handful of commercial examples, and it's also pretty straightforward to implement this manually. As far as I an tell, ssh and ssh_config don't have a great way to handle this usage model. Various kludges and solutions that sort of work include: User runs a command to get the certificate, and the command puts the certificate somewhere that matches the CertificateFile. If the user forgets to run the command, they fail to authenticate and have to do it manually. ssh_config contains a Match ... exec [command to refresh the certificate]. This sort of works, except that it runs the command far too frequently. For example, ssh -O exit [name] refreshes the certificate, and it should not do so. IdentityAgent could point to a custom agent. This would be more useful if ssh could _start_ the agent. In any case, this requires an agent, which is more complex than a tool that refreshes a certificate. PKCS11Provider doesn't seem useful. ProxyCommand could specify a command that refreshes the certificate. Cloudflare recommended this at one point, and it worked about as poorly as might be expected. (That is, very poorly indeed.) So my feature request: a way to do this for real. Here are a couple of ideas: PreAuthCommand: runs a command before reading any files associated with authentication. (This especially means that the command runs, and completes, before opening the CertificateFile.) CertificateCommand: runs a command that outputs a certificate or perhaps just a CertificateFile directive. I'm sure there are more ways to make this better, hence this feature request. Thanks, Andy _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
