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

发布于 2024-09-17 18:44:03 字数 409 浏览 5 评论 0原文

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

有没有办法自动说“是”或忽略它?

When i ssh to a machine, sometime i get this error warning and it prompts to say "yes" or "no". This cause some trouble when running from scripts that automatically ssh to other machines.

Warning Message:

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.

Is there a way to automatically say "yes" or ignore this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(21

标点 2024-09-24 18:44:03

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

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

编辑

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

参考

Depending on your ssh client, you can set the StrictHostKeyChecking option to no on the command line, and/or send the key to a null known_hosts file. You can also set these options in your config file, either for all hosts or for a given set of IP addresses or host names.

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

EDIT

As @IanDunn notes, there are security risks to doing this. If the resource you're connecting to has been spoofed by an attacker, they could potentially replay the destination server's challenge back to you, fooling you into thinking that you're connecting to the remote resource while in fact they are connecting to that resource with your credentials. You should carefully consider whether that's an appropriate risk to take on before altering your connection mechanism to skip HostKeyChecking.

Reference.

谎言 2024-09-24 18:44:03

老问题值得更好的答案。

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

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

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

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

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

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

Old question that deserves a better answer.

You can prevent interactive prompt without disabling StrictHostKeyChecking (which is insecure).

Incorporate the following logic into your script:

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

It checks if public key of the server is in known_hosts. If not, it requests public key from the server and adds it to known_hosts.

In this way you are exposed to Man-In-The-Middle attack only once, which may be mitigated by:

  • ensuring that the script connects first time over a secure channel
  • inspecting logs or known_hosts to check fingerprints manually (to be done only once)
眉黛浅 2024-09-24 18:44:03

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

To disable (or control disabling), add the following lines to the beginning of /etc/ssh/ssh_config...

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

Options:

  • The Host subnet can be * to allow unrestricted access to all IPs.
  • Edit /etc/ssh/ssh_config for global configuration or ~/.ssh/config for user-specific configuration.

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

Similar question on superuser.com - see https://superuser.com/a/628801/55163

伤感在游骋 2024-09-24 18:44:03

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

Make sure ~/.ssh/known_hosts is writable. That fixed it for me.

遮云壑 2024-09-24 18:44:03

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

ssh -o BatchMode=yes -o StrictHostKeyChecking=no [email protected] "uptime"

The best way to go about this is to use 'BatchMode' in addition to 'StrictHostKeyChecking'. This way, your script will accept a new hostname and write it to the known_hosts file, but won't require yes/no intervention.

ssh -o BatchMode=yes -o StrictHostKeyChecking=no [email protected] "uptime"
淡写薰衣草的香 2024-09-24 18:44:03

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

它仅显示一次。

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

Failed to add the host to the list of known hosts 

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

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

This warning is issued due the security features, do not disable this feature.

It's just displayed once.

If it still appears after second connection, the problem is probably in writing to the known_hosts file.
In this case you'll also get the following message:

Failed to add the host to the list of known hosts 

You may fix it by changing owner of changing the permissions of the file to be writable by your user.

sudo chown -v $USER ~/.ssh/known_hosts
↘紸啶 2024-09-24 18:44:03

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

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

User set to your_login_user 表示此设置属于 your_login_user
StrictHostKeyChecking 设置为 no 将避免出现提示
IdentityFile 是 RSA 密钥的路径

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

Edit your config file normally located at '~/.ssh/config', and at the beggining of the file, add the below lines

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

User set to your_login_user says that this settings belongs to your_login_user
StrictHostKeyChecking set to no will avoid the prompt
IdentityFile is path to RSA key

This works for me and my scripts, good luck to you.

忆离笙 2024-09-24 18:44:03

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

Do this -> chmod +w ~/.ssh/known_hosts. This adds write permission to the file at ~/.ssh/known_hosts. After that the remote host will be added to the known_hosts file when you connect to it the next time.

单身狗的梦 2024-09-24 18:44:03

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

然后在 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 页面< /a>.

Ideally, you should create a self-managed certificate authority. Start with generating a key pair:

ssh-keygen -f cert_signer

Then sign each server's public host key:

ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

This generates a signed public host key:

/etc/ssh/ssh_host_rsa_key-cert.pub

In /etc/ssh/sshd_config, point the HostCertificate to this file:

HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Restart the sshd service:

service sshd restart

Then on the SSH client, add the following to ~/.ssh/known_hosts:

@cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

The above contains:

  • @cert-authority
  • The domain *.example.com
  • The full contents of the public key cert_signer.pub

The cert_signer public key will trust any server whose public host key is signed by the cert_signer private key.

Although this requires a one-time configuration on the client side, you can trust multiple servers, including those that haven't been provisioned yet (as long as you sign each server, that is).

For more details, see this wiki page.

参考Cori的答案,我对其进行了修改并使用了以下命令,该命令有效。如果没有 exit,剩余的命令实际上会记录到远程计算机,这是我不希望在脚本中出现的

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

With reference to Cori's answer, I modified it and used below command, which is working. Without exit, remaining command was actually logging to remote machine, which I didn't want in script

ssh -o StrictHostKeyChecking=no user@ip_of_remote_machine "exit"
一身骄傲 2024-09-24 18:44:03

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

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

Add these to your /etc/ssh/ssh_config

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no
梦幻的味道 2024-09-24 18:44:03

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

Generally this problem occurs when you are modifying the keys very oftenly. Based on the server it might take some time to update the new key that you have generated and pasted in the server. So after generating the key and pasting in the server, wait for 3 to 4 hours and then try. The problem should be solved. It happened with me.

心碎的声音 2024-09-24 18:44:03

对于发现此问题并且只是希望阻止首次连接时出现提示,但仍希望 ssh 严格检查后续连接上的密钥(首次使用时信任)的任何人,您可以设置 StrictHostKeyChecking 到 ~/.ssh/config 中的 accept-new ,这将执行您正在寻找的操作。您可以在 man ssh_config 中阅读更多相关信息。我强烈反对完全禁用密钥检查。

For anyone who finds this and is simply looking to prevent the prompt on first connection, but still wants ssh to strictly check the key on subsequent connections (trust on first use), you can set StrictHostKeyChecking to accept-new in ~/.ssh/config, which will do what you're looking for. You can read more about it in man ssh_config. I strongly discourage disabling key checking altogether.

坏尐絯℡ 2024-09-24 18:44:03

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

  1. 生成 ssh 密钥。系统将要求您为密钥创建密码
ssh-keygen -f ~/.ssh/id_ecdsa -t ecdsa -b 521

(上面使用推荐的加密技术)

  1. 将密钥复制到远程主机
ssh-copy-id -i ~/.ssh/id_ecdsa user@host

注意,用户@主机将与您不同。您需要输入该服务器的密码,而不是密钥密码。

  1. 您现在可以安全地登录服务器并且不会收到错误消息。
ssh user@host

所有来源信息都位于此处:
ssh-keygen

The following steps are used to authenticate yourself to the host

  1. Generate a ssh key. You will be asked to create a password for the key
ssh-keygen -f ~/.ssh/id_ecdsa -t ecdsa -b 521

(above uses the recommended encryption technique)

  1. Copy the key over to the remote host
ssh-copy-id -i ~/.ssh/id_ecdsa user@host

N.B the user @ host will be different to you. You will need to type in the password for this server, not the keys password.

  1. You can now login to the server securely and not get an error message.
ssh user@host

All source information is located here:
ssh-keygen

少女情怀诗 2024-09-24 18:44:03

我试图为 Github 添加 SSH 密钥,但尽管我正确执行了所有操作并且对 known_hosts 文件也具有适当的权限,但仍面临相同的错误。

这是我所缺少的以及修复它的方法。在 Github 上添加公钥时,您必须确保密钥名称是以下之一 -

  • id_rsa.pub
  • id_ecdsa.pub
  • id_ed25519.pub

这就是我做错的事情。因此,也许在 Github 上添加密钥时检查一次。

文档链接 - https://docs.github.com/en/authentication/connecting-to-github-with-ssh/checking-for-existing-ssh-keys#checking-for-existing- ssh 密钥

I was trying to add a SSH key for Github and was facing the same error despite of doing everything correctly and having appropriate permission for known_hosts file too.

Here's what I was missing and what fixed it. While adding the public key on Github, you have to make sure that key name is one of the following -

  • id_rsa.pub
  • id_ecdsa.pub
  • id_ed25519.pub

That's what I was doing wrong. So maybe check that once while adding the key on Github.

Link for docs - https://docs.github.com/en/authentication/connecting-to-github-with-ssh/checking-for-existing-ssh-keys#checking-for-existing-ssh-keys

表情可笑 2024-09-24 18:44:03

在主机服务器中运行它是预感问题

chmod -R 700 ~/.ssh

Run this in host server it's premonition issue

chmod -R 700 ~/.ssh
私野 2024-09-24 18:44:03

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

I had the same error and wanted to draw attention to the fact that - as it just happened to me - you might just have wrong privileges.
You've set up your .ssh directory as either regular or root user and thus you need to be the correct user. When this error appeared, I was root but I configured .ssh as regular user. Exiting root fixed it.

写给空气的情书 2024-09-24 18:44:03

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

This is trying to establish password-less authentication. So, if you try to run that command manually once, it will ask to provide the password there. After entering password, it saves that password permanently, and it will never ask again to type 'yes' or 'no'.

我最亲爱的 2024-09-24 18:44:03

对我来说,原因是我对 ~/.ssh/known_hosts 拥有错误的权限

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

For me the reason is that I have wrong permission on ~/.ssh/known_hosts.

I have no write permission on known_hosts file. So it ask me again and again.

三生路 2024-09-24 18:44:03

就我而言,主机未知,而不是在问题中输入“是” 您确定要继续连接(是/否/[指纹])吗?只需点击 enter 即可。

In my case, the host was unkown and instead of typing yes to the question are you sure you want to continue connecting(yes/no/[fingerprint])? I was just hitting enter .

铜锣湾横着走 2024-09-24 18:44:03

我解决了出现以下写入错误的问题:
错误:
无法确定主机“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. 现在您可以连接到该主机了。

该解决方案现在正在运行......

I solve the issue which gives below written error:
Error:
The authenticity of host 'XXX.XXX.XXX' can't be established.
RSA key fingerprint is 09:6c:ef:cd:55:c4:4f:ss:5a:88:46:0a:a9:27:83:89.

Solution:
1. install any openSSH tool.
2. run command ssh
3. it will ask for do u add this host like.
accept YES.
4. This host will add in the known host list.
5. Now you are able to connect with this host.

This solution is working now......

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文