Skip to content
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

Closed
samir0282 opened this issue Sep 16, 2013 · 9 comments
Closed

Incorrect identification: line too long #118

samir0282 opened this issue Sep 16, 2013 · 9 comments
Milestone

Comments

@samir0282
Copy link

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.

@bstempi
Copy link

bstempi commented Jan 8, 2014

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.

@ghost
Copy link

ghost commented Feb 9, 2014

I think it is bug in sshj STATE machine
client should wait for serverID before sending clientID

@Override
    public void init(String remoteHost, int remotePort, InputStream in, OutputStream out)
            throws TransportException {
        connInfo = new ConnInfo(remoteHost, remotePort, in, out);

        try {

            log.info("Client identity string: {}", clientID);
            connInfo.out.write((clientID + "\r\n").getBytes(IOUtils.UTF8));
            connInfo.out.flush();

            // Read server's ID
            final Buffer.PlainBuffer buf = new Buffer.PlainBuffer();
            while ((serverID = readIdentification(buf)).isEmpty()) {
                buf.putByte((byte) connInfo.in.read());
            }

            log.info("Server identity string: {}", serverID);

        } catch (IOException e) {
            throw new TransportException(e);
        }

        reader.start();
    }

@hierynomus
Copy link
Owner

@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.

@ghost
Copy link

ghost commented Jan 9, 2015

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

@hierynomus
Copy link
Owner

I would consider that an error on the server side, as it then clearly does
not adhere to the protocol. Which ssh servers are we taking about? Do you
have any examples?
On Jan 9, 2015 6:11 PM, "bk1te" notifications@github.com wrote:

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


Reply to this email directly or view it on GitHub
#118 (comment).

@ghost
Copy link

ghost commented Jan 9, 2015

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/.

@ghost
Copy link

ghost commented Jan 9, 2015

btw locally i fix this issue that way and doesn`t have this error anymore..

@hierynomus
Copy link
Owner

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.

bluekeyes added a commit to bluekeyes/sshj that referenced this issue Mar 13, 2015
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.
bluekeyes added a commit to bluekeyes/sshj that referenced this issue Mar 13, 2015
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.
@hierynomus
Copy link
Owner

Thanks @bluekeyes For the PR to at least better identify that this happens.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants