Yes the SSH Agent plugin falls back to the system temporary directory when the path is going to be longer than 108 characters, the maximum typically supported by Linux kernels. Unfortunately this breaks the assumption of Docker Pipeline that the container and (agent) host share filesystems only in the workspace and its associated temporary directory.

Might work to use ws with a (shortish) absolute path inside node but outside inside. Or use withCredentials to access the SSH private key explicitly rather than using sshAgent.

I ran into this as well. I got around the issue by checking "Use custom child workspace" in my job config, and setting "Child Directory" to ${SHORT_COMBINATION}

Avoid that workaround; use ws instead.

Interesting... Couple of questions:

• Why should I avoid this?
• What is ws?

Look at the documentation.

Thanks for being so helpful.

Would perhaps be bypassed by PR 2, TBD.

HI , I have the same problem - I am using jenkins version 2.32.1
Docker Pipeline - 1.9.1
Pipeline - 2.4
Pipeline: Basic Steps -2.3
Pipeline: Job - 2.9
SSH Agent Plugin 1.13

I couldn't workaround it , any idea ?

here is my pipeline

_node ('ubuntu-aws'){
timestamps
{
docker.image('node').inside {
sshagent(['XXX'])

} // ssh agent
}
}

_

Again: only known workaround is to use the ws Pipeline step with a short absolute path, taking care to avoid collisions with other builds somehow (not generally easy). Proposed alternate plugin implementation would probably solve this issue; needs review and testing.

PR 17 is the new version.

For those using multibranch projects, read release notes. Since the default workspace directory name will be up to 80 characters, and you must stay within 108 for sshagent to work, that means you must limit your “remote FS root” to well under 28 characters.

Code changed in jenkins
User: Jesse Glick
Path:
pom.xml
src/main/java/com/cloudbees/jenkins/plugins/sshagent/RemoteAgent.java
src/main/java/com/cloudbees/jenkins/plugins/sshagent/SSHAgentBuildWrapper.java
src/main/java/com/cloudbees/jenkins/plugins/sshagent/SSHAgentStepExecution.java
src/main/java/com/cloudbees/jenkins/plugins/sshagent/exec/ExecRemoteAgent.java
src/main/java/com/cloudbees/jenkins/plugins/sshagent/exec/ExecRemoteAgentFactory.java
src/test/java/com/cloudbees/jenkins/plugins/sshagent/SSHAgentBase.java
src/test/java/com/cloudbees/jenkins/plugins/sshagent/SSHAgentBuildWrapperTest.java
src/test/java/com/cloudbees/jenkins/plugins/sshagent/SSHAgentStepWorkflowTest.java
http://jenkins-ci.org/commit/ssh-agent-plugin/8d02c6ca20ce514e8737a15b24bbfa7557930273
Log:
Merge pull request #18 from jglick/ExecRemoteAgent-JENKINS-36997

JENKINS-36997 CLI implementation of RemoteAgent

Compare: https://github.com/jenkinsci/ssh-agent-plugin/compare/f38bb5f22fea...8d02c6ca20ce

We tried this out with:

sshagent(['CredId']) {
  docker.inside('image') {
    // git operations
  }
}

and it did not work.

Using the following did work:

docker.inside('image') {
  sshagent(['CredId']) {
    // git operations
  }
}

That makes sense to me based on how the execution works now with using a CLI implementation.

Thanks for fixing this!

Right, the ssh-agent needs to be run inside the container so its socket is in the same kernel namespace as the commands which try to access it.

Why is this marked as resolved? I use a multibranch pipeline and still suffer from this issue.
I have a master slave setup. Which workspaces now need to be shorter than 108? master or slave or both?
Simply doing ws("test") before the image.inside didn't help although the resulting ws path is really short.

Outside of the container git cloning with inside sshagent(..){ works. Inside container it doesn't and the log says:
docker exec 9859e94c20b84efd81e1752417c1f5144fa198ba76b14e1670f8993512af7d60 ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-GoP5qbl4iakN/agent.13
SSH_AGENT_PID=20

```
$ docker exec --env SSH_AGENT_PID=20 --env SSH_AUTH_SOCK=/tmp/ssh-GoP5qbl4iakN/agent.13 9859e94c20b84efd81e1752417c1f5144fa198ba76b14e1670f8993512af7d60 ssh-add /home/INT/jenkins/short@tmp/private_key_3688909095782238252.key
Identity added: /home/INT/jenkins/short@tmp/private_key_3688909095782238252.key (/home/INT/jenkins/short@tmp/private_key_3688909095782238252.key)

```

hermain As Mike and Jesse alluded to, the new Agent implementation was added which is based on the CLI ssh-agent. If you have a CLI available inside the docker container and use the `sshagent` inside the docker.inside() closure, your git clone should work.

Look for the message like "Exec ssh-agent (binary ssh-agent on a remote machine)" or any errors that mention ssh-agent

devopsfido I managed to resolve the issue but this page was offline at the time so I forgot to mention it here:

The problem in my case was that my git was not a known host inside the container:

image.inside("-u root:root --network=host") {
            sshagent(credentials: [config.gitKeyCredentialsId] ) {
                sh "mkdir ~/.ssh"
                sh "ssh-keyscan git.myCompany.com >> ~/.ssh/known_hosts"
               // call scripts that do git clone...
            }
        }

I hope that helps you and anyone else with a similar problem.

Hello, I'm using latest 1.17 version of SSH Agent Plugin and still expirience the same issue.
Although docker image has ssh-agent cmd line command inside - the socket is created under {{/tmp} so it's inaccesisble

eshepelyuk maybe ssh-agent is not in $PATH or something.

hermain Thank you!  This was exactly our issue.

Works with SSH Agent Plugin v1.17 for us, using declarative pipeline and just a regular agent block:

pipeline {
  agent { docker {
    image 'my_build_image'
    ...
  } }
  ...
  stage("foo") {
    sshagent(credentials: [config.gitKeyCredentialsId] ) {
      sh "mkdir ~/.ssh && ssh-keyscan git.myCompany.com >> ~/.ssh/known_hosts"
      // call scripts that do git clone...
    }
  }
}