Fixed end of substring in getAgentValue

[aralex]

Fixed end of substring in getAgentValue. Otherwise the following error may occour:

[Pipeline] End of Pipeline
Also:   org.jenkinsci.plugins.workflow.actions.ErrorAction$ErrorId: f2e82224-14bd-4013-bd9e-f7f08a73c6c5
java.lang.StringIndexOutOfBoundsException: begin 13, end -1, length 0
	at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4601)
	at java.base/java.lang.String.substring(String.java:2704)

I found it in job on Windows agent.

[jglick]

What is the text output that was misparsed on Windows? This looks like something that would benefit from test coverage.

[aralex]

What is the text output that was misparsed on Windows? This looks like something that would benefit from test coverage.

I don't know how to view the problem text. I thought to rebuild this java-file but I have no experience for it.

[aralex]

This is the bigger log piece:

Also:   org.jenkinsci.plugins.workflow.actions.ErrorAction$ErrorId: f2e82224-14bd-4013-bd9e-f7f08a73c6c5
java.lang.StringIndexOutOfBoundsException: begin 13, end -1, length 0
	at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4601)
	at java.base/java.lang.String.substring(String.java:2704)
	at com.cloudbees.jenkins.plugins.sshagent.exec.ExecRemoteAgent.getAgentValue(ExecRemoteAgent.java:146)
	at com.cloudbees.jenkins.plugins.sshagent.exec.ExecRemoteAgent.parseAgentEnv(ExecRemoteAgent.java:130)
	at com.cloudbees.jenkins.plugins.sshagent.exec.ExecRemoteAgent.<init>(ExecRemoteAgent.java:57)
	at com.cloudbees.jenkins.plugins.sshagent.SSHAgentStepExecution.initRemoteAgent(SSHAgentStepExecution.java:121)
	at com.cloudbees.jenkins.plugins.sshagent.SSHAgentStepExecution.start(SSHAgentStepExecution.java:35)

I would try to check the command manually. What command should I enter?

[jglick]

ssh-agent-plugin/src/main/java/com/cloudbees/jenkins/plugins/sshagent/exec/ExecRemoteAgent.java

Lines 52 to 57 in 95d6ea2

	if (launcher.launch().cmds("ssh-agent").stdout(baos).start()
	.joinWithTimeout(1, TimeUnit.MINUTES, listener) != 0) {
	String reason = new String(baos.toByteArray(), StandardCharsets.US_ASCII);
	throw new AbortException("Failed to run ssh-agent: " + reason);
	}
	agentEnv = parseAgentEnv(new String(baos.toByteArray(), StandardCharsets.US_ASCII), listener); // TODO could include local filenames, better to look up remote charset

so just try running ssh-agent on your agent machine and see what format the output is in.

[aralex]

When I just run ssh-agent it prints nothing.

[aralex]

I'm trying to work with Windows Server 2019. SSH agent works as a service there. And ssh-agent command does return nothing.

[aralex]

I understood the problem! Two versions of OpenSSH agents are present on My builder node: OSS version (in C:\Program Files\Git\usr\bin) and Microsoft's vesion (in C:\Windows\System32\OpenSSH\ssh-agent.exe). This plugin runs Microsoft's vesion by default, because OSS version isn't avaliable via PATH environment variable.

I modified PATH in My pipeline, but obtained the same result :-(

Don't the plugin use PATH environment variable to run ssh-agent?

[jglick]

Don't the plugin use PATH environment variable to run ssh-agent?

ssh-agent-plugin/src/main/java/com/cloudbees/jenkins/plugins/sshagent/SSHAgentStepExecution.java

Lines 102 to 121 in 107d246

	Launcher launcher = getContext().get(Launcher.class);
	TaskListener listener = getContext().get(TaskListener.class);
	Run<?, ?> build = getContext().get(Run.class);
	FilePath workspace = getContext().get(FilePath.class);
	List<SSHUserPrivateKey> userPrivateKeys = new ArrayList<>();
	for (String id : new LinkedHashSet<>(step.getCredentials())) {
	final SSHUserPrivateKey c = CredentialsProvider.findCredentialById(id, SSHUserPrivateKey.class, build);
	CredentialsProvider.track(build, c);
	if (c == null && !step.isIgnoreMissing()) {
	throw new AbortException(Messages.SSHAgentBuildWrapper_CredentialsNotFound(id));
	}
	if (c != null && !userPrivateKeys.contains(c)) {
	userPrivateKeys.add(c);
	}
	}
	for (SSHUserPrivateKey userPrivateKey : userPrivateKeys) {
	listener.getLogger().println(Messages.SSHAgentBuildWrapper_UsingCredentials(SSHAgentBuildWrapper.description(userPrivateKey)));
	}
	agent = new ExecRemoteAgent(launcher, listener);

does not currently pay attention to Pipeline overrides with withEnv('PATH+EXTRA=…') {…}. It could be made to do so I suppose, just never came up. If you fix the path for java -jar agent.jar that would be honored.

Not sure what Microsoft’s version of the tool does, if it is not printing anything. Would be nice if the plugin automatically detected this tool and at least failed with a clear error.

[jglick]

Closing as this does not seem like a fix for the actual issue, though some improvements as mentioned above would be helpful.

[HannesWell]

I understood the problem! Two versions of OpenSSH agents are present on My builder node: OSS version (in C:\Program Files\Git\usr\bin) and Microsoft's vesion (in C:\Windows\System32\OpenSSH\ssh-agent.exe). This plugin runs Microsoft's vesion by default, because OSS version isn't avaliable via PATH environment variable.

Do you think a solution would be to run the ssh-agent included in a (c)git installation for Windows?

If yes, this plugin could look up the git installation if it detects to run on Windows e.g. by using where git (from a Windows cmd shell). It seems to be common that this returns C:\Program Files\Git\cmd\git.exe.
Running where ssh-agent from the git-bash on Windows then usually returns:

$ where ssh-agent
C:\Program Files\Git\usr\bin\ssh-agent.exe
C:\Windows\System32\OpenSSH\ssh-agent.exe

So this plugin maybe could append ..\..\usr\bin\ssh-agent.exe to the path(s) returned by where git and check if that executable exists and use that instead of the default Windows (service) ssh-agent?

[jglick]

This plugin does nothing all that special. If you run into any issues, just stop using it and run ssh-agent directly, or more commonly simply pass some option like -i to whatever command needs a private key.

[HannesWell]

This plugin does nothing all that special. If you run into any issues, just stop using it and run ssh-agent directly, or more commonly simply pass some option like -i to whatever command needs a private key.

That's relatable, but at the same time it's also not a satisfactory situation from a users perspective if this plugin doesn't work on Windows at all (as far as I understand it), while there is a possible solution. Furthermore it's currently not easy to understand what the issue actually is.
I have now created a proposal that worked at least for me locally:

• Support execution on Windows by using ssh-agent provided by git #169