On 10.09.21 12:38, Damien Miller wrote: > Yeah, addings just certificates to the agent requires protocol > extensions to match them against already loaded private keys. It's > messy and complicated in a piece of code that we really don't want > to be messy and complicated. And considering that the most current relevant spec that openssh.org points to https://datatracker.ietf.org/doc/html/draft-miller-ssh-agent-04 does not list certs *at all*, that sort of thing has already been done, hasn't it? IIUC by adding "cert" variants of the existing key types that no implementation but OpenSSH would recognize and try to process. (FWIW, assuming that the agent will not hold more than a handful privkeys - the MaxAuthTries issue comes to mind here - and can determine which of those matches a cert - that seems to be what https://marc.info/?l=openssh-unix-dev&m=143792343407993&w=4 is doing -, an SSH_AGENTC_ADD_IDENTITY / SSH_AGENTC_ADD_ID_CONSTRAINED message with an "obviously invalid" privkey could be used to signal "please try the ones you already have".) > But you don't actually need to load a certificate into an agent to > use it with an agent! You can just have the private key in the agent > and specify CertificateFile in ~/.ssh/config or on the command-line > and ssh will match the private key to the certificate when it is time > to use it (well, it should anyway). That's *sort of* what I resorted to: The CA service throws the cert back via stdout, and a client-side wrapper script stuffs it into a local file ~/.ssh/${FOOBARBAZ}-cert.pub, so that at least any subsequent reloads shove it into the agent. (I recommend that users fix their ssh-askpass setup (it's broken out of a standard install more often than not these days) and use "-c -t 18000" with ssh-add, which would help it. I often fall on deaf ears with that, though.) I *also* recommend that users set up at least *two* keypairs of different cryptalgorithms in case one goes badly-broken-and-express-disabled one day (memento the "DSA on Ubuntu" incident), and also occasionally replace them, which means that they can easily have several of the *same* algorithm as well (keeping the old one in case they forgot a system in replacing it with the new). I had my script tested by exactly *one* other user so far, and had to screen-sharing-talk him through configuring the FOOBARBAZ= settings in it so that the certs *actually would* wind up in the proper files. And then there's the possibility that you have *several* CAs providing different certs (different principals, from different projects) for the *same* user keypair and you try to store *that* in "the (one) proper" file ... or is OpenSSH ssh-add willing to read in *several* certs stored in just one file(name)? Regards, -- Jochen Bern Systemingenieur Binect GmbH
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
