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