openssh bugs - Jan 2020 - [Bug 3113] New: StrictHostKeyChecking=no works with changed 1024 bit RSA hostkeys but fails when 2048 RSA

https://bugzilla.mindrot.org/show_bug.cgi?id=3113

            Bug ID: 3113
           Summary: StrictHostKeyChecking=no works with changed 1024 bit
                    RSA hostkeys but fails when 2048 RSA
           Product: Portable OpenSSH
           Version: 7.6p1
          Hardware: amd64
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: Andy.Hart1 at cgi.com

We currently implement the StrictHostKeyChecking=no in a user account's
~/.ssh/config file, to ensure that automated backups aren't affected by
a change of the ssh host key across cisco switches & firewalls, and
netscaler load balancers. Recently one of these devices had its SSH
host key change. The ssh client connecting to it (ubuntu 18.04, running
openssh 7.6p1) failed to automatically accept and store the new key,
preventing the backup from working. My investigation has identified
that the ssh client would fail to automatically accept and store a
changed SSH host key when it is of type 2048bits RSA, but will
successfully accept and store a changed host key if it is of type
1024bits RSA. I have recreated this problem using a CentOS 7.6 server
running openssh 7.4p1, acting as the SSH server, and a Ubuntu 18.04
server running openssh 7.6p1. Testing first with a 1024 bit RSA host
key on the SSH server, I do an initial connection from my SSH client
and accept the new key. I then made a single character change to the
key stored in the ssh client's known hosts file and repeated the ssh
connection. It successfully accepted the modified key and stored it. I
then repeated the test but with a 2048 bit RSA host key on the SSH
server, but after modifying the key, the second connection failed to
accept and store the host key.

I have had the same results when using the "-o
StrictHostKeyChecking=no" on the command line, rather than relying on
the ~/.ssh/config file.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3113

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Could you please attach a debug trace ("ssh -vvv ...") from a client
experiencing this problem?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3113

--- Comment #2 from Andy Hart <Andy.Hart1 at cgi.com> ---
Created attachment 3352
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3352&action=edit
SSH debug connection output as requested

The debug output (ssh -vvv?.) if from a ubuntu ssh client, connecting
to a CentOS ssh server. For this capture, the SSH server has a 2048bit
RSA host key. The client started with an empty known_hosts file, and
made a first connection. It accepted and stored the SSH servers host
key. I then modified the stored key in the clients known hosts file,
and repeated the SSH connection , this time with the "-vvv" option .
The connection failed with a warning about a MITM attack, i.e. despite
the "StrictHostKeyChecking=no" set in the config file it did NOT
accept
the changed key. However, if I repeat this test with a 1024bit RSA key
on the SSH server and no MITM attack is reported

Regards,
Andy

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3113

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3352|application/octet-stream    |text/plain
          mime type|                            |

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3113

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
This is the intended behaviour. StrictHostKeyChecking controls whether
ssh accepts a *new* hostkey automatically. It is not intended to
disable host key checking entirely.

I'd generally recommend against doing that, because an on-path attacker
can trivially MITM your connections. If you really want to do this,
then the easiest way is to pass "-oUserKnownHostsFile=/dev/null
-oStrictHostKeyChecking=no" to ssh.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3113

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
closing resolved bugs as of 8.6p1 release

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.