Agent Failed to launch on target machine, failing at showing environment

I just updated my Jenkins to 2.387.2 not long ago, and was trying to configure another Windows PC as a agent node, which I have successfully setup as a agent node a year ago. Right now, the agent won’t even launch on that target PC.

SSHLauncher{host=‘gt-crunch-dev.itsgames.com’, port=22, credentialsId=‘gt-crunch-dev-itam-ssh-cred’, jvmOptions=‘’, javaPath=‘’, prefixStartSlaveCmd=‘’, suffixStartSlaveCmd=‘’, launchTimeoutSeconds=60, maxNumRetries=10, retryWaitTime=15, sshHostKeyVerificationStrategy=hudson.plugins.sshslaves.verifiers.NonVerifyingKeyVerificationStrategy, tcpNoDelay=true, trackCredentials=true} [04/06/23 18:20:29] [SSH] Opening SSH connection to gt-crunch-dev.itsgames.com:22. [04/06/23 18:20:30] [SSH] WARNING: SSH Host Keys are not being verified. Man-in-the-middle attacks may be possible against this connection. [04/06/23 18:20:30] [SSH] Authentication successful. java.io.IOException: The execute request failed. at com.trilead.ssh2.channel.ChannelManager.requestExecCommand(ChannelManager.java:776) at com.trilead.ssh2.Session.execCommand(Session.java:313) at com.trilead.ssh2.Connection.exec(Connection.java:1475) at hudson.plugins.sshslaves.SSHLauncher.verifyNoHeaderJunk(SSHLauncher.java:599) at hudson.plugins.sshslaves.SSHLauncher.lambda$launch$0(SSHLauncher.java:436) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829) Caused by: java.io.IOException: The server denied the request. at com.trilead.ssh2.channel.ChannelManager.requestExecCommand(ChannelManager.java:772) … 8 more [04/06/23 18:20:30] Launch failed - cleaning up connection [04/06/23 18:20:30] [SSH] Connection closed.

From the log itself, it looks like the authentication went through, but it fails when it usually should be displaying the environment, or perhaps a bit earlier than that?

Does anyone know what command was being used to obtain and display the environment? How do we find out what “The execute request failed” is about?

Some more detailed information on the setup:

  1. Jenkins is 2.387.2
  2. Launch methods is “Launch agent via SSH”
    ** Credentials uses “Username and Password”, of a local account on the target PC
    ** Host Key Verification Strategy is “Non verifying Verification Strategy”
  3. The Jenkins Server runs an a Windows VM on ESXi
  4. I can connect to the Target PC from the Jenkins Server through an SSH session with the same credentials with no issues
  5. The local account has Full Control permission of the Root Directory on the Target PC
  6. Target PC’s Java is OpenJDK 11.0.18+10

[EDIT 2023/4/6]
After some digging and testing, it appears that Jenkins was attempting to use the “SET” command to output the target’s environment info, but got rejected and threw an exception.
If I manually start an SSH session and run the SET command, the enviornment variables get displayed okay.
Some notable ones of interests:

C:\Users\itamautomation>set
COMPUTERNAME=XXXX-DEV
ComSpec=C:\WINDOWS\system32\cmd.exe
HOMEDRIVE=C:
JAVA_HOME=C:\Java\OpenLogic-jdk-11.0.18.10-hotspot\
...
SHELL=c:\windows\system32\cmd.exe
SSH_CLIENT=10.118.100.210 54723 22
SSH_CONNECTION=10.118.100.210 54723 10.118.100.226 22
SSH_TTY=windows-pty
SystemDrive=C:
SystemRoot=C:\WINDOWS

How does Jenkins run the “SET” command on the agent target differently from manually running this in an interactive SSH session?

Here’s an update. After I changed the permission of the Jenkins Root folder to grant the local account “Modify > Allow” permission, and then reboot the VM, the agent can launch properly.
This issue came back a few more times, but after rebooting the VM, the agent will again launch correctly.

But then after a month, my Jenkins got updated to 2.387.3, and I’m starting to see the agent failing to launch again with the same error.

What exactly is causing this issue to show up? Should I try to add a Host Key Verification Strategy?