JSchException: échec de négociation de l'algorithme
J'essaie de me connecter au serveur sftp distant via ssh avec JSch (0.1.44-1) mais pendant "session.connect ();" Je reçois cette exception:
com.jcraft.jsch.JSchException: Algorithm negotiation fail at
com.jcraft.jsch.Session.receive_kexinit(Session.Java:529) at
com.jcraft.jsch.Session.connect(Session.Java:291) at com.jcraft.jsch.Session.connect(Session.Java:154)
...
Journaux de JSch:
INFO: Connecting to xx.xx.xx.xxport 22
INFO: Connection established
INFO: Remote version string: SSH-2.0-WeOnlyDo 2.0.6
INFO: Local version string: SSH-2.0-JSCH-0.1.44
INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
INFO: aes256-ctr is not available.
INFO: aes192-ctr is not available.
INFO: aes256-cbc is not available.
INFO: aes192-cbc is not available.
INFO: arcfour256 is not available.
INFO: SSH_MSG_KEXINIT sent
INFO: SSH_MSG_KEXINIT received
INFO: Disconnecting from xx.xx.xx.xx port 22
Je peux me connecter au serveur distant avec la commande linux sftp. J'essayais de trouver n'importe quel indice sur Internet mais j'ai échoué.
Déboguer la sortie de la commande linux sftp:
OpenSSH_5.5p1-DAM_1.2, OpenSSL 0.9.8r 8 Feb 201
debug1: Reading configuration data /etc/DAM/ssh/ssh_config
debug1: Applying options for *
debug1: Applying options for *.*
debug1: Connecting to xx.xx.xx.xx [xx.xx.xx.xx] port 22.
debug1: Connection established.
debug1: identity file /**/spv_id_rsa.key type -1
debug1: identity file /**/spv_id_rsa.key-cert type -1
debug1: Remote protocol version 2.0, remote software version WeOnlyDo 2.0.6
debug1: no match: WeOnlyDo 2.0.6
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1-DAM_1.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes256-cbc hmac-md5 none
debug1: kex: client->server aes256-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'xx.xx.xx.xx' is known and matches the RSA Host key.
debug1: Found key in ~/.ssh/known_hosts:8
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /**/spv_id_rsa.key
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending subsystem: sftp
Connected to xx.xx.xx.xx.
sftp>
Il y a quelques endroits où les clients et les serveurs SSH essaient de s'entendre sur une implémentation commune. Deux que je connais sont le cryptage et la compression. Le serveur et le client produisent une liste d'options disponibles, puis la meilleure option disponible dans les deux listes est choisie.
S'il n'y a pas d'option acceptable dans les listes, cela échoue avec l'erreur que vous avez obtenue. Je suppose à partir de la sortie de débogage ici, mais il semble que les seules options de serveur pour le chiffrement soient "aes256-cbc hmac-md5 none".
JSch ne fait pas hmac-md5 et aes256-cbc est désactivé à cause de vos fichiers de politique Java. Deux choses que vous pourriez essayer sont ...
Pour augmenter les bibliothèques de chiffrement disponibles sur le serveur, installez des fichiers de stratégie sans restriction sur votre client, en activant aes256-cbc (assurez-vous que le message indiquant qu'il est désactivé disparaît, ces fichiers de stratégie sont notoirement faciles à installer sur la mauvaise machine virtuelle Java) à partir du site :
Pour JDK 1.6: http://www.Oracle.com/technetwork/Java/javase/downloads/jce-6-download-429243.html
Pour JDK 1.7: http://www.Oracle.com/technetwork/Java/javase/downloads/jce-7-download-432124.html
Pour JDK 1.8: http://www.Oracle.com/technetwork/Java/javase/downloads/jce8-download-2133166.html
ou essayez de désactiver le cryptage.
Le premier est idéal si vous avez accès au serveur (croyez-moi, aes128-cbc est beaucoup de cryptage), mais le second est assez facile pour tester rapidement la théorie.
Enfin une solution qui fonctionne sans avoir à apporter de modifications au serveur:
Téléchargez le dernier jsch.jar comme Yvan le suggère: http://sourceforge.net/projects/jsch/files/jsch.jar/ jsch-0.1.52.jar fonctionne bien
Placez le fichier téléchargé dans votre "...\JetBrains\PhpStorm 8.0.1\lib", et supprimez le fichier jsch existant (pour PHPStorm 8 c'est jsch-0.1.50.jar)
Redémarrez PHPStorm et cela devrait fonctionner
Utilisez la même solution pour Webstorm
Les étapes complètes pour ajouter les algorithmes au serveur RECEIVING (celui auquel vous vous connectez). Je suppose que c'est un serveur Linux.
Sudo /etc/ssh/sshd_config
Ajoutez ceci au fichier (cela peut être à la fin):
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
Redémarrez ensuite le serveur SSH:
Sudo service sshd restart
FWIW, j'ai eu ce même message d'erreur sous JSch 0.1.50. La mise à niveau vers 0.1.52 a résolu le problème.
Le problème est lié à la version du pot JSCH que vous utilisez.
Mettez-le à jour avec le dernier pot.
J'obtenais également la même erreur et cette solution a fonctionné.
Vous pouvez télécharger le dernier pot depuis
Assurez-vous que vous utilisez la dernière version de JSch. J'ai eu exactement le même problème lors de l'utilisation de JSch 0.1.31 et de la tentative de connexion à un serveur RedHat 5. La mise à jour vers la dernière version a résolu le problème.
J'ai eu le même problème, en exécutant Netbeans 8.0 sur Windows et JRE 1.7.
Je viens d'installer JRE 1.8 depuis https://www.Java.com/fr/download/ (notez qu'il s'appelle Version 8 mais c'est la version 1.8 lorsque vous l'installez), et il l'a corrigé.
La solution pour moi consistait à installer Oracle JCE illimité et à installer dans JRE_HOME/lib/security. Ensuite, j'ai redémarré glassfish et j'ai pu me connecter à mon serveur sftp en utilisant jsch.
ajoutez KexAlgorithms diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha 1 à votre sshd_config sur le serveur.
Cela a fonctionné, mais assurez-vous de redémarrer sshd: Sudo service sshd restart