Negociación de algoritmo falla SSH en Jenkins

Estoy intentando enviar ssh desde Jenkins a un servidor local, pero se produce el siguiente error:

[SSH] Exception:Algorithm negotiation fail com.jcraft.jsch.JSchException: Algorithm negotiation fail at com.jcraft.jsch.Session.receive_kexinit(Session.java:520) at com.jcraft.jsch.Session.connect(Session.java:286) at com.jcraft.jsch.Session.connect(Session.java:150) at org.jvnet.hudson.plugins.SSHSite.createSession(SSHSite.java:141) at org.jvnet.hudson.plugins.SSHSite.executeCommand(SSHSite.java:151) at org.jvnet.hudson.plugins.SSHBuildWrapper.executePreBuildScript(SSHBuildWrapper.java:75) at org.jvnet.hudson.plugins.SSHBuildWrapper.setUp(SSHBuildWrapper.java:59) at hudson.model.Build$BuildExecution.doRun(Build.java:154) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:533) at hudson.model.Run.execute(Run.java:1754) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) Finished: FAILURE 

Versión instalada de Java en el servidor SSH:

 java version "1.8.0_25" Java(TM) SE Runtime Environment (build 1.8.0_25-b18) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) 

Versión instalada de java en el cliente:

 java version "1.8.0_25" Java(TM) SE Runtime Environment (build 1.8.0_25-b18) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) 

También probé esta solución: JSchException: la negociación del algoritmo falla pero no está funcionando. De masilla todo parece estar bien. La conexión está establecida, pero cuando activa el trabajo de Jenkins se produce el error. Debería probar otra versión del servidor ssh. Ahora estoy usando Copssh.

TL; DR edita tu sshd_config y habilita el soporte para diffie-hellman-group-exchange-sha1 y diffie-hellman-group1-sha1 en KexAlgorithms:

 KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 

Sospecho que el problema apareció después del siguiente cambio en OpenSSH 6.7: “El conjunto predeterminado de cifrados y MAC ha sido alterado para eliminar los algoritmos inseguros”. (ver registro de cambios ). Esta versión fue lanzada el 6 de octubre y llegó a las pruebas de Debian el 21 de octubre (ver el registro de cambios de Debian ).

OpenSSH habilita solo los siguientes algoritmos de intercambio de claves por defecto:

  • curve25519-sha256@libssh.org
  • ecdh-sha2-nistp256
  • ecdh-sha2-nistp384
  • ecdh-sha2-nistp521
  • diffie-hellman-group-exchange-sha256
  • diffie-hellman-group14-sha1

Mientras que JSch afirma que admite estos algoritmos (ver bajo “características”) para el intercambio de claves:

  • diffie-hellman-group-exchange-sha1
  • diffie-hellman-group1-sha1

Entonces, de hecho, no pueden ponerse de acuerdo sobre un algoritmo común de intercambio de claves. La actualización de sshd_config (y el reinicio del servidor SSH) hace el truco. Aparentemente se supone que JSch soporta el método “diffie-hellman-group-exchange-sha256” desde la versión 0.1.50 (ver changelog ).

Como se describe aquí: http://sourceforge.net/p/jsch/mailman/message/32975616/ , en JSch 0.1.51 diffie-hellman-group-exchange-sha256 está implementado, pero no habilitado. Puede habilitarlo usando la función setConfig manera:

 JSch jsch = new JSch(); java.util.Properties configuration = new java.util.Properties(); configuration.put("kex", "diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256"); configuration.put("StrictHostKeyChecking", "no"); Session session = jsch.getSession("username", "hostname", 22); session.setPassword("password"); session.setConfig(configuration); session.connect(); 

Tuvimos el mismo problema con nuestras jenkins (2.21) y el complemento SSH (2.4)

Nuestra solución es usar la ejecución del shell nativ. Parece que los plugins de jenkins no usan la misma configuración de conexión ssh que el shell nativ.

Entonces puedes hacer que el ssh se conecte así (sin el ssh-plugin):

 ssh user@host <<'ENDSSH' echo your remote command here ENDSSH 

Si ajusta sus comandos remotos con el código anterior, la conexión funciona bien.

Con esta solución ya no necesitas el ssh-plugin.

Para su información: obtuvimos el problema en nuestros servidores mittwald ya que actualizaron el openssh en sus servidores.

En mi caso, OpenSSH_6.7p1 en el servidor, tuve que modificar KexAlgorithms y MAC (valores adicionales de hmac-md5, hmac-sha1, hmac-sha1-96, hmac-md5-96):

 KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com,hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96 

Más arriba debe colocarse:

 /etc/ssh/sshd_config 

Y luego reinicia el ssh:

 sudo /etc/init.d/ssh restart 

Me he enfrentado exactamente el mismo problema. AS Matthieu sugirió que tenemos que agregar algún algoritmo de intercambio de claves en el archivo sshd-config presente en cygwin> etc> sshd_config. Acabo de agregar lo siguiente y funcionó para mí,

KexAlgorithms diffie-hellman-group1-sha1, curve25519-sha256 @ libssh.org, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group-exchange-sha256, diffie-hellman-group14 -sha1

Pero el archivo en sí está en modo de solo lectura, así que tenemos que proporcionarle acceso completo, como leer, escribir y ejecutar a través de comandos. “chmode 777 sshd_config”. luego agrega los algoritmos mencionados anteriormente. detenga el servicio sshd a través de “net stop sshd” y luego inícielo “net start sshd”.

Que te diviertas….

Lo único que esto me ayudó.

Si quieres solucionar este problema temporalmente, simplemente descarga “Jsch” con mín. versión de 0.1.53 y moverlo al directorio de complementos SSH, por ejemplo: cp /tmp/jsch-0.1.53.jar / var / lib / jenkins / plugins / ssh / WEB-INF / lib / No olvides reiniciar jenkins. Ahora debería ser capaz de construir su trabajo con Debian Jessie.

https://issues.jenkins-ci.org/browse/JENKINS-25258?focusedCommentId=274232&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-274232

En lugar de arreglar esto en el lado del servidor , también puede actualizar el lado del cliente . Si usa http://maven.apache.org/wagon/wagon-providers/wagon-ssh/ en su última versión (> = 2.12), este problema ya no ocurre.

       org.apache.maven.plugins maven-site-plugin 3.6   org.apache.maven.wagon wagon-ssh 2.12         

También enfrenté el mismo problema con excepciones similares en la consola de Jenkins. Luego probé la solución de Matthieu Wipliez. Pero no funcionó ya que la misma configuración ya estaba hecha en mi servidor SSH (máquina remota: Linux ubuntu 16.04).

Después de pasar algunas horas, simplemente revisé la versión de mi complemento SSH que era 2.1 y la actualicé a la última (2.5).

¡Y adivina lo que funcionó!

No sé si funcionará en todos los casos similares, pero me gustaría sugerir probar primero. Puede ahorrarle tiempo.

Si terminas aquí porque obtienes el mismo error en PyCharm:

Estoy usando 2016.2.3 y solo puedo actualizar si cambio al modelo de suscripción. El problema solo se ve en mi cuadro de Windows. No pude actualizar el servidor remoto como se describe en otras respuestas (KexAlgorithms).

Mi solución es

  1. Haga clic en Ayuda
  2. Seleccione “Buscar acción”
  3. Escriba “Cambiar IDE Boot JDK ..”
  4. Use la flecha desplegable y haga clic en la opción “…”
  5. Encuentre la versión de JAVA que está usando en su máquina local y seleccione esa carpeta.

PyCharm se reinicia y puedo enviar ssh a servidores remotos.