jenkins and ssh-agent forwarding

[Nathaniel Irons]

I've been looking for a way to scrub our CI system of password-less SSH keys, on-disk credentials, and plugins trusted with passphrases. ssh-agent is running on our Jenkins master (Ubuntu), and contains keys for github, our in-house git server, and the build nodes (OS X).

Agent forwarding is enabled on the the build nodes, the master, and in the master's ~/.ssh/config host entries. When I SSH into jen...@master.local, typing "ssh buildnode.local", gets me logged in without a passphrase challenge. $SSH_AUTH_SOCK is then set correctly by SSH on the build node with a per-connection agent socket:

$ echo $SSH_AUTH_SOCK

/tmp/ssh-F2kCwhD3eF/agent.35290

At this point, if I type `ssh -T g...@github.com`, I see the expected reply:

Hi <expected-github-username>! You've successfully authenticated, but GitHub does not provide shell access.

I can then merrily clone and pull without interference.

However, when Jenkins create a slave session over SSH, the SSH_AUTH_SOCK variable isn't set, and connections to Github or our internal server all die with authentication failures.

As an exercise, I connected a build node SSH session from the Jenkins VM, copied out its SSH_AUTH_SOCK value, and defined that as an env var on the build node's configuration. A test job tied to that build node then connected to github perfectly.

This isn't a solution yet, because as soon as I close the SSH session, the agent socket gets cleaned up, and a subsequent run of the test job fails. It does demonstrate that I'm only one step away from managing my credentials securely and centrally, but Jenkins is somehow creating its SSH sessions without accepting the SSH_AUTH_SOCK env var that it should be getting for free.

Any suggestions on overcoming this last hurdle, or an equivalently secure way to achieve the same ends?

Thanks,

  -nat

[Stephen Connolly]

Have you had a look at the SSH Agent plugin?

Not quite the way you are approaching this, and we still need to work it into git and svn plugins, but still feedback would be good

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Nathaniel Irons]

I saw it, but part of my goal is to avoid trusting a Jenkins plugin with credentials. I already trust the ssh-agent and forwarding arrangement built into the OS, which *should* work out of the box with Jenkins. I'd at least like to understand why Jenkins doesn't inherit and take advantage of $SSH_AUTH_SOCK like an ordinary SSH client, before investing in additional complexity.

Thanks,

  -nat