Created attachment 1059126 [details]
Output of "ssh -vvv root.2.238" on RHEL 6

Created attachment 1059129 [details]
Output of "ssh -vvv root.2.238" on Fedora 22

Cross-filed case 01487237 on the Red Hat customer portal. Please let us
know if you need more information, contact data for LANCOM are mentioned
in the same ticket.

This is pretty strange. The first step, public key verification succeed, but the sign_and_send_pubkey is failing (silently on client). There is nothing more interesting in the client log. Also comparation with upstream 5.3 and our shipped version doesn't show any interesting differences.

Your log shows that server is identified as lancom, but I don't think it is some in-house implementation -- probably other re-branded opensource project? It would be useful to see some server logs (if there is the possibility). It should point us to the problem, but it is strange this is happening only with our shipped RHEL6 client.

If you have the LANCOM device around, can you please try to get some of these logs? Otherwise I will try to contact LANCOM directly.

Created attachment 1060426 [details]
Output of "ssh -vvv root.2.238" on RHEL 6 (for LANCOM trace)

Created attachment 1060427 [details]
Trace logs of LANCOM for failed OpenSSH login with RHEL 6

(In reply to Jakub Jelen from comment #5)
> If you have the LANCOM device around, can you please try to get some of
> these logs? Otherwise I will try to contact LANCOM directly.

I have attached the logs that I was able to gather on both ends for really
the same login - if they are not helpful enough, please get in touch directly
with LANCOM (the contact data and ticket on the other end are known to GSS).

Thank you for the logs. There is obvious failure during pubkey authentication, but there is not explained reason why:

> key found in list of authorized keys
> cannot read signature, bailing out
> sent USERAUTH_FAILURE message

To debug this problem, I will probably have to debug more with lancom. I will keep you updated about progress.

I didn't get any information from LANCOM or possibility to test this issue, so I was unable to reproduce this problem and actually "touch" it in real environment. I can hardly investigate internal behaviour only from these logs, when there is no apparent error what went wrong.

Yes, I can admit, there is probably some problem on one of the sides, but without ability to actually touch it, I can only ask you for some more pieces of information, but such remote debugging will probably not work well.

I can think about maximal size of key that is accepted (if there is such threshold), if there is some active network device possibly matching that packet as malicious (or too large). There is still too large surface where things can go wrong.

Jakub, thank you for the status update. I triggered our contact person at
LANCOM already. If it helps, I can search if we have a spare device around
that we can attach to a Internet line for you - would that help in case if
LANCOM still doesn't provide the information you are looking for?

During the call with LANCOM this morning, we tried to reproduce your issue with some recent router firmware versions, but without any success. I was able to connect from stock RHEL6.7 (openssh-5.3p1-112.el6_7.x86_64) using 4096 bit RSA key without any problems.
Lancom will contact you about available firmware versions we tested.

Based on that result I figured out that I was fooled by a non-default setting,
thus my personal result is so far this:

2048 bit RSA key:
a) Works fine: "ssh -o Compression=yes root@<host>"
b) Works fine: "ssh -o Compression=no root@<host>"

4096 bit RSA key:
c) Does not work: "ssh -o Compression=yes root@<host>"
d) Works fine: "ssh -o Compression=no root@<host>"

I think what has been tested with comment #12 so far is d), but not c) (as I
wasn't really aware about the compression myself before).

Thank you for the clarification.

We tested today with LANCOM again, based on compression option, and we observed your described behaviour with the old firmware. The new firmware is fixing this issue and connection succeed both with and without compression with these keys.

Closing now, as there is nothing to fix from our side.

Jakub, thank you really very much for your time and support here!

For the others who maybe stumble over this: This issue is addressed with LCOS
9.04.1309 and 9.10.0452 (or later) - which was not available at the time when
we opened the initial ticket at LANCOM (and later at Red Hat).

As said before, not a bug in OpenSSH, but in SSH implementation of LANCOM.