add keys and certificate to forwarded agent on remote host

[Peter Moody]

On Mon, Sep 17, 2018 at 6:13 AM, Rory Campbell-Lange
<rory at campbell-lange.net> wrote:
> Apologies if this post is inappropriate to this list; please redirect me
> if so.
>
> Our team uses ssh extensively for server access and maintenance
> (Debian). An issue is acting as root when operating, for example, over
> ansible and keeping a record of who performed the actions, something ssh
> certificates solves well.
>
> The problem is then to automate certificate issuance since it would be
> pretty arduous for someone to keep issuing short-lived user
> certificates.
>
> I was intrigued to read Uber's ussh announcement page and wondered if
> this suggests a route for doing so:
> (https://medium.com/uber-security-privacy/introducing-the-uber-ssh-certificate-authority-4f840839c5cc)
>
>     An employee gets a ussh certificate when they run the ussh command.
>     This connects to the USSHCA, performs the pam conversation and
>     forwards the client’s ssh agent to the CA. If the client
>     successfully authenticates, the CA generates a new ssh key,
>     populates the associated cert with the configured information
>     (validity period, the user it’s valid for, the options permitted,
>     etc.) and adds both the key and the certificate to the remote agent.
>     The certificates are added to the agent with a timeout telling the
>     agent to remove the keys when the certificate expires.
>
> Assuming we write a program to generate a new key pair and associated
> user certificate, how would one go about adding this to a forwarded
> agent on the remote server hosting the program? Can ssh-add work on the
> remote socket file? Is such an operation advisable?

Hi,

It's unclear if I'm ever going to be able to opensource usshca at this
point, but I can assure that you it's definitely possible to add a
private key (and certificate) to a forwarded ssh-agent. It might not
be clear from the blog post, but usshca is itself an ssh server,
albeit one that doesn't drop an authenticated user into a shell.
openssh's sshd makes a remotely forwarded agent available locally via
unix domain socket, but usshca just takes the remote agent and,
assuming everything's a-ok, adds the key and cert.

there should be examples online of what this looks like, at least in go.

In the example below, if 'conn' is an ssh.ServerConn (ie. what you get
from calling ssh.NewServerConn [1] on an incoming connection), you can
run something like

  agentChan, reqs, err := conn.OpenChannel("auth-agent at openssh.com", nil)
  if err != nil {
    panic(err)
  }
  go ssh.DiscardRequests(reqs)
  agentConn := agent.NewClient(agentChan)

and now agentConn is an agent interface [2] connecting you to a remote
ssh-agent. You can add your newly generated ssh keys and certificates,
you can fetch public keys, request data be signed, verify signatures,
etc.

Hope this helps.

Cheers,
peter

[1] https://godoc.org/golang.org/x/crypto/ssh#NewServerConn
[2] https://godoc.org/golang.org/x/crypto/ssh/agent#Agent

> Apologies for this rather naive questions, and also if I'm covering
> well-worn territory.
>
> Thanks
> Rory
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev