Programmer algorithm practice must read, common Java API skills to share>>>

Recently, a requirement used the SFTP upload function. My colleagues have already packaged the SFTP tool class and used jsch. In the idea of not making wheels repeatedly, they directly used it. The JDK version is 1.7 and jsch version is 0.1.51. The self-test passed and the test environment was ok, but when it came to the production environment, it threw an algorithm negotiation fail exception, which was immediately silly. The following is the specific exception information:

com.jcraft.jsch.JSchException:Algorithmnegotiationfail
atcom.jcraft.jsch.Session.receive_ kexinit(Session.java:583)~[jsch-0.1.51.jar:na]
atcom.jcraft.jsch.Session.connect(Session.java:320)~[jsch-0.1.51.jar:na]

What’s more, it’s successful to connect to the server side with the Linux command SFTP (refer to the FTP and SFTP commands under Linux for details) under the local side (client side), and it can also upload. First of all, the reasons such as wrong user name/password, network congestion, and not adding white list are eliminated. Then I think about the problem of the program itself, but why are the development environment and test environment all right?Is it an environmental problem?Use the SSH – V command to view the SSH version. The local end and the opposite end of the test environment and the local end of the production environment are “openssh”_ 3 P1, OpenSSL 1.0.0-fips 29 Mar 2010 “, but the opposite end of the production environment is” openssh “_ 6.7p1, OpenSSL 1.0.1e-fips 11 Feb 2013”。 It seems that it’s really an environmental problem

Calm down and return to the exception algorithmnegotiation fail, which means that the algorithm negotiation failed. Check the jsch source code, the exception occurred in the connect phase. Search information on the Internet (introduction of SSH protocol). It is found that one of the five stages of SSH communication process is the key and algorithm negotiation stage. In this stage, the two sides negotiate the final algorithm according to the algorithm supported by the local end and the opposite end. That’s where the problem should be. Different versions of openssh in 5.3 and 6.7 have different default algorithm lists, which leads to the failure of algorithm negotiation. Refer to com.jcraft.jsch.jschexception: algorithm negotiation fail

So how can we know the default algorithm list of different versions of openssh?What’s openssh default kexalgorithms?Through the SSH – VVV ServerIP command, as shown in the figure below:

Among them, 1 and 2 are the default kexalgorithms of openssh version 5.3 and 6.7, respectively. You can see that the diffie-hellman-group1-sha1 and diffie-hellman-group-exchange-sha1 algorithms supported by (native) openssh 5.3 are no longer in the default list of (opposite) openssh 6.7

It turns out that after the SSH upgrade, some of the original encryption algorithms are no longer used by default for security. Since there is no original encryption algorithm, you can add it manually. Please refer to this blog Edit /etc/sshd_ Config, plus kexalgorithms diffie-hellman-group1-sha1, curve25519- [email protected] ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1

Restart service sshd

Just when I thought it could be done, my colleagues at the opposite end (because I was connected to their SFTP server, so they did the above adding and modifying work) said that there was an error when restarting the service after the modification:

A289885427 because the server is not on my side, I can’t debug it myself, so I have no choice

Finally, I’m not willing to upload it manually every day. I went to jsch’s official website to have a look, but I got something. I found it in its changelog

Changes since version 0.1.52:
- bugfix: the rekey initiated by the remote may crash the session.

This is to fix the bug that “the key update initiated remotely may crash the session”. This is the problem I encountered. I upgraded the jsch version to the latest 0.1.53, which can be uploaded successfully. The problem is solved