Score:0

Server

ssh-keyscan to known_hosts produces no results

A L

12/20/22, 9:18 PM

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:

What is my ssh-keyscan output communicating/mean? I would expect something like |1|weofijgojw = sshkey string here.
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 [email protected]
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 [email protected] -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 [email protected] -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 [email protected] -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!

1125

1 + 11

ssh

known-hosts

ubuntu-20.04

Ginnungagap

12/20/22, 10:18 PM

Does the targeted host have an RSA host key?

dave_thompson_085

12/21/22, 3:26 AM

@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.

A L

12/21/22, 2:37 PM

@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 [email protected] - 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!

dave_thompson_085

12/21/22, 6:45 PM

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?

A L

12/23/22, 7:19 PM

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

Michael Hampton

12/23/22, 7:19 PM

As you can see, the remote device only offers _weak_ outdated key exchange algorithms and ciphers. A very strange thing for a [commercial offering](https://www.allegrosoft.com/product/iot-edge-device/romsshell/) today. These are not enabled by default in modern ssh today, and as someone else mentioned, will eventually be removed entirely. It's bizarre that a company would call this "secure" but I suppose I've probably seen worse. What exactly is this device, and can you replace it with something that actually does have some security?

A L

12/23/22, 7:28 PM

@MichaelHampton - Agreed, in this case these are decade old (or older) cisco switches/routers/AP's - and they're this bad or worse in many cases. From a security perspective, our current systems templates include modern equipment which ssh-keyscan has no issues querying, this Q was for the old fleet which I'm wrestling with. In short - there's a plan rolling to phase these out, but there are thousands I'd like to be able to automate against in the interim and this is the major hurdle to doing that currently. Is there no way to pass the legacy parameters to ssh-keyscan?

Michael Hampton

12/23/22, 7:29 PM

There probably is. Did you check the man page?

A L

12/23/22, 7:31 PM

yeah - I'm using: https://man.openbsd.org/ssh-keyscan.1 and my original source for the legacy options to even get normal SSH app to connect are from here: https://www.openssh.com/legacy.html - nothing in the apps arguments suggests they can be supplied.. but I wanted to get community feedback in case I'm missing/misreading something!

dave_thompson_085

12/23/22, 11:00 PM

**AH! DSA!** Yes, ssh-keyscan doesn't try DSA by default, even before OpenSSH deprecated it (7.0 IIRC). `ssh-keyscan -t dsa` may work to get the key (even 8.6 does set DHG1 for kx _in scan_, but it looks to me 7.4 up won't set 3des). But to actually _connect_ with `ssh` (or `scp` etc) you will need all the options you found.

A L

1/7/23, 1:52 PM

@dave_thompson_085 - Ok, cool - that's good to know! I will work to test this out in my lab, in the meantime do you want to post a separate answer so that I can flag/accept? This has been a very pesky problem that I'm sure others in network automation will run into that I'd like to have a formal answer for. If I complete testing/confirm prior to seeing anything posted here I'll write one myself but would prefer to give you credit where due! Thank you regardless for your help.

Score:1

Server

dave_thompson_085

1/9/23, 6:56 AM

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

0 + 0

A L

1/13/23, 11:46 PM

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.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: ssh-keyscan to known_hosts produces no results

TH: ssh-keyscan ไปยังknown_hosts ไม่สร้างผลลัพธ์

RO: ssh-keyscan to known_hosts nu produce rezultate

RU: ssh-keyscan для known_hosts не дает результатов

VI: ssh-keyscan to known_hosts không tạo ra kết quả nào

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.