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

[bugzilla-daemon at bugzilla.mindrot.org]

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.