Bug 1250149 - SSH connections to LANCOM devices don't work using a 4096 bit RSA key
SSH connections to LANCOM devices don't work using a 4096 bit RSA key
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openssh (Show other bugs)
6.7
All Linux
medium Severity medium
: rc
: ---
Assigned To: Jakub Jelen
BaseOS QE Security Team
:
Depends On:
Blocks: 1172231
  Show dependency treegraph
 
Reported: 2015-08-04 11:20 EDT by Robert Scheck
Modified: 2015-10-12 10:39 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-12 09:00:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of "ssh -vvv root@192.0.2.238" on RHEL 6 (8.77 KB, text/plain)
2015-08-04 11:23 EDT, Robert Scheck
no flags Details
Output of "ssh -vvv root@192.0.2.238" on Fedora 22 (9.62 KB, text/plain)
2015-08-04 11:26 EDT, Robert Scheck
no flags Details
Output of "ssh -vvv root@192.0.2.238" on RHEL 6 (for LANCOM trace) (8.77 KB, text/plain)
2015-08-07 12:37 EDT, Robert Scheck
no flags Details
Trace logs of LANCOM for failed OpenSSH login with RHEL 6 (17.05 KB, text/plain)
2015-08-07 12:37 EDT, Robert Scheck
no flags Details

  None (edit)
Description Robert Scheck 2015-08-04 11:20:43 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 root@192.0.2.238
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):
openssh-5.3p1-104.el6_6.1.x86_64
openssh-5.3p1-111.el6.x86_64
openssh-6.6.1p1-12.el7_1.x86_64
openssh-6.8p1-5.fc22.x86_64

How reproducible:
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

Actual results:
SSH connections to LANCOM devices don't work using a 4096 bit RSA key.

Expected results:
Working SSH connections to LANCOM devices using a 4096 bit RSA key.
Comment 1 Robert Scheck 2015-08-04 11:23:44 EDT
Created attachment 1059126 [details]
Output of "ssh -vvv root@192.0.2.238" on RHEL 6
Comment 2 Robert Scheck 2015-08-04 11:26:53 EDT
Created attachment 1059129 [details]
Output of "ssh -vvv root@192.0.2.238" on Fedora 22
Comment 4 Robert Scheck 2015-08-04 11:35:57 EDT
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.
Comment 5 Jakub Jelen 2015-08-05 03:44:42 EDT
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.
Comment 6 Robert Scheck 2015-08-07 12:37:28 EDT
Created attachment 1060426 [details]
Output of "ssh -vvv root@192.0.2.238" on RHEL 6 (for LANCOM trace)
Comment 7 Robert Scheck 2015-08-07 12:37:38 EDT
Created attachment 1060427 [details]
Trace logs of LANCOM for failed OpenSSH login with RHEL 6
Comment 8 Robert Scheck 2015-08-07 12:40:30 EDT
(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).
Comment 9 Jakub Jelen 2015-08-11 03:47:45 EDT
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.
Comment 10 Jakub Jelen 2015-09-21 08:24:19 EDT
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.
Comment 11 Robert Scheck 2015-09-21 13:05:40 EDT
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?
Comment 12 Jakub Jelen 2015-09-30 06:07:53 EDT
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.
Comment 13 Robert Scheck 2015-10-09 05:49:03 EDT
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).
Comment 14 Jakub Jelen 2015-10-12 09:00:41 EDT
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.
Comment 15 Robert Scheck 2015-10-12 10:39:27 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.