SSH certificate and serverside ForceCommand

Damien Miller djm at mindrot.org
Wed Jun 24 12:21:05 AEST 2020


On Tue, 23 Jun 2020, Alejandro Dabin wrote:

> Hi,
> We're developing an open source project that uses SSH certificates. We
> issue short lived certificates (few minutes) to execute commands on behalf
> of users. We have a use case where we need to issue certificates with 10
> days validity and store them, so we put a command inside them:
> 
> ssh-keygen -s ca-key -I certN -n user -O force-command="wget something" -V
> +10d user-key.pub
> 
> and it works as expected. This way, if the certificate is stolen, it can
> only be used to execute that command (also the CA is only trusted from some
> hosts, no root login, etc).
> 
> We also want to use "ForceCommand" option on the server (inside a "Match"
> section) to put a wrapper that checks commands executed for this CA. If a
> rogue certificate is issued, at least we can control what is executed.
> However, as the command is embedded inside the certificate, the server
> passes an empty "SSH_ORIGINAL_COMMAND" to the wrapper. I couldn't find any
> additional option or environment variable for this case. We can pass the
> command when the connection is established, but it defeats the purpose of
> having the certificate's "force-command".
> 
> So, is there a way the wrapper could get the command embedded inside a
> certificate?

I think your best avenue would be to set ExposeAuthInfo=yes in
sshd_config (note: requires a relatively recent sshd) and parse it out
of the certificate listed in $SSH_USER_AUTH. E.g.

grep "^publickey .*cert[a-z0-9-]*@openssh.com" $SSH_USER_AUTH \
	| awk '{print $2 " " $3}' | ssh-keygen -Lf -

> As a side note, more information about the certificate (issue and
> expiration time) could be useful for auditing. It would be useful too if
> the server could log it (aside from CA, certificate serial, etc), but
> couldn't find any option either.

No, the logging tries to balance between usefulness and brevity.
I'm not sure why expiry information would be useful there - I would
have thought that it's either it's good and accepted or bad and not...

-d


More information about the openssh-unix-dev mailing list