-
Notifications
You must be signed in to change notification settings - Fork 599
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect identification: line too long #118
Comments
I'm not sure if this is your issue, but last time I encountered this was because I was opening too many connections. Many Linux systems have a limit in place for how many unauthenticated SSH sessions can be open. For Debian, this is 10. If I hit a system with more than 10 connections at once, some of them would get a message that they should try again later, causing the exception above. In my case, I got around this by adding some retry logic. You could just as easily adjust the host's SSH settings. |
I think it is bug in sshj STATE machine
|
@bk1te No, the both the client and server MUST send the identification according to the RFC. That means that neither should necessarily wait for the other. Also the length of the buffer is enough according to the specification (i.e. RFC 4253 section 4.2), where it specifies the max length of the identification string is 255 characters including the line terminators. |
Some server implementations send crypto info after they receive client id string and in some cases server receives client id before client receives servers one. So when client start reading data it already has server id and crypto info and boom there is an error |
I would consider that an error on the server side, as it then clearly does
|
It is not an error it is just network lag. We could avoid this issue just sending client identification string after we receive server one. It is not big deal but will help other users/. |
btw locally i fix this issue that way and doesn`t have this error anymore.. |
It would be good to make a switch for this behaviour I think, instead of always waiting for the server ident string before sending our own. If we would encounter a server which also waits for the client ident string then we'd be screwed. A switch would be better in this case. |
OpenSSH will drop connections based on the value of MaxStartups when there are too many unauthenticated connection. When this happens, reads on the client socket return -1, which was previously inserted into the identification buffer, leading to the error in hierynomus#118.
OpenSSH will drop connections based on the value of MaxStartups when there are too many unauthenticated connection. When this happens, reads on the client socket return -1, which was previously inserted into the identification buffer, leading to the error in hierynomus#118.
Thanks @bluekeyes For the PR to at least better identify that this happens. |
Hi,
I am getting following exception while trying to open ssh connection.
Caused by: net.schmizz.sshj.transport.TransportException: Incorrect identification: line too long
at net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:164)
at net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:671)
at net.schmizz.sshj.SocketClient.connect(SocketClient.java:71)
at net.schmizz.sshj.SocketClient.connect(SocketClient.java:77)
at net.schmizz.sshj.SocketClient.connect(SocketClient.java:103)
at com.omneon.dam.util.bitspeed.BitSpeedUtil.openConnection(BitSpeedUtil.java:370)
at com.omneon.dam.util.bitspeed.BitSpeedUtil.exists(BitSpeedUtil.java:303)
... 19 more
The application has multiple threads. And each thread is opening its connection separately.
SSH version: OpenSSH_4.5p1, OpenSSL 0.9.8b 04 May 2006
In net.schmizz.sshj.transport.TransportImpl::readIdentification() getting buffer size more than 256 bytes.
The text was updated successfully, but these errors were encountered: