openssh unix dev - Mar 2023 - Feature request: a good way to supply short-lived certificates to openssh

On 07/03/23, Darren Tucker (dtucker at dtucker.net)
wrote:
> On Tue, 7 Mar 2023 at 05:26, Andy Lutomirski <luto at kernel.org>
wrote:
> [...]
> > 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.
> 
> You can have the command check if the cert is expired or near expired
> before refreshing it.  I've done this in the past with expiring
> certificates.
I was intrigued by Darren's note about a command to check certificate
expiry. I've put together a quick POC in go to list expiring certificates:
https://gist.github.com/rorycl/d194243c61b349021935c97f751a931e

Output is something like:

    0 key ssh-ed25519 : is not a certificate
    1 key ssh-ed25519-cert-v01 at openssh.com
        comment:  acmeinc_briony_from:2023-03-07T08:18_to:2023-03-07T11:18UTC
        validity: 2023-03-07 08:37:23 GMT to 2023-03-07 11:37:23 GMT
        expiring in 60m? true

I'd be grateful to Andy if he explained what sort of command he runs to
refresh certificates. I understood most refresh arrangements to involve OAuth2.

Rory

This is the approach I take:

- generate a private key and certificate and stuff them into ssh-agent

- set the label in ssh-agent to something that identifies the key+cert, 
and the ssh-agent expiry time to be the same as the certificate expiry 
time, or slightly less

- each time you make an ssh connection, query the agent to see if 
there's the expected key+cert, and generate a new one if not

I'm using Hashicorp Vault to generate the certs, and I wrote this code 
for the client side:

https://github.com/candlerb/vault-ssh-agent-login

It skips the cert generation if there appears to be a valid cert already 
in the agent.

I invoke this via a wrapper script (below). I haven't looked into 
hooking it directly into ssh_config (which is what this thread was 
originally about).

#!/bin/bash -eu
export VAULT_ADDR="https://vault.example.net:8200"

case "${1:-}" in
"-force") OPT="-force"; shift ;;
"")?????? OPT="" ;;
*)??????? OPT="-quiet" ;;
esac

vault-ssh-agent-login -role=my_ssh_role \
 ? -valid-principals="brian,ubuntu" \
 ? -auth-method=oidc -auth-path=google $OPT

[ $# -gt 0 ] && exec ssh "$@"

On Tue, Mar 7, 2023, at 3:25 AM, Rory Campbell-Lange
wrote:
> On 07/03/23, Darren Tucker (dtucker at dtucker.net) wrote:
>> On Tue, 7 Mar 2023 at 05:26, Andy Lutomirski <luto at kernel.org>
wrote:
>> [...]
>> > 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.
>> 
>> You can have the command check if the cert is expired or near expired
>> before refreshing it.  I've done this in the past with expiring
>> certificates.
>
> I was intrigued by Darren's note about a command to check certificate 
> expiry. I've put together a quick POC in go to list expiring 
> certificates: 
> https://gist.github.com/rorycl/d194243c61b349021935c97f751a931e
>
> Output is something like:
>
>     0 key ssh-ed25519 : is not a certificate
>     1 key ssh-ed25519-cert-v01 at openssh.com
>         comment: 
acmeinc_briony_from:2023-03-07T08:18_to:2023-03-07T11:18UTC
>         validity: 2023-03-07 08:37:23 GMT to 2023-03-07 11:37:23 GMT
>         expiring in 60m? true
Nifty,
>
> I'd be grateful to Andy if he explained what sort of command he runs to
> refresh certificates. I understood most refresh arrangements to involve 
> OAuth2.
The actual setup I'm using is:

Host myhost
	Match host myhost exec "cloudflared access ssh-gen --hostname
myhost.domain"
	ProxyCommand cloudflared access ssh --hostname myhost.domain
	IdentityFile ~/.cloudflared/blahblah
	CertificateFile ~/.cloudflared/blahblah.pub

cloudflared is this thing (open source!):

https://github.com/cloudflare/cloudflared

There are two pieces of magic here.  One is the "couldflared access
ssh-gen" command.  It's annoyingly slow (which could be fixed,
presumably), and it refreshes the certificates in ~/.cloudflared, using (I
presume -- haven't checked) OAuth2 behind the scenes.  The other is the
ProxyCommand, which, as I've configured it, is just a proxy.

This is a kludge.  On the one hand, it mostly works.  On the other hand, it
behaves poorly when doing anything other than just connecting.  The case that
bothers me the most is ssh -O command myhost.

I think the most straightforward change to openssh would be to allow me to
rewrite it as:

Host myhost
	PreAuthCommand cloudflared access ssh-gen --hostname myhost.domain
	ProxyCommand cloudflared access ssh --hostname myhost.domain
	IdentityFile ~/.cloudflared/blahblah
	CertificateFile ~/.cloudflared/blahblah.pub

ssh -O would not invoke the PreAuthCommand, and other ssh commands that
don't need to authenticate would also not invoke it (e.g. ssh reusing an
existing connection).  But an ssh command that did need to authenticate would
read it before opening and of the the credential files.


(I have no affiliation with Cloudflare.)