web-dev-qa-db-fra.com

La négociation d'algorithme échoue SSH dans Jenkins

J'essaie de passer de Jenkins à un serveur local mais l'erreur suivante est générée:

[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

Version installée de Java sur le serveur 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)

Version installée de Java sur le client:

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)

Nous avons également essayé cette solution: JSchException: la négociation de l’algorithme échoue , Mais elle ne fonctionne pas. Depuis PuTTY, tout semble aller pour le mieux. La connexion est établie mais lorsque je déclenche le travail Jenkins, l'erreur est renvoyée. Devrais-je essayer une autre version du serveur SSH. Maintenant j'utilise copssh.

javasshjenkinsjsch
32
sarbo

TL; DR modifiez votre sshd_config et activez la prise en charge de diffie-hellman-group-exchange-sha1 et de diffie-hellman-group1-sha1 dans KexAlgorithms:

KexAlgorithms [email protected],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

Je soupçonne que le problème est apparu après la modification suivante dans OpenSSH 6.7: "L'ensemble de chiffrements par défaut et de codes MAC a été modifié pour supprimer les algorithmes dangereux.". (voir changelog ). Cette version est sortie le 6 octobre et a été testée le 21 octobre (voir Debian changelog ).

OpenSSH n'active par défaut que les algorithmes d'échange de clés suivants:

  • [email protected]
  • ecdh-sha2-nistp256
  • ecdh-sha2-nistp384
  • ecdh-sha2-nistp521
  • diffie-hellman-group-exchange-sha256
  • diffie-hellman-group14-sha1

Alors que JSch prétend prendre en charge ces algorithmes (voir sous "caractéristiques") pour l'échange de clés:

  • diffie-hellman-group-exchange-sha1
  • diffie-Hellman-Group1-Sha1

Donc, en effet, ils ne peuvent pas se mettre d’accord sur un algorithme commun d’échange de clés. La mise à jour de sshd_config (et le redémarrage du serveur SSH) fait l'affaire. Apparemment, JSch est supposé supporter la méthode "diffie-hellman-group-exchange-sha256" depuis la version 0.1.50 (voir changelog ).

63
Matthieu Wipliez

Nous avons eu le même problème avec nos jenkins (2.21) et le plugin SSH (2.4)

Notre solution consiste à utiliser l'exécution du shell nativ. Il semble que les plugins jenkins n'utilisent pas les mêmes paramètres de connexion ssh que le shell nativ. 

Pour que le ssh se connecte comme ceci (sans le plugin ssh): 

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

Si vous enveloppez vos commandes à distance avec le code ci-dessus, la connexion fonctionne correctement. 

Avec cette solution, vous n’avez plus besoin du plug-in ssh. 

Pour votre information: Nous avons eu le problème sur nos serveurs mittwald depuis qu'ils ont mis à jour OpenSh sur leurs serveurs. 

6
bschauer

Comme indiqué ci-dessous: http://sourceforge.net/p/jsch/mailman/message/32975616/ , dans JSch 0.1.51, diffie-hellman-group-exchange-sha256 est implémenté mais n'est pas activé. Vous pouvez l'activer en utilisant la fonction setConfig comme ceci:

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();
6
Nielsvh

Dans mon cas - OpenSSH_6.7p1 sur le serveur - je devais modifier les KexAlgorithms et les MAC (valeurs hmac-md5, hmac-sha1, hmac-sha1-96, hmac-md5-96 supplémentaires):

KexAlgorithms [email protected],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 [email protected],[email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,[email protected],hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96

Ci-dessus devrait être mis en place:

/etc/ssh/sshd_config

Et puis redémarrez le ssh:

Sudo /etc/init.d/ssh restart
4
wierzbiks

J'ai été confronté exactement au même problème ... comme Matthieu a suggéré que nous devions ajouter un algorithme d'échange de clés dans le fichier sshd-config présent dans cygwin> etc> sshd_config . Je viens juste d'ajouter ce qui suit et cela a fonctionné pour moi,

KexAlgorithms diffie-hellman-group1-sha1, curve25519-sha256 @ libssh.org, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffd-hellman-groupe-sha256, diffie-hellman-groupe-sha256, diffie-hellman-groupe-sha256 -sha1

Mais le fichier lui-même est en lecture seule et nous devons donc lui fournir tous les accès tels que lecture, écriture et exécution via la commande Invite. "chmode 777 sshd_config" . puis ajoutez les algorithmes mentionnés ci-dessus. arrêtez le service sshd via "net stop sshd" puis lancez-le "net start sshd".

S'amuser....

2
Eagle

Le seul que cela m'a aidé.

Si vous souhaitez résoudre temporairement ce problème, téléchargez simplement "Jsch" avec min. version 0.1.53 et déplacez-le dans le répertoire du plug-in SSH, pour exemple: cp /tmp/jsch-0.1.53.jar/var/lib/jenkins/plugins/ssh/WEB-INF/lib/N'oubliez pas de redémarrer Jenkins. Vous devriez maintenant pouvoir construire votre travail avec Debian Jessie.

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

1
4xy

Au lieu de corriger ceci du côté serveur, vous pouvez également mettre à jour le côté client. Si vous utilisez http://maven.Apache.org/wagon/wagon-providers/wagon-ssh/ dans une version plus récente (> = 2.12 - la version actuelle en date de sept. 2018 est 3.2.0), ceci le problème ne se produit plus.

<project>
  <!-- ... -->
  <build>
    <pluginManagement>
      <plugins>
        <plugin>
          <groupId>org.Apache.maven.plugins</groupId>
          <artifactId>maven-site-plugin</artifactId>
          <version>3.6</version>
          <dependencies>
            <dependency>
              <groupId>org.Apache.maven.wagon</groupId>
              <artifactId>wagon-ssh</artifactId>
              <version>3.2.0</version>
            </dependency>
          </dependencies>
        </plugin>
      </plugins>
    </pluginManagement>
  </build>
  <!-- ... -->
</project>

Mise à jour 2018-10-21: La dernière version est maintenant la 3.2.0. En raison de divers problèmes de vulnérabilité, je vous conseillerais de utilisez toujours une version actuelle du logiciel associé à SSH ou SSL} malgré tout . Vérifiez et mettez à jour vos dépendances dans votre code.

1
Alexander

Si vous vous retrouvez ici parce que vous obtenez la même erreur dans PyCharm - 

J'utilise 2016.2.3 et je ne peux effectuer la mise à niveau que si je convertis au modèle d'abonnement. Le problème ne se voit que sur ma machine Windows. Je n'ai pas pu obtenir le serveur distant mis à jour comme décrit dans d'autres réponses (KexAlgorithms).

Ma solution est 

  1. Cliquez sur Aide
  2. Sélectionnez "Rechercher une action"
  3. Tapez "Switch IDE Boot JDK .."
  4. Utilisez la flèche déroulante et cliquez sur l'option "..."
  5. Recherchez la version de Java que vous utilisez sur votre ordinateur local et sélectionnez ce dossier. 

PyCharm redémarre et je parviens à ssh sur des serveurs distants.

0
FineJ

J'ai également rencontré le même problème avec des exceptions similaires sur la console Jenkins. Puis j'ai essayé la solution de Matthieu Wipliez. Mais cela ne fonctionnait pas car la même configuration avait déjà été effectuée sur mon serveur SSH (Machine distante: Linux Ubuntu 16.04).

Après avoir passé quelques heures, je viens de vérifier la version 2.1 de mon plugin SSH et je l’ai mise à jour à la dernière (2.5). 

Et devinez ce que ça a marché !!

Je ne sais pas si cela fonctionnera dans tous les cas similaires, mais je voudrais suggérer de l'essayer d'abord. Cela peut vous faire gagner du temps.

0
Amey Deshmukh