[
https://issues.apache.org/jira/browse/DIRMINA-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17354946#comment-17354946
]
Frits Jalvingh commented on DIRMINA-1143:
-----------------------------------------
I agree, there's probably some bad thing in between. That PaloAltoNetworks
exists and makes devices that do this apparently.
Still, I need to find a way to solve this, and I'd prefer without writing a
retry loop.. I checked the "failed" trace again, and there actually *is* a ssh
identification inside packet 8; it is at the end of that packet and apparently
after the key exchange proposal. Is there something we can do with that? Why is
the code assuming the ssh ident is at the start of that exchange packet?
> sftp authentication fails with "Incorrect identification (null characters not
> allowed) - at line 1 character #1 after ''
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRMINA-1143
> URL: https://issues.apache.org/jira/browse/DIRMINA-1143
> Project: MINA
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu Linux 18.04, Java 11.
> Reporter: Frits Jalvingh
> Priority: Major
> Attachments: good.pcap, packetlog2.cat
>
>
> I am having this intermittent error when authenticating to an sftp server. It
> is always the same server and always the same program; connecting fails about
> once every 5 times with this error coming from SessionHelper.java, method
> doReadIdentification. I had this error before and upgraded to Mina 2.6.0 from
> maven (org.apache.sshd, sshd-core et al) but that changed nothing. The code
> runs on Ubuntu Linux 18.04 (Azure, sigh) with Java 11.I tried to do some
> debugging and for that I changed SessionHelper so that it dumps the
> information that it is trying to read at that time from its buffer. Because
> that always died with that NUL character as the first character read I made
> the code continue to read a bit so that there might be some context.. What is
> present in that buffer at this time is this:
>
> {{0000: 00 00 01 d4 0b 14 8a e8 5f 65 22 7b 97 4f 2d 61 ........_e"{.O-a}}
> {{0010: 12 75 19 81 6e 1a 00 00 00 47 64 69 66 66 69 65 .u..n....Gdiffie}}
> {{0020: 2d 68 65 6c 6c 6d 61 6e 2d 67 72 6f 75 70 2d 65 -hellman-group-e}}
> {{0030: 78 63 68 61 6e 67 65 2d 73 68 61 32 35 36 2c 64 xchange-sha256,d}}
> {{0040: 69 66 66 69 65 2d 68 65 6c 6c 6d 61 6e 2d 67 72 iffie-hellman-gr}}
> {{0050: 6f 75 70 2d 65 78 63 68 61 6e 67 65 2d 73 68 61 oup-exchange-sha}}
> {{0060: 31 00 00 00 0f 73 73 68 2d 72 73 61 2c 73 73 68 1....ssh-rsa,ssh}}
> {{0070: 2d 64 73 73 00 00 00 41 61 65 73 31 32 38 2d 63 -dss...Aaes128-c}}
> {{0080: 74 72 2c 61 65 73 31 39 32 2d 63 74 72 2c 61 65 tr,aes192-ctr,ae}}
> {{0090: 73 32 35 36 2d 63 74 72 2c 61 65 73 31 32 38 2d s256-ctr,aes128-}}
> {{00a0: 63 62 63 2c 61 65 73 31 39 32 2d 63 62 63 2c 61 cbc,aes192-cbc,a}}
> {{00b0: 65 73 32 35 36 2d 63 62 63 00 00 00 41 61 65 73 es256-cbc...Aaes}}
> {{00c0: 31 32 38 2d 63 74 72 2c 61 65 73 31 39 32 2d 63 128-ctr,aes192-c}}
> {{00d0: 74 72 2c 61 65 73 32 35 36 2d 63 74 72 2c 61 65 tr,aes256-ctr,ae}}
> {{00e0: 73 31 32 38 2d 63 62 63 2c 61 65 73 31 39 32 2d s128-cbc,aes192-}}
> {{00f0: 63 62 63 2c 61 65 73 32 35 36 2d 63 62 63 00 cbc,aes256-cbc.}}
>
> The error occurs when reading that 00 at offset 0000; the rest of the data is
> there by looking into the rest of that buffer..
> I can quite easily reproduce this, so if more data is needed I should be able
> to provide it..
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
