如何强制ssh从命令行接受新的主机指纹?

Joh*_*n O 27 ssh sftp arguments command-line-arguments

我得到了标准

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
Run Code Online (Sandbox Code Playgroud)

错误信息.然而,执行该命令的系统(Appworx)(SFTP我认为,这不是问题)是自动的,我不能轻易接受新的钥匙,甚至与第三方供应商,这是一个有效的改变检查后.我可以添加一个新的shell脚本,我可以从同一个系统(和用户)执行,但似乎没有一个命令或命令行参数会告诉ssh接受密钥.我在手册页或Google上找不到任何内容.当然这有可能吗?

Pet*_*ake 30

以下是告诉客户信任密钥的方法.一个更好的方法是提前给它一个关键,我在第二段中已经描述过了.这是针对Unix上的OpenSSH客户端,所以我希望它与您的情况相关.

您可以设置StrictHostKeyChecking参数.它有自己的选择yes,noask.默认是ask.要在系统范围内设置,请编辑/etc/ssh/ssh_config; 为你设置它,编辑~/.ssh/config; 并将其设置为单个命令,在命令行上提供选项,例如

ssh -o "StrictHostKeyChecking no" hostname
Run Code Online (Sandbox Code Playgroud)

如果您有权访问远程系统的主机密钥,另一种方法是提前将它们添加到您的known_hosts文件中,以便SSH知道它们并且不会提出问题.如果可以,从安全角度来看,它会更好.毕竟,警告可能是正确的,你可能会受到中间人攻击.

例如,这是一个脚本,它将检索密钥并将其添加到known_hosts文件中:

ssh -o 'StrictHostKeyChecking no' hostname cat /etc/ssh/ssh_host_dsa_key.pub >>~/.ssh/known_hosts
Run Code Online (Sandbox Code Playgroud)

  • 糟糕的主意。检查其他答案和评论以了解原因和更好的替代方案。tldr:使用 `StrictHostKeyChecking=accept-new` 代替。 (8认同)
  • 我不打算压制警告.我已经知道了,未来我会得到更多.我想要一个脚本,在我收到警告后,我可以运行脚本并让它回答"是",而不是它是交互式的.我无法输入"是".我希望有一个"连接到这个主机,回答是,并断开"ssh的论点,或某种方式来完成相同的事情. (3认同)
  • @cregox这不是一个糟糕的主意,你只是阅读理解能力很差。这对我来说是几年前的事了,但我没有办法交互式地使用该系统。我无法进入并手动将密钥更新为新密钥。在我的情况下,我已经与外部主机(通过电话和电子邮件)核实,这确实只是他们这边不可避免的系统问题。我还能够编写一个可以执行的脚本,以代替我坐在那里并使用键盘来确认我想要这个。它不是自动化的,我必须调用脚本。没有人提供替代方案。 (2认同)

Oz1*_*123 28

虽然常识是不要禁用主机密钥检查,但 SSH 本身有一个内置选项可以执行此操作。它相对不为人知,因为它是新的(在 Openssh 6.5 中添加)。

这是通过-o StrictHostKeyChecking=accept-new.

警告:仅当您绝对信任要通过 SSH 连接到的 IP\主机名时才使用它:

ssh -o StrictHostKeyChecking=accept-new mynewserver.example.com
Run Code Online (Sandbox Code Playgroud)

注意,即使密钥已更改,StrictHostKeyChecking=no也会添加公钥。 仅适用于新主机。从手册页~/.ssh/known_hosts accept-new

如果此标志设置为“accept-new”,则 ssh 将自动将新的主机密钥添加到用户已知的主机文件中,但不允许连接到主机密钥已更改的主机。如果此标志设置为“no”或“off”,ssh 将自动将新的主机密钥添加到用户已知的主机文件中,并允许连接到已更改主机密钥的主机,但受到一些限制。如果这个标志设置为 ask(默认),只有在用户确认这是他们真正想要做的事情后,新的主机密钥才会被添加到用户已知的主机文件中,并且 ssh 将拒绝连接到其主机密钥的主机已经改变。在所有情况下都会自动验证已知主机的主机密钥。

为什么-o StrictHostKeyChecking=no是恶?

当您不检查主机密钥时,您可能会在另一台计算机上通过 SSH 会话登陆(是的,这可以通过IP Hijacking 实现)。然后可以使用不属于您的恶意服务器来窃取密码和所有类型的数据。接受一个新的未知密钥也很危险。只有在对网络有绝对信任或服务器没有受到损害时才应该这样做。就个人而言,我仅在机器启动后立即使用cloud-init在云环境中启动机器时才使用此标志。

  • `accept-new` 仅适用于新主机,不适用于主机密钥更改的情况 - 这就是这个问题的目的。 (3认同)
  • 这应该是公认的答案! (2认同)

AJ *_*ter 27

这里的答案是可怕的建议.你永远不应该在任何真实世界的系统中关闭StrictHostKeyChecking(例如,如果你只是在自己的本地家庭网络上玩,它可能没问题 - 但是其他任何事情都不能这样做).

而是使用:

ssh-keygen -R hostname
Run Code Online (Sandbox Code Playgroud)

这将强制known_hosts更新文件以仅删除已更新其密钥的一个服务器的旧密钥.

然后当你使用:

ssh user@hostname
Run Code Online (Sandbox Code Playgroud)

它会要求您确认指纹 - 就像任何其他"新"(即以前看不见的)服务器一样.

  • 请所有人注意:这是唯一正确的答案!例如,在本地开发Docker容器上使用`StrictHostKeyChecking no`,该容器会在每次映像更新时更改其主机密钥,但请勿将其用于实时服务器!真的,你不想要那个! (4认同)
  • 这说明以交互方式添加密钥。因此,这不是唯一的答案,因为您可以提供* act *键。这样比较好,因为您使用的是已知有效的副本。它还允许自动化。 (2认同)
  • 您还可以使用“StrictHostKeyChecking accept-new”接受新密钥,但在保存的密钥冲突时仍拒绝连接。 (2认同)

Loc*_*ith 7

只是添加最“现代”的方法。
与所有其他答案一样 - 这意味着您盲目地接受来自主机的密钥。谨慎使用!

HOST=hostname; ssh-keygen -R $HOST && ssh-keyscan -Ht ed25519 $HOST >> "$HOME/.ssh/known_hosts"
Run Code Online (Sandbox Code Playgroud)

首先使用 删除任何条目-R,然后生成一个散列 ( -H)known_hosts条目,我们将其附加到文件末尾。

这个答案一样,更喜欢 ed25519。


Ear*_*uby 6

由于您尝试通过在正在执行ssh-ing的主机上运行bash脚本来实现自动化,并假设:

  • 您不想忽略主机密钥,因为这会带来额外的安全风险。
  • 您要切换的主机上的主机密钥很少更改,并且如果这样做,则存在良好的众所周知的原因,例如“目标主机已重建”
  • 您想要运行一次此脚本以将新密钥添加到known_hosts,然后known_hosts不理会。

在您的bash脚本中尝试以下操作:

# Remove old key
ssh-keygen -R $target_host

# Add the new key
ssh-keyscan $target_host >> ~/.ssh/known_hosts
Run Code Online (Sandbox Code Playgroud)


小智 5

您只需更新从服务器发送的当前指纹即可。只需输入以下内容即可开始:)

ssh-keygen -f "/home/your_user_name/.ssh/known_hosts" -R "server_ip"
Run Code Online (Sandbox Code Playgroud)