StrictHostKeyChecking=ask不管我做什么都不工作

Question

这似乎是一个新手的问题，但我无法在更改主机嘿之后登录到ssh服务器，尽管到处都是StrictHostKeyChecking=no或StrictHostKeyChecking=ask。

我想要的行为是被问及与键不匹配的问题，并且能够说“是”，以便ssh覆盖已知的键并继续前进。我得到的印象是，这曾经是默认行为！

• /etc/ssh/ssh_config没有StrictHostKeyChecking (它被注释掉)。根据手册，默认的是询问，这应该是我想要的。
• ~/..ssh/config没有StrictHostKeyChecking配置
• 我尝试在命令行上设置StrictHostKeyChecking=ask和StrictHostKeyChecking=no，结果令人困惑：

对于cmdline上的StrictHostKeyChecking=ask，我从来没有被问到。有人告诉我，连接失败了：

ECDSA host key for localhost has changed and you have requested strict checking.
Host key verification failed.

对于cmdline上的StrictHostKeyChecking=no，连接是建立的，但是是瘫痪的，这样说：

Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
X11 forwarding is disabled to avoid man-in-the-middle attacks.

我不是喜悦，因为我需要X转发。

因此，简单地说，只在cmdline上添加选项似乎会产生不同的效果，但我仍然没有被要求。在/etc/ssh/ssh_config或~/.ssh/config中添加该选项没有任何区别。为什么会这样呢？是因为我想用X吗？不，即使是X残疾，我也没有被要求。是因为服务器端的配置吗？(sshd)

Answer 1

你似乎想要的行为从来不是默认行为，ssh也从来没有这样做过。

仔细检查手册页对StrictHostKeyChecking的评论：

如果此标志设置为“是”，ssh(1)将不会自动将主机键添加到~/.ssh/知名_ host文件，并且拒绝连接到主机键已更改的主机。这提供了最大限度的防止中间人(MITM)攻击的保护，尽管当/etc/ssh/ssh_ when文件维护不善或经常与新主机建立连接时，它可能会很烦人。此选项强制用户手动添加所有新主机。如果此标志设置为“接受-新”，那么ssh将自动向用户已知的主机文件中添加新的主机密钥，但不允许连接到已更改主机键的主机。如果将此标志设置为“no”或“off”，ssh将自动向用户已知的主机文件中添加新的主机键，并允许连接到已更改主机键的主机，但须受一些限制。如果此标志设置为ask (默认值)，则只有在用户确认这是他们真正想要做的事情之后，才会将新的主机键添加到用户已知的主机文件中，而ssh将拒绝连接到其主机键已更改的主机。在所有情况下，都会自动验证已知主机的主机密钥。

只问主人是否不知道。如果主机已知且密钥不匹配，则会得到有关主机键不匹配的错误，并且连接将被中止。

如果您出于某种原因故意更改了主机密钥，则在验证新密钥是否确实正确之后，还需要在本地known_hosts文件中更改或删除它。这不是ssh将永远自动化的事情，因为它会带来极大的安全风险。