ssh：无法建立主机“主机名”的真实性

Posted 2023-03-04

【中文标题】ssh：无法建立主机“主机名”的真实性

【英文标题】：ssh: The authenticity of host 'hostname' can't be established

【发布时间】：2011-04-09 11:57:52

【问题描述】：

当我 ssh 到一台机器时，有时我会收到此错误警告，并提示说“是”或“否”。从自动 ssh 到其他机器的脚本运行时，这会导致一些问题。

警告信息：

The authenticity of host '<host>' can't be established.
ECDSA key fingerprint is    SHA256:TER0dEslggzS/BROmiE/s70WqcYy6bk52fs+MLTIptM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pc' (ECDSA) to the list of known hosts.

有没有办法自动说“是”或忽略这个？

【问题讨论】：

我建议不要这样做。您需要弄清楚为什么会出现这些错误，否则您会向中间人的攻击敞开心扉，而这正是这些错误试图保护您免受攻击的原因。

这可能是由使用该 ssh 密钥的服务器更改引起的，也可能是由于有人坐在您和服务器之间监听您发送/接收的所有内容。

这个错误的原因是什么？

我不同意彼得的观点。在一个大型组织中，试图让其他人解决这样的问题，而您只是试图完成您的工作是不现实的。

许多大型组织与@SridharSarnobat 的建议完全相反。你必须确保合适的人解决这些问题，而试图解决这些问题只会让事情变得更糟。

【参考方案1】：

根据您的 ssh 客户端，您可以在命令行上将 StrictHostKeyChecking 选项设置为 no，和/或将密钥发送到 null known_hosts 文件。您还可以在配置文件中为所有主机或给定的一组 IP 地址或主机名设置这些选项。

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

编辑

正如@IanDunn 所说，这样做存在安全风险。如果您要连接的资源已被攻击者欺骗，他们可能会将目标服务器的挑战重播给您，让您误以为您正在连接到远程资源，而实际上他们正在连接到该资源您的凭据。在更改连接机制以跳过 HostKeyChecking 之前，您应该仔细考虑这是否是一个适当的风险。

Reference.

【讨论】：

我认为在没有警告安全隐患的情况下推荐这个是不负责任的。 superuser.com/a/421084/121091 是 IMO 更好的答案。

@IanDunn 在一般的 SSH 客户端情况下我会同意你的看法，但鉴于 OP 明确指出他在运行脚本时遇到了这个问题，因此每次主机密钥更改时都会破坏脚本（并且有很多原因可能会导致这种情况）您提到的答案无法解决。也就是说，这是一个有效的批评，所以我更新了我的答案以指出风险。

我不敢相信有这么多人赞成这个答案，而且它也被提问者接受了。这种方法绕过安全检查并将其连接到远程主机。检查 ~/.ssh/ 文件夹中的 known_hosts 文件是否具有写权限。如果没有，那么使用这个答案***.com/a/35045005/2809294

只要你知道自己在做什么，这就是最好的解决方案。我有一个内部网站，我们会自动连接到该网站，该网站有很多更新（实际上是随机的）IP 地址。我将它添加到 ~/.ssh/config 并且它可以正常工作。请注意，我知道这个网站就是我认为的那样，如果不是，那么坏人就没有优势，因为我知道正在传输什么数据。

【参考方案2】：

值得更好回答的老问题。

您可以在不禁用StrictHostKeyChecking（这是不安全的）的情况下阻止交互式提示。

在您的脚本中加入以下逻辑：

if [ -z "$(ssh-keygen -F $IP)" ]; then
  ssh-keyscan -H $IP >> ~/.ssh/known_hosts
fi

它检查服务器的公钥是否在known_hosts。如果没有，它从服务器请求公钥并将其添加到known_hosts。

通过这种方式，您只会遭受一次中间人攻击，可以通过以下方式缓解：

确保脚本首次通过安全通道连接 检查日志或 known_hosts 以手动检查指纹（仅执行一次）

【讨论】：

或者只是管理所有机器的 known_hosts 文件作为基础架构配置设置的一部分。

请注意 ssh-keyscan 不适用于 ProxyCommand：marc.info/?l=openssh-unix-dev&m=108446567718763&w=2

它不会按预期工作。 `ssh-keygen -F $IP` 应该是"`ssh-keygen -F $IP`"（引号），否则它不会被解释为字符串

或者作为oneliner使用ssh-kegen返回值：ssh-keygen -F $IP >/dev/null || ssh-keyscan -H $IP >> ~/.ssh/known_hosts

【参考方案3】：

要禁用（或控制禁用），将以下行添加到/etc/ssh/ssh_config...的开头...

Host 192.168.0.*
   StrictHostKeyChecking=no
   UserKnownHostsFile=/dev/null

选项：

主机子网可以是*，以允许不受限制地访问所有 IP。 编辑/etc/ssh/ssh_config 用于全局配置或~/.ssh/config 用于用户特定配置。

见http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html

superuser.com 上的类似问题 - 请参阅 https://superuser.com/a/628801/55163

【参考方案4】：

确保~/.ssh/known_hosts 是可写的。这为我解决了问题。

【讨论】：

允许所有人写入 known_hosts 是否安全？

@akaRem 绝对不是。通常您希望它只对拥有该.ssh 文件夹的用户可写。

权限0400 是最佳的（请任何人纠正我）但是在我的情况下，问题只是我的用户的.ssh 文件夹的所有权发生了变化——因此我自己的0400 权限无效。 sudo 将所有权改回给我解决了我的问题。

这个解决了我的问题。

【参考方案5】：

解决此问题的最佳方法是在“StrictHostKeyChecking”之外使用“BatchMode”。这样，您的脚本将接受新主机名并将其写入 known_hosts 文件，但不需要是/否干预。

ssh -o BatchMode=yes -o StrictHostKeyChecking=no [e-mail] "uptime"

【参考方案6】：

编辑您的配置文件，通常位于“~/.ssh/config”，并在文件开头添加以下行

Host *
    User                   your_login_user
    StrictHostKeyChecking  no
    IdentityFile          ~/my_path/id_rsa.pub

用户设置为 your_login_user 表示此设置属于 your_login_user StrictHostKeyChecking 设置为 no 将避免提示 IdentityFile 是 RSA 密钥的路径

这适用于我和我的脚本，祝你好运。

【讨论】：

谢谢它真的拯救了一天。但是最后一行IdentityFile 是干什么用的？没有它似乎也可以工作..

【参考方案7】：

由于安全功能而发出此警告，请勿禁用此功能。

它只显示一次。

如果在第二次连接后仍然出现，问题可能是写入known_hosts 文件。 在这种情况下，您还会收到以下消息：

Failed to add the host to the list of known hosts 

您可以通过更改所有者来修复它，将文件的权限更改为您的用户可写。

sudo chown -v $USER ~/.ssh/known_hosts

【参考方案8】：

理想情况下，您应该创建一个自我管理的证书颁发机构。从生成密钥对开始： ssh-keygen -f cert_signer

然后签署每个服务器的公共主机密钥： ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

这会生成一个签名的公共主机密钥： /etc/ssh/ssh_host_rsa_key-cert.pub

在/etc/ssh/sshd_config 中，将HostCertificate 指向此文件： HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

重启sshd服务： service sshd restart

然后在 SSH 客户端上，将以下内容添加到 ~/.ssh/known_hosts： @cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

以上包含：

@cert-authority 域*.example.com 公钥cert_signer.pub完整内容

cert_signer 公钥将信任其公共主机密钥由cert_signer 私钥签名的任何服务器。

虽然这需要在客户端进行一次性配置，但您可以信任多个服务器，包括那些尚未配置的服务器（只要您签署每台服务器即可）。

更多详情，请参阅this wiki page。

【参考方案9】：

参考 Cori 的回答，我对其进行了修改并使用了以下命令，该命令有效。没有exit，剩下的命令实际上是登录到远程机器，这是我不想要的脚本

ssh -o StrictHostKeyChecking=no user@ip_of_remote_machine "exit"

【参考方案10】：

执行此操作 -> chmod +w ~/.ssh/known_hosts。这将向~/.ssh/known_hosts 处的文件添加写权限。之后，远程主机将在您下次连接时添加到known_hosts 文件中。

【参考方案11】：

通常当您经常修改密钥时会出现此问题。根据服务器，更新您在服务器中生成并粘贴的新密钥可能需要一些时间。所以在生成密钥并粘贴到服务器后，等待 3 到 4 小时再尝试。问题应该得到解决。它发生在我身上。

【参考方案12】：

将这些添加到您的 /etc/ssh/ssh_config

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

【讨论】：

这里有更多详细信息shellhacks.com/disable-ssh-host-key-checking

【参考方案13】：

在主机服务器上运行这是预兆问题

chmod -R 700 ~/.ssh

【讨论】：

您是否要求人们将 authorized_keys 和公钥的权限从 644 更改为 700 ？以及从 600 到 700 的私钥？

【参考方案14】：

我遇到了同样的错误，并想提请注意这一事实 - 就像我刚刚发生的那样 - 您可能只是拥有错误的权限。您已将 .ssh 目录设置为常规目录或 @ 987654322@ 用户，因此您需要成为正确的用户。出现此错误时，我是root，但我将.ssh 配置为普通用户。退出 root 修复了它。

【参考方案15】：

以下步骤用于向主机验证自己的身份

生成 ssh 密钥。系统将要求您为密钥创建密码

ssh-keygen -f ~/.ssh/id_ecdsa -t ecdsa -b 521

（以上使用推荐的加密技术）

将密钥复制到远程主机

ssh-copy-id -i ~/.ssh/id_ecdsa user@host

注意用户@host 与您不同。您需要输入此服务器的密码，而不是密钥密码。

您现在可以安全地登录服务器而不会收到错误消息。

ssh user@host

所有来源信息均位于此处： ssh-keygen

【参考方案16】：

这是尝试建立无密码身份验证。因此，如果您尝试手动运行该命令一次，它将要求在那里提供密码。输入密码后，它会永久保存该密码，并且不再要求输入“是”或“否”。

【参考方案17】：

对我来说，原因是我对 ~/.ssh/known_hosts 的权限错误。

我没有known_hosts 文件的写权限。所以它一次又一次地问我。

【参考方案18】：

在我的情况下，主持人是未知的，而不是在问题are you sure you want to continue connecting(yes/no/[fingerprint])? 中输入yes，我只是在点击enter。

【参考方案19】：

我解决了给出以下书面错误的问题： 错误： 无法确定主机'XXX.XXX.XXX'的真实性。 RSA 密钥指纹为 09:6c:ef:cd:55:c4:4f:ss:5a:88:46:0a:a9:27:83:89。

解决方案： 1.安装任何openSSH工具。 2. 运行命令 ssh 3.它会询问你是否添加这个主机。 接受是。 4. 该主机将添加到已知主机列表中。 5. 现在你可以连接这个主机了。

这个解决方案现在正在运行......

【讨论】：

这没有回答问题。最初的（非常古老的）问题是关于通过脚本自动确认此类提示的能力。

如果它对他有用，也许对其他人也有用。无需对实际有用的东西投反对票

运行“ssh”不起作用。它显示选项用法：ssh [..][..][..][user@]hostname [command]