Loading (Only) a Cert Into the Agent

[Jochen Bern]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20210910/5c0c3f7c/attachment-0001.p7s>