In order to have an agent to connect to the controller with JNLP we have used the following contstruct to connect to the controlelr to get the secret key:
Basically, this is a Jenkins CLI call over SSH and it has worked soince long time ago, and still works in our RHEL7 environment. But we also have a new RHEL 8 system, which is under construction, where this call returns nothing starting with version 2.427.
Is this somethingh thsthar been turned off on purpose, e.g. for security reasons, or can it be a configuration error, or is it a bug in Jenkins 2.427?
The configuraiton is identical with both the RHEL7 system and ad the THEL8 system was configured before the 1.427 version was installed.
By extracting the code from the actual startup script, I get the following command and the result:
$ drskv ssh -p 38397 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i /opt/jenkins/etc/id_rsa drskv@u42163.jenk.utv.test.skv.se groovy = <<EOF
println hudson.model.Hudson.instance.getComputer("u42071.zv.utv.test.skv.se").getJnlpMac()
EOF
Warning: Permanently added '[u42163.jenk.utv.test.skv.se]:38397,[10.33.130.119]:38397' (RSA) to the list of known hosts.
$
Before the upgrade to 2.427, I got the following result:
$ ssh -p 38397 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i /opt/jenkins/etc/id_rsa drskv@u42163.jenk.utv.test.skv.se groovy = <<EOF
println hudson.model.Hudson.instance.getComputer("u42071.zv.utv.test.skv.se").getJnlpMac()
EOF
Warning: Permanently added '[u42163.jenk.utv.test.skv.se]:38397,[10.33.130.119]:38397' (RSA) to the list of known hosts.
ec43713362ba717e699dbd9b8698383312bae97c220bea19c93d3e2e04cc3277
$
Jenkins setup:
jenkins version 2.247
OS RedHat Enterprise Linux release 8.8 (Ootpa)
4.18.0-477.10.1.el8_8.x86_64
What is the Jenkins version still running fine on your RHEL7 machine?
As of Jenkins version 2.176, I think Jenkins implemented security hardening to prevent the use of JNLP agents via SSH without proper authentication and authorization.
I also think the call getJnlpMac() was made inaccessible from the script console to improve security.
This was to prevent attackers from remotely triggering agents on Jenkins without proper authentication.
2.428 works fine in RHEL7. I find it very strange that the behaviour is different depending on wether the program runs in RHEL7 or RHEL8, but that’s how it is. Jenkins’s support of RHEL7 is at sunset and therefore is the RHEL8 environment our new target.
If the access was removed in the newer versions, there should at least be be a notice in the changelog, but I haven’t found anything like that.
If the access is removed intentionally, it would mean a great extra work for us, we have about 160 jenkins instances running that together use almost 650 agents that each one of them are started using this method, and it is not mangeable to manually fetch the server secret and put it on each of those agent servers, which would have to be done if any of them are rebooted.
Some more information: After further research, it does not work in RHEL7 either with 2.427 and 2.428. However, the agents seems to connect to the controller despite the lack of the secret string, so I did not see that it was a problem before.
But all versions I have tested up to, and including, 2.426 works in both RHEL7 and RHEL8.
I tries an alternative call, which I believe is slightly more modern (“Jenkins” instead of “Hudfson”):
println jenkins.model.Jenkins.get().getComputer("u42071.zv.utv.test.skv.se").getJnlpMac()
skriv eller klistra in din kod här
I had a hope that this more modern code would work better, but unfortunately not.
btw, in my original code there is a typo in one of my code examples. One command starts with the word “drskv”, which should not be there. The cause is a badly made copy when I wrote the message. The actual call in my script is
sudo -u drskv ssh ...
That user is the user account that is being used for these calls, and the one that holds the ssh credentials for the call, but I thought that it was irrelevant for the problem. Unfortunately, i copied one extra word.
The script is also run in two different servers, on server connected to a controller using jenkins 2.428 and one using version 2.426 (the one that is working). Hence the different parameters to the getComputer() method.
Yet another update: I found a workaround, which was actually the reason why it worked better in my RHEL7 environment:
If I allow “Anonymous” to connect in the security matrix settings, the agent can connect to the controller without using the secret. However, this is a bit less secure.
