Hello Jack, (and others, because this explanation might shed some light on things)
Am 06.06.2023 um 23:20 schrieb Jack Woehr via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx>:
I'm *not sure* that it is *not* related. That's why I mentioned it.
But I am. :-) (Through my own experiences, which are admittedly not related to IBM i. But then other than "where are the sshd logs ending up" and different path names for files, it's still ssh.)
"Host key verification failed" is an ... "interesting" ... message 😁
This is a message I regularly encounter in my corporate lab environment, where a limited amount of IP addresses are available in DHCP pool for preparing customer rollouts.
I clone a VM, change the hostname, and reboot => My scripts recreate /etc/ssh/ssh_host*
Next I want relogin to said VM. MAC address stays the same, thus DHCP assigns the same IP address, but suddenly that IP address has a new ssh keyset, no longer matching the one saved in ~/.ssh/known_hosts. => Boom, error. I can't log in, because of said error.
"Host key verification failed" is the message one receives when an already saved host key for a given hostname/IP address does no longer match the key received in the actual protocol exchange upon connecting.
By default, recent ssh implementations save known_hosts entries in hashed format, to protect hostnames (from DNS): An attacker getting hold of a stock known_hosts file obtained a nice list of hosts to try out for further activities. I deliberately switch off hashing anyway, because it's easier for me to spot outdated or wrong entries. One can do this per user (~/.ssh/config) or globally:
Host *
HashKnownHosts no
Existing entries aren't affected, but new entries will from now on be in clear text. Note that there are no private keys saved. The contents of known_hosts aren't sensitive in a cryptographic way. An unhashed known_hosts allows to be edited with a simple text editor, searching for affected DNS names and IP addresses to delete those.
See also:
https://en.wikipedia.org/wiki/Trust_on_first_use
Does that help in understanding?
The supplier told me that "..doing connection tests with your user , the
problem described does not occur, there are no keys activated on the server
side .."
... does not either make sense to me.
The supplier hasn't grasped the underlying problem. Reasons are unknown to me. For one reason or another, the supplier's host key changed and this is most likely the base problem.
So IMHO the *easiest *debugging step is to upgrade the outdated software.
While it's always a good security measure to stay current, I reiterate that the problem being observed by the OP is not related to older software levels.
:wq! PoC
midrange.com
