After upgrade from version 02.11 to 0.2.16 connections fail with: java.io.IOException: End of IO Stream Read about jsch HOT 8 CLOSED

Hi @HubertOT,

No there is not any sort of "answer" that a server is supposed to provide.
This extension is documented by OpenSSH as follows:

1.11 transport: SSH2_MSG_EXT_INFO during user authentication

This protocol extension allows the SSH2_MSG_EXT_INFO to be sent
during user authentication. RFC8308 does allow a second
SSH2_MSG_EXT_INFO notification, but it may only be sent at the end
of user authentication and this is too late to signal per-user
server signature algorithms.

Support for receiving the SSH2_MSG_EXT_INFO message during user
authentication is signalled by the client including a
"[email protected]" key via its initial SSH2_MSG_EXT_INFO
set after the SSH2_MSG_NEWKEYS message.

A server that supports this extension MAY send a second
SSH2_MSG_EXT_INFO message any time after the client's first
SSH2_MSG_USERAUTH_REQUEST, regardless of whether it succeed or fails.
The client SHOULD be prepared to update the server-sig-algs that
it received during an earlier SSH2_MSG_EXT_INFO with the later one.

Thanks,
Jeremy

from jsch.

Hi @HubertOT,

1. Can you please provide a full backtrace?
2. Can you please provide a full copy of JSch logs?
3. Can you please confirm the last version of JSch that works for you (and thus the earliest release that fails)?

Thanks,
Jeremy

from jsch.

Hi @norrisjeremy,

1. java.io.IOException: End of IO Stream Read
   at com.jcraft.jsch.IO.getByte(IO.java:95)
   at com.jcraft.jsch.Session.read(Session.java:1232)
   at com.jcraft.jsch.UserAuthNone.start(UserAuthNone.java:54)
   at com.jcraft.jsch.Session.connect(Session.java:413)
   at com.jcraft.jsch.Session.connect(Session.java:199)
   at org.springframework.integration.sftp.session.SftpSession.connect(SftpSession.java:292)
   at org.springframework.integration.sftp.session.DefaultSftpSessionFactory.getSession(DefaultSftpSessionFactory.java:397)
2. Unfortunately as stated I am not allowed to provide full JSCH logs as mentioned otherwise would have done that in first place.
3. The issue does not occur using JSch 0.2.14, but happens only for JSch 0.2.15 and 0.2.16. Adding/Setting, using JSch 0.2.15 or 0.2.16, the property "enable_ext_info_in_auth" with value "no" in the JSch config resolves the issue. So it looks to be introduced with support for this new extension.

One of the sFTP-server brands to which the connection fails without setting JSch property "enable_ext_info_in_auth" value to "no", is HostedFTP.

With kind regards,
Hubert

from jsch.

Hi @HubertOT,

My best guess is that some of the servers to which you are connecting do not work correctly if the client advertises the [email protected] extension in it's ext-info message, so you'll likely just have to disable this via the enable_ext_info_in_auth setting as you already found.

Thanks,
Jeremy

from jsch.

Thank you @norrisjeremy, Will try to confirm this for one of the sFTP-servers and if needed will come back.

Is the server expected to give an answer on the [email protected] advertisement? If so, what answers would be possible for verification?

from jsch.

@norrisjeremy, Maybe a stupid question, but if the server does not provide a (clear) answer, should the client then not be robust against any behavior of the server, so have a fallback mechanism to the "old" path not supporting the SSH2_MSG_EXT_INF in case anything goes wrong?

from jsch.

Hi @HubertOT,

That's not how SSH2_MSG_EXT_INFO messages work: it's a unidirectional message allowing a client to advertise to a server (or vice versa) a set of key/value tuples. You can read up further on this in RFC-8308 to better understand.

Thanks,
Jeremy

from jsch.

Hi @norrisjeremy, Thank you very much for you quick responses and help. It's really appreciated. Will read the mentioned RFC.

With kind regards,
Hubert

from jsch.