Signature length is incorrect: received 127, but expected 128

Question

I had a strange problem after updating java 1.8. I use jsch-0.1.54.jar in one of our utilities to download files from different places. This particular utility was used for almost 4-5 years without any problems (then it was jsch-0.1.48). At that time, the environment was java 1.6. We recently upgraded to java 1.8, and as a result, we updated this special utility. Now we are faced with some strange problem, and this happens sometimes, and most of the time downloading files is a prefect.

Error log

INFO: SSH_MSG_KEXDH_INIT sent INFO: expecting SSH_MSG_KEXDH_REPLY INFO: Disconnecting from SRV2000 port 22 2016-10-28 08:42:18:0576 ERROR [main] net.AerisAbstractMethod - Failed to open connection com.jcraft.jsch.JSchException: Session.connect: java.security.SignatureException: Signature length not correct: got 127 but was expecting 128 at com.jcraft.jsch.Session.connect(Session.java:565) at com.jcraft.jsch.Session.connect(Session.java:183) at com.aeris.net.AerisSFTPMethod.connectToServer(AerisSFTPMethod.java:65) at com.aeris.net.AerisAbstractMethod.getListOfFiles(AerisAbstractMethod.java:143) at com.aeris.worker.AerisUploaderDownloader.performUploadDownloadListing(AerisUploaderDownloader.java:112) at com.aeris.main.AerisCommonSftpUtility.main(AerisCommonSftpUtility.java:102) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.simontuffs.onejar.Boot.run(Boot.java:340) at com.simontuffs.onejar.Boot.main(Boot.java:166) 

Success log: (in most cases, it is success)

 INFO: SSH_MSG_KEXDH_INIT sent INFO: expecting SSH_MSG_KEXDH_REPLY INFO: ssh_rsa_verify: signature true WARN: Permanently added 'SRV2000' (RSA) to the list of known hosts. INFO: SSH_MSG_NEWKEYS sent INFO: SSH_MSG_NEWKEYS received INFO: SSH_MSG_SERVICE_REQUEST sent INFO: SSH_MSG_SERVICE_ACCEPT received INFO: Authentications that can continue: publickey,password,keyboard-interactive INFO: Next authentication method: publickey INFO: Authentication succeeded (publickey). 2016-10-28 08:36:48:0794 INFO [main] net.AerisAbstractMethod - Session connected to server 2016-10-28 08:36:48:0794 INFO [main] net.AerisAbstractMethod - Opening SFTP channel.. 2016-10-28 08:36:48:0810 INFO [main] net.AerisAbstractMethod - Connecting to server through channel. 2016-10-28 08:36:48:0857 INFO [main] net.AerisAbstractMethod - Connection successful. 2016-10-28 08:36:48:0857 INFO [main] net.AerisAbstractMethod - Changing to directory:C:/interfaces/ib/wf/work 2016-10-28 08:36:48:0888 INFO [main] net.AerisAbstractMethod - Start file Listing of the remote directory:C:/interfaces/ib/wf/work 0 Oct 28, 2016 04:15 ./ 0 Oct 28, 2016 04:15 ../ 

I did a full analysis with Vandyke (sftp software provider), but found no errors for this purpose. I also tried using sftp with various tools, but I am not getting any errors. Below is a snippet of code for connecting an SFTP server. Can anyone help on this?

 protected void connectToServer() throws AerisConnectionException { JSch jSch =(JSch)this.client; try { session = jSch.getSession(config.getUsername(), config.getRemoteserver(), config.getPort()); LOGGER.info("Creating SSH Session using Username:"+config.getUsername()+ " Server :" +config.getRemoteserver()+ " at PORT:"+config.getPort()); if(config.getAuth().equalsIgnoreCase("PASSWD")||config.getAuth().equalsIgnoreCase("KEYPASS")){ LOGGER.info("Setting password ..."); session.setPassword(config.getPassword()); } Properties jShconfig = new Properties(); jShconfig.put("StrictHostKeyChecking", "no"); jShconfig.put("PreferredAuthentications", "publickey,password,keyboard-interactive"); jShconfig.put("LogLevel", "VERBOSE"); LOGGER.info("Setting timeout to "+config.getTimeOut()); session.setTimeout(config.getTimeOut()*1000); session.setConfig(jShconfig); session.connect(); LOGGER.info("Session connected to server"); this.connected=true; } catch (JSchException e) { LOGGER.error("Failed to open connection ",e); throw new AerisConnectionException("Failed to open connection."); } } 

Answer 1

Although it would be nice if the stack confirmed, I bet that the server uses the RSA master key for authentication and mistakenly truncates, leading zero in rare cases.

RSA signature values ​​(and encrypted values ​​as well) defined by PKCS # 1 that SSH uses (like many other things, including SSL) should be encoded as a fixed-length octet string "k" equal to the length required to encode the module, or informally "the same size as the module." However, since the underlying mathematical value is a large non-negative integer (unsigned), in particular modexp (s, d, n), historically some implementations are omitted by leading zero octets - an omission that is valid when processing the value as an integer - - the result is an encoded value that is sometimes shorter than it should be.

The RSA signature (or encrypted) is actually a uniform random number in (1, n). Thus, when the RSA key used by the server has a round binary size, for example 1024, this trimming will be approximately 1 to 200 times randomly , or 400 if truncated as a signed number.

I did not know, but when testing, I confirm that (Oracle) Java 6 really takes such a “short” value for Signature type RSA or as SHA1withRSA actually used here, both of which imply PKCS1-v1_5, but Java 7 and 8 throw an exception which you saw. OTOH, both OpenSSH and PuTTY (also used by WinSCP and FileZilla) accept "short" values, always sending the correct length values; this post-Elian behavior can make it difficult to detect when a peer partner is behaving so badly. (Note: I checked OpenSSH 5.5 and 7.3, the oldest and newest of them at my fingertips, but only the current PuTTY 0.67, because everything I keep on the network.)

You can try to tell the server software developer of the published standards, but this may not be useful. You might ask jcraft about a special occasion; they already have logic in the DSA and ECDSA cases for mpint / ASN.1, which, as I can argue, are equally ugly. Or , if the server has another (useful) key, request by setting "server_host_key" to NOT include ssh-rsa - the easiest way is to get the existing / default list, split, delete "ssh-rsa" (and check not empty) and reunite instead of confusing your users and / or (co) maintainers by listing specific algorithms today.