Red Hat Bugzilla – Bug 1250149
SSH connections to LANCOM devices don't work using a 4096 bit RSA key
Last modified: 2015-10-12 10:39:27 EDT
Description of problem:
Every SSH connection try from RHEL 6 to a LANCOM device leads to "Received
disconnect from <host>: 6:" instead of a successful login when using a 4096
bit RSA key for the key based authentication; but it works using a password
rather a key. A 2048 bit RSA key works also fine.
$ ssh email@example.com
Received disconnect from 192.0.2.238: 6:
When trying to debug this with LANCOM it turned out that it seems to work
with a vanilla OpenSSH 5.3p1 (tested by LANCOM) and it even works with the
OpenSSH shipped with RHEL 7 and Fedora 22 (but not with RHEL 6). The same
4096 bit RSA key works fine for SSH connections to other OpenSSH servers,
no matter if it's RHEL 5, 6, 7 or SLES or Debian. Given that the LANCOM
tests were also not showing up an issue on their side with a OpenSSH 5.3p1
I believe this is a bug in OpenSSH as shipped in RHEL 6.
Version-Release number of selected component (if applicable):
Everytime, see above and below.
Steps to Reproduce:
1. Get a system with RHEL 6
2. Run "ssh-keygen -t rsa -b 4096"
3. Use the public key on a LANCOM device
4. Try to connect to the LANCOM device using SSH
5. Receive the failure
SSH connections to LANCOM devices don't work using a 4096 bit RSA key.
Working SSH connections to LANCOM devices using a 4096 bit RSA key.
Created attachment 1059126 [details]
Output of "ssh -vvv firstname.lastname@example.org" on RHEL 6
Created attachment 1059129 [details]
Output of "ssh -vvv email@example.com" 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 firstname.lastname@example.org" 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.