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


153

当我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.

有没有一种方法可以自动说“是”或忽略它?


27
我不建议这样做。您需要弄清楚为什么会出现这些错误,否则,您将向处于中间攻击状态的男人敞开心opening,这就是这些错误试图保护您免受攻击的原因。
Peter Bagnall 2013年

3
这可能是由于使用该ssh密钥的服务器发生了更改,也可能是由于坐在您与服务器之间的某人正在侦听您发送/接收的所有消息所致。
derekdreery 2013年

该错误的原因可能是什么?
AiU

我不同意彼得的观点。在一个大型组织中,试图让其他人解决这样的问题是不现实的。
Sridhar Sarnobat

许多大型组织与@SridharSarnobat的建议恰恰相反。您必须确保合适的人员能够解决此类问题,而尝试解决这些问题只会使情况变得更糟。
詹姆斯·摩尔

Answers:


135

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

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

编辑

正如@IanDunn指出的那样,这样做存在安全隐患。如果您正在连接的资源被攻击者欺骗,他们可能会重播目标服务器的挑战给您,使您以为您正在连接到远程资源,而实际上他们正在通过以下方式连接到该资源:您的凭据。在更改连接机制以跳过HostKeyChecking之前,您应该仔细考虑这是否是适当的风险。

参考


40
我认为在不警告安全隐患的情况下建议这样做是不负责任的。superuser.com/a/421084/121091是IMO的更好答案。
伊恩·邓恩

5
@IanDunn在一般的SSH客户端情况下,我会同意您的意见,但是鉴于OP明确声明他在运行脚本时遇到了此问题,因此替代方法是每次主机密钥更改时都破坏脚本(这有很多原因可能是这种情况),但您指的答案无法解决。就是说,这是一个有效的批评,所以我更新了答案以指出风险。
cori

6
我不敢相信有这么多人赞成这个答案,而且提问者也接受了这个答案。这种方法绕过了安全检查,并将其连接到远程主机。检查〜/ .ssh /文件夹中的known_hosts文件是否具有写许可权。如果不是,则使用此答案stackoverflow.com/a/35045005/2809294
ARK

只要您知道自己在做什么,这就是最好的解决方案。我有一个内部网站,我们可以自动连接到该网站,该网站有很多,可以更新(实际上是随机的)IP地址。我将其添加到〜/ .ssh / config中,并且可以正常工作。提醒您,我知道该站点就是我想的样子,如果不是,那么坏人就没有优势,因为我知道要传输的是什么数据。
user1683793

75

值得更好回答的老问题。

您可以禁用而不禁用交互式提示StrictHostKeyChecking(这是不安全的)。

将以下逻辑合并到脚本中:

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

它检查服务器的公钥是否在known_hosts。如果不是,它将向服务器请求公钥并将其添加到中known_hosts

这样,您仅会遭受一次中间人攻击,可以通过以下方法缓解这种情况:

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

4
或仅作为基础结构配置设置的一部分来管理所有计算机的known_hosts文件。
Thilo

1
请注意,ssh-keyscan不适用于ProxyCommand:marc.info/?
unix

1
它不会按预期工作。`ssh-keygen -F $IP`应该"`ssh-keygen -F $IP`"(用引号引起来),在其他情况下则不会被解释为字符串
avtomaton

或者作为使用ssh-kegen返回值的单行代码:ssh-keygen -F $IP >/dev/null || ssh-keyscan -H $IP >> ~/.ssh/known_hosts
Gohu

38

要禁用(或禁用控制),请将以下行添加到/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


19

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


4
每个人都可以写到known_hosts是否安全?
akaRem 2015年

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

权限0400是最佳的(请纠正我的任何人),但是在我的情况下,问题只是.ssh我的用户的文件夹的所有权发生了更改,从而使我自己的0400权限无效。sudo改变所有权给我解决了我的问题。
查妮·凯

这为我解决了这个问题。
西瓦吉

14

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

ssh -o BatchMode=yes -o StrictHostKeyChecking=no user@server.example.com "uptime"

10

编辑通常位于“〜/ .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是什么?似乎也可以不使用它
。.– supersan

7

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

它只显示一次。

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

Failed to add the host to the list of known hosts 

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

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

5

参考Cori的答案,我对其进行了修改,并在下面的命令中使用了该命令,该命令正在起作用。没有exit,剩余的命令实际上是登录到远程计算机,这在脚本中是我不想要的

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

5

这样做-> chmod +w ~/.ssh/known_hosts。这将添加对文件的写入权限~/.ssh/known_hosts。之后,known_hosts下次连接时,远程主机将被添加到文件中。


4

理想情况下,您应该创建一个自我管理的证书颁发机构。从生成密钥对开始: 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私钥。

尽管这需要在客户端进行一次性配置,但是您可以信任多个服务器,包括尚未配置的服务器(只要您对每个服务器进行签名即可)。

有关更多详细信息,请参见此Wiki页面


2

通常,当您经常修改密钥时,会发生此问题。根据服务器,可能需要一些时间来更新已生成并粘贴到服务器中的新密钥。因此,在生成密钥并将其粘贴到服务器后,请等待3到4个小时,然后尝试。该问题应解决。它发生在我身上。



0

在主机服务器上运行它是预先问题

chmod -R 700 ~/.ssh

您是否在要求人们将authorized_keys和公用密钥的权限从644更改为700?私钥从600到700?
nurettin

0

我遇到了同样的错误,并想提请您注意-您可能刚刚获得了错误的特权-这只是发生在我身上。
您已将.ssh目录设置为常规目录或root用户目录,因此您需要成为正确的用户。出现此错误时,我被root配置.ssh为普通用户。退出root修复它。


-3

我解决了产生以下书面错误的问题:
错误:
无法建立主机“ 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.现在,您可以与此主机连接。

该解决方案现在正在工作……


这不能回答问题。最初的问题(很旧)是关于通过脚本自动确认此类提示的能力。
MasterAM 2013年

如果对他有用,也许对其他人也有用。无需对实际有用的东西进行
投票

运行“ ssh”不起作用。它显示的是选项用法:ssh [..] [..] [..] [user @] hostname [command]
P Satish Patro
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.