Status: Resolved (View Workflow)
Jenkins 1.647, ssh-slaves-plugin 1.10
The supported macs and kex methods in trilead are severely outdated, resulting in connection issues with properly secured ssh daemons on target machines. For instance:
sshd: fatal: no matching mac found: client hmac-sha1-96,hmac-sha1,hmac-md5-96,hmac-md5 server hmac-sha2-256,hmac-sha2-512,firstname.lastname@example.org,hmac-ripemd160 [preauth]
In JENKINS-14709 a suggestion is made to replace trilead with orion, but Orion is not being maintained either. Orion refers to Ganymed, but even that hasn't been looked at for almost 2 years: Ganymed commits. It does seem to support hmac-sha2 macs though.
The ssh credentials plugin is unable to connect to slaves that have newer algorithms
The keys from Jenkins (client) and slave (server below) have:
fatal: no matching mac found: client: hmac-sha1-96,hmac-sha1,hmac-md5-96,hmac-md5 server: email@example.com,firstname.lastname@example.org,email@example.com,hmac-sha2-512,hmac-sha2-256,firstname.lastname@example.org [preauth]
Jenkins yields a trace:
[06/22/15 14:49:05] [SSH] Opening SSH connection to 10.68.16.150:22. Key exchange was not finished, connection is closed. ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins. java.lang.IllegalStateException: Connection is not established! at com.trilead.ssh2.Connection.getRemainingAuthMethods(Connection.java:1030) at com.cloudbees.jenkins.plugins.sshcredentials.impl.TrileadSSHPublicKeyAuthenticator.getRemainingAuthMethods(TrileadSSHPublicKeyAuthenticator.java:88) at com.cloudbees.jenkins.plugins.sshcredentials.impl.TrileadSSHPublicKeyAuthenticator.canAuthenticate(TrileadSSHPublicKeyAuthenticator.java:80) at com.cloudbees.jenkins.plugins.sshcredentials.SSHAuthenticator.newInstance(SSHAuthenticator.java:207) at com.cloudbees.jenkins.plugins.sshcredentials.SSHAuthenticator.newInstance(SSHAuthenticator.java:169) at hudson.plugins.sshslaves.SSHLauncher.openConnection(SSHLauncher.java:1173) at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:701) at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:696) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) [06/22/15 14:49:06] Launch failed - cleaning up connection [06/22/15 14:49:06] [SSH] Connection closed.
On our slaves we would like to have hmac-sha2-512 / hmac-sha2-256 but that is not supported by Trilead SSH.
JENKINS-31549 sshcredentials via trilead-ssh2 Cannot Connect to Servers Requiring Strong MACs
- is duplicated by
JENKINS-36873 ssh credentials does not support newer MAC/KEX algos due to outdated trilead-ssh2
- is related to
JENKINS-26379 Jenkins - ssh connection exception
JENKINS-26495 SSH Key Exchange not finished
JENKINS-39805 Remove unsafe cyphers of SSHD module
JENKINS-44046 Git SSH connection issues with Jenkins 2.58
- links to
I see the same issue when I connect the clean Ubuntu Server 14.04.4 LTS with the latest openssh-server from the update center
In my case I had to weaken the security settings and to use the common RSA algorithm
I used another fork of Trilead ssh2 instead which has sha256 implemented.
it's called ConnectBot sshlib. available on GitHub. https://github.com/connectbot/sshlib
I have added a trace / some details from the duplicate task I have filled
JENKINS-36873. As I understand it that Java installation is stall/no more updated by upstream and Jenkins core provides its own fork. Looks like the proper way to fix it would be to remove Trilead entirely and switch to another SSH implementation. Maybe Bouncy Castle?
The workaround is to configure the slaves with some outdated algorithms supported by Trilead
Our bug for my own reference https://phabricator.wikimedia.org/T103351
Couldn't find a similar issue when I created this one, but apparently it did exist.
Having this same issue in Jenkins 2.x and SSH plugin 1.11.
Our problem is the key exchange when checking out SVN repos.
Has anyone found a working solution to this issue that doesn't involve changing accepted ciphers on the slaves?
From what I see "no". Kohsuke was just a default assignee, but he rarely works on plugins now. Removed the assignee
A few various pull requests have been sent. Seems the active one is now https://github.com/jenkinsci/trilead-ssh2/pull/14 proposed by Michael Clarke (assignee of this task).
Code changed in jenkins
User: Michael Clarke
Merge pull request #14 from jenkinsci/SHA256-and-SHA512-HMAC-support
JENKINS-33021 Add support for SHA256 and SHA512 HMAC algorithms
Resolving the issue as a new trilead-ssh2 release has been done with ^^ change. All that needs doing is jenkins to be updated now.
You can follow progress here:
Edit: removed message about failure to patch Jenkins with the new trilead library. Building Jenkins from source with the new trilead library did work.
Code changed in jenkins
User: Michael Clarke
Bump Trilead version to receive a number of security enhancements
JENKINS-41606 JENKINS-33021 JENKINS-26379 JENKINS-31549
Thank you Michael Clarke ! That works perfectly and we use:
server: email@example.com,firstname.lastname@example.org,email@example.com,hmac-sha2-512,hmac-sha2-256,firstname.lastname@example.org [preauth]
This is a critical issue for us, because our security policy dictates that we must have quite strict ssh cipher settings configured to all our ssh servers.