On Saturday, 21 November 2020 15:22:03 GMT n952162 wrote: > I tried to ssh to another machine and got a failing man-in-the-middle > warning.
When keys have changed at the remote end and the new key is not listed in ~/.ssh/known_hosts, you will get a warning whether you want to accept the key and continue connecting or not. This is the moment, or ideally in advance of this moment, you contact the remote system's sysadmin to find out what the fingerprint of the new key might be. > The fingerprint given to check didn't match that of the target host. On > closer inspection, the entries in known_hosts are *ecdsa-sha2-nistp256* > and the offending key was of type *ed25519*, as reported by the client. > > These are both gentoo machines, relatively recently updated. Therefore this update seems to have generated new keys and set ed25519 as the default. > Everything on the net talks about how to generate key files of the > appropriate type, but I'm don't want to generate a key file. > > Apparently, this is a gentoo configuration issue. USE flags of openssh > on both machines are the same. > > There are two news items related to ssh, but neither seems relevant. > > Has there been a changed system-wide determination of the key type and > what would be the best way to make them consistent across all machines? Take a look in /etc/ssh and/or ~/.ssh/ for the config files to set preferences for ssh client and sshd server either generically or per remote host. However, you'll need to be reviewing and adjusting these regularly, because ciphers and algos become deprecated when vulnerabilities are discovered.
signature.asc
Description: This is a digitally signed message part.
