SSH Keyscan to Known Hosts – Troubleshooting No Results

known-hostssshubuntu-20.04

When I execute:

ssh-keyscan -H 172.22.56.2

I get the following output:

# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31

If I then try:

ssh-keyscan -H 172.22.56.2 >> ~/.ssh/known_hosts

Not being familiar with ssh-keyscan but believing the output I got to be .. not what I was looking for, I also tried variations of -t like:

ssh-keyscan -H -t rsa 172.22.56.2 >> ~/.ssh/known_hosts

All results are the same.
Permissions on the file are:

-rw-r--r-- 1 username username 886

The 'username' is the one running the commands above ..
This leaves me with the following questions:

  1. What is my ssh-keyscan output communicating/mean? I would expect something like |1|weofijgojw = sshkey string here.
  2. Why is nothing written to ~/.ssh/known_hosts regardless? There are no indications of issues communicated back to me / the command takes

Thank you in advance for any insight!

UPDATE 1:

user@hostname:~$ ssh user@172.22.56.2
Unable to negotiate with 172.22.56.2 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

user@hostname:~$ ssh user@172.22.56.2 -oKexAlgorithms=+diffie-hellman-group1-sha1
Unable to negotiate with 172.22.56.2 port 22: no matching host key type found. Their offer: ssh-dss

user@hostname:~$ ssh user@172.22.56.2 -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-dss
Unable to negotiate with 172.22.56.2 port 22: no matching cipher found. Their offer: 3des-cbc

user@hostname:~$ ssh user@172.22.56.2 -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-dss -oCiphers=+3des-cbc

The authenticity of host '172.22.56.2 (172.22.56.2)' can't be established.
DSA key fingerprint is SHA256:HwdMfb3k5KwrwQkFIRe6ZXilbObYhNzLbwb0zvk2n8U.
Are you sure you want to continue connecting (yes/no/[fingerprint])? ^C

user@hostname:~$ ssh-keyscan -H 172.22.56.2
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31

Adding in '-vv' only applies to the ssh application not ssh-keyscan so I didn't find anything useful from that.

Technically, the originally posed questions were answered, but that's more to do with my lack of completeness of vision for the inquiry – it seems at this point the real question is:

  • Why does ssh-keyscan return no results when ssh to the same host produces an SSH key prompt?

Should I open a new question or just alter my original submission? Thank you!

Best Answer

(From comments plus update)

The problem is that the target device is really lame and apparently (as diagnosed by ssh) supports only old and mostly obsolete SSH options that recent OpenSSH dislikes.

First, it has only a DSA (also spelled DSS in SSH) key. ssh-keyscan by default has never requested a DSA key, although the set of types it does request has varied and mostly included other new types that were added; that's why running it without options shows 5 attempts -- to get key types the device doesn't have. This part can be fixed by specfying -t dsa.

Second, it only supports DH group 1 for KEX and 3des-cbc for encryption. Although ssh no longer considers group 1 secure and needs the -oKexAlgorithms= option to use it, ssh-keyscan forces what looks like all KEX groups. However, it does not alter the ssh default for ciphers, so ssh-keyscan in OpenSSH 7.4 up should still fail. If you downgrade below 7.4 I believe ssh-keyscan -t dsa will work. Of course downgrading is bad for security, so you should only do this on a scratch monkey, like a virtual machine or container that is then discarded.

Alternatively, as you have found, ssh can be given -o options to accept these old options, so it can get the host key and add it to known_hosts. If your concern is just to avoid the interaction i.e. automate, use -oStrictHostKeyChecking=no (or accept-new in 7.6 up) to do this without prompting. If you don't want the new key put directly in the file, also use -oUserKnownHostsFile= to put it somewhere else -- although once you've done that, really the only possible thing to do with the new file is to add it to known_hosts just like ssh would have, so why bother?

Related Topic