openssh unix dev - Apr 2022 - ssh-keyscan broke when we upgraded OpenSSH

About 2 weeks ago, we upgraded a Debian Linux system to "OpenSSH_8.4p1
Debian-5, OpenSSL 1.1.1n  15 Mar 2022". On that system, ssh-keyscan changed
for the worse. It stopped working for about 30 of our network devices. When
it fails, the "-v" command-line option shows that the reason is

debug1: kex: algorithm: (no match)

It seems that the upgraded version of ssh-keyscan doesn't like devices that
use diffie-hellman-group-exchange-sha1. The ssh command continues to work
with these devices, but the ssh-keyscan does not.

We are familiar with addressing this problem for the ssh command by setting
KexAlgorithms lines in our ~/.ssh/config files. It seems that ssh-keyscan
doesn't even look in the ~/.ssh/config file at all, so we can't do that.

We have a Python program that runs ssh-keyscan on 192 devices. Our
work-around is to manually maintain a list of the devices that now don't
work with ssh-keyscan. We use ssh to get the keys for those devices into a
temporary ssh_known_hosts file, and merge that file with the dynamic one.

Is there something better that we can do?

-- Pete

On Fri, 1 Apr 2022, Pete Siemsen wrote:
> About 2 weeks ago, we upgraded a Debian Linux system to "OpenSSH_8.4p1
> Debian-5, OpenSSL 1.1.1n  15 Mar 2022". On that system, ssh-keyscan
changed
> for the worse. It stopped working for about 30 of our network devices. When
> it fails, the "-v" command-line option shows that the reason is
> 
> debug1: kex: algorithm: (no match)
> 
> It seems that the upgraded version of ssh-keyscan doesn't like devices
that
> use diffie-hellman-group-exchange-sha1. The ssh command continues to work
> with these devices, but the ssh-keyscan does not.
> 
> We are familiar with addressing this problem for the ssh command by setting
> KexAlgorithms lines in our ~/.ssh/config files. It seems that ssh-keyscan
> doesn't even look in the ~/.ssh/config file at all, so we can't do
that.
> 
> We have a Python program that runs ssh-keyscan on 192 devices. Our
> work-around is to manually maintain a list of the devices that now
don't
> work with ssh-keyscan. We use ssh to get the keys for those devices into a
> temporary ssh_known_hosts file, and merge that file with the dynamic one.
Yes, ssh-keyscan currently uses the ssh default key exchange algorithm
list and has no way of overriding it.

I guess we either need to include all KEX algorithms in ssh-keyscan's
list or to provide an option to do this.