0

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!

11
  • Does the targeted host have an RSA host key? Aug 20, 2021 at 22:18
  • 1
    @Ginnungagap: OpenSSH since 6.1 9 years ago has tried at least 2 algorithms, and the output here shows it trying 5! OP: the # lines just log that it's trying to get a key; if it succeeds yes with -H you would get a line in the form |1|base64|base64 algorithmname base64 and since you didn't it means that server isn't offering any key your OpenSSH understands, thus there is nothing to write to your known_hosts file. ssh -vv should show in debug2: host key algorithms: what the server is offering. Aug 21, 2021 at 3:26
  • @dave_thompson_085 - ty dave! Not being very ssh saavy, a follow up Q for you if you don't mind - when I attempt to ssh uname@172.22.56.2 - I do receive errors that ciphers/etc aren't supported, however, if I supply legacy options with -o (KexAlgo/ciphers/hostkeyAlgo) - I am given an RSA fingerprint with a yes/no prompt to accept.. Ty for explaining the # output - I had assumed something similar!
    – A L
    Aug 21, 2021 at 14:37
  • What legacy options? (Upstream) OpenSSH still offers algorithm ssh-rsa on connection by default (i.e. in myproposal.h), though they've been warning they will remove it 'soon' since 8.2 in 2020-02, and ssh-keyscan has requested both ssh-rsa and the newer/better rsa-sha2-* (which share the same rsa key) since 8.1 in 2019-10. Which are you using, and has it been patched or reconfigured? Aug 21, 2021 at 18:45
  • @dave_thompson_085 - aha - I actually isolated down the issue to being ssh-keyscan not having those legacy options by default ... do you know of a way to supply the same optional legacy parameters in my recent update to ssh-keyscan? Should I rephrase my questions around that or make a new question?
    – A L
    Aug 23, 2021 at 19:19

1 Answer 1

1

(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?

1
  • ty or thiS! I'l add for anyone coming here frustrated by ansible inventory use of the above - ANSIBLE DOESNT USE OPENSSH of the system!! It uses libssh or paramiko for network devices. So the above is only useful for network automation if you're building other things for ansible with the data.
    – A L
    Sep 13, 2021 at 23:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.