openssh unix dev - Feb 2017 - ssh-agent check for new fresh certificate (and key)? worthwhile doing?

As background, for one of my clients we built out a command line tool
which does SSO with Google Apps, then generates a new SSH key pair,
and sends this off to an internal service which verifies the request
and then issues a new short lived (24 hour) certificate (if interested
the code for the server and client is open-sourced here:
https://github.com/continusec/geecert), overwriting the previous
certificate and private key.

Some of our users like to use SSH agent forwarding, and while this
generally works fine, when our users run their daily command to get a
new certificate, their ssh-agent still holds the old one.

Would it be reasonable to write a patch to ssh-agent to that changed
its behavior to:

Check whether a certificate it is going to use is expired (or close to
it, or maybe just changed on disk), and if so, check if there is a new
certificate at the same location, and if so, drop the current
certificate / private key, and replace with the new certificate
private key?

Alternatively I could change our daily command to check if ssh-agent
is running with the cert there, and ask it to add a new one (and
somehow clean out the old one), but since I'm a glutton for
punishment, I thought I'd ask here whether a more general solution is
likely to be accepted if I submitted a patch along those lines.

why not add the certificate to the running ssh-agent with a timeout
that expires when the cert does?

I don't think ssh-agent exposes a "how long until this key
expires"
api, but you can at least use this method to see if the cert/key are
*on* the agent and you can assume that if they're on the agent, then
they're valid.

we make extensive use of the certificates at work and this is how we do it.

On Wed, Feb 1, 2017 at 2:40 AM, Adam Eijdenberg <adam at continusec.com>
wrote:
> As background, for one of my clients we built out a command line tool
> which does SSO with Google Apps, then generates a new SSH key pair,
> and sends this off to an internal service which verifies the request
> and then issues a new short lived (24 hour) certificate (if interested
> the code for the server and client is open-sourced here:
> https://github.com/continusec/geecert), overwriting the previous
> certificate and private key.
>
> Some of our users like to use SSH agent forwarding, and while this
> generally works fine, when our users run their daily command to get a
> new certificate, their ssh-agent still holds the old one.
>
> Would it be reasonable to write a patch to ssh-agent to that changed
> its behavior to:
>
> Check whether a certificate it is going to use is expired (or close to
> it, or maybe just changed on disk), and if so, check if there is a new
> certificate at the same location, and if so, drop the current
> certificate / private key, and replace with the new certificate
> private key?
>
> Alternatively I could change our daily command to check if ssh-agent
> is running with the cert there, and ask it to add a new one (and
> somehow clean out the old one), but since I'm a glutton for
> punishment, I thought I'd ask here whether a more general solution is
> likely to be accepted if I submitted a patch along those lines.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Thu, Feb 2, 2017 at 1:16 AM, Peter Moody <mindrot at hda3.com>
wrote:
> why not add the certificate to the running ssh-agent with a timeout
> that expires when the cert does?
That's an excellent idea. I've modified our tooling to do exactly that
(https://github.com/continusec/geecert/commit/dfeee14b278e28d15bf532bb6e6e8ffe530e6b11).

Thank you for the suggestion.
> I don't think ssh-agent exposes a "how long until this key
expires"
> api, but you can at least use this method to see if the cert/key are
> *on* the agent and you can assume that if they're on the agent, then
> they're valid.
I guess a case could be made for ssh-add to always set a timeout when
adding a certificate with an expiry time, but I think for now I'm
happy enough to do that on our end.