Mailing List Archive

Loading (Only) a Cert Into the Agent
A quick question (I hope): I built an SSH user CA that would allow users
to SSH in (using their keypair) and thus trigger creation of a matching
cert. What I would *like* to do is to (add agent forwarding to the login
and) have the CA load the cert straight into the agent.

What happens is that doing an ssh-add on the CA fails because it cannot
find the *private* key in a local file, and even when I download the
cert and do the ssh-add locally, I need to enter the passphrase into the
terminal, presumably because it does read the privkey from its file as
well - in spite of the fact that the privkey is already loaded in the
agent all the time.

Is this a principal limitation of the code/protocol/security model,
something I can work around (though I don't yet see how), a feature
request with a chance of getting implemented, ... ?

Kind regards,
--
Jochen Bern
Systemingenieur

Binect GmbH
Re: Loading (Only) a Cert Into the Agent [ In reply to ]
On 9/10/21 9:53 AM, Jochen Bern wrote:
> A quick question (I hope): I built an SSH user CA that would allow users
> to SSH in (using their keypair) and thus trigger creation of a matching
> cert. What I would *like* to do is to (add agent forwarding to the login
> and) have the CA load the cert straight into the agent.
>
> What happens is that doing an ssh-add on the CA fails because it cannot
> find the *private* key in a local file, and even when I download the
> cert and do the ssh-add locally, I need to enter the passphrase into the
> terminal, presumably because it does read the privkey from its file as
> well - in spite of the fact that the privkey is already loaded in the
> agent all the time.
>
> Is this a principal limitation of the code/protocol/security model,
> something I can work around (though I don't yet see how), a feature
> request with a chance of getting implemented, ... ?

Yes,
this was discussed since 2015 in context of PKCS #11 backed keys in
hardware, but the protocol was not yet updated to support loading
separate certificates:

https://bugzilla.mindrot.org/show_bug.cgi?id=2472

Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Loading (Only) a Cert Into the Agent [ In reply to ]
There was also a discussion on this topic earlier this year, with
subject "Insert certificate into agent for existing key?"

https://marc.info/?l=openssh-unix-dev&w=4&r=1&s=insert+certificate+into+agent&q=b
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Loading (Only) a Cert Into the Agent [ In reply to ]
On Fri, 10 Sep 2021, Brian Candler wrote:

> There was also a discussion on this topic earlier this year, with subject
> "Insert certificate into agent for existing key?"
>
> https://marc.info/?l=openssh-unix-dev&w=4&r=1&s=insert+certificate+into+agent&q=b

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.

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).

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Loading (Only) a Cert Into the Agent [ In reply to ]
On 10/09/2021 11:38, Damien Miller wrote:
> 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 is true, but:

a. if you are generating the certificate dynamically, you have to write
it out to the filesystem.  Usually not a problem if the certificate
fetch is scripted.

b. if you are doing multi-hop ssh logins with agent forwarding, you have
to copy the certificate file to all intermediate hosts. That's a bigger
pain.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Loading (Only) a Cert Into the Agent [ In reply to ]
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