☰

处理 SSH 主机验证错误的最顺畅的工作流程？

tag-icon • tag-icon linux ssh command-line-interface ssh-keys
处理 SSH 主机验证错误的最顺畅的工作流程？

这是一个我们都面临的简单问题，可能无需多想就可以手动解决。

当服务器发生变化、重新配置或重新分配 IP 地址时，我们会收到下面的 SSH 主机验证消息。我有兴趣简化工作流程以解决这些 ssh 识别错误。

给出以下消息，我通常vi /root/.ssh/known_hosts +434会删除（dd）有问题的行。

我见过其他组织的开发人员/用户删除他们的全部的 known_hosts看到这条消息后，我感到很沮丧。虽然我没有那么做，但我知道有一种更优雅的方式来处理这个问题。

尖端？

[root@xt ~]# ssh las-db1

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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
ed:86:a2:c4:cd:9b:c5:7a:b1:2b:cc:42:15:76:8c:56.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:434
RSA host key for las-db1 has changed and you have requested strict checking.
Host key verification failed.

答案1

您可以使用以下ssh-keygen命令按主机删除特定条目：

ssh-keygen -R las-db1

如果您没有该命令，您可以随时使用 sed：

sed -i '/las-db1/d' /root/.ssh/known_hosts

答案2

作为一个 Puppet 用户，我解决这个问题的方法是让我的 Puppet 服务器收集我的 SSH 主机密钥并将它们发布到所有建立 SSH 连接的系统。

这样我就不必担心删除它们了。99% 的时间里，puppet 都在运行，并且为我更新了密钥，因为我的代理每 30 分钟运行一次。对我来说，例外情况非常少见，所以如果我不愿意等待，我不介意快速编辑系统范围内的 known_hosts。

class ssh::hostkeys {

  @@sshkey { "${::clientcert}_rsa":
    type => rsa,
    key => $sshrsakey,
    tag => 'rsa_key',
  }

  if 'true' == $common::params::sshclient {
    Sshkey <<| tag == 'rsa_key' |>> {
      ensure => present
    }
  }

  file {'/etc/ssh/ssh_known_hosts':
    ensure => present,
    owner => 'root',
    group => 'root',
    mode => 0644,
  }

}

答案3

我想补充一条建议，它能够在非常特殊且不太需要担心安全性的情况下为您提供帮助。

我有一个实验室环境，其中的机器经常重新安装。每次发生这种情况时，都会生成新的主机密钥（我可能可以将主机密钥保存在某处并在安装后脚本中设置它）。

由于在这个实验室环境中安全性对我来说不是问题，并且密钥经常更改，因此我的 .ssh/config 文件中有以下内容：

Host lab-*
  User kenny
  IdentityFile ~/.ssh/lab_id_rsa
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null

这确保连接到我的实验室机器不会再导致该错误，并且我的 ssh 客户端将直接连接而无需检查主机密钥。

只有当您根本不关心安全性时才应该这样做，因为这会使您处于容易受到中间人攻击的境地。

答案4

SSHFP DNS ResourceRecord 可能会有所帮助，具体取决于您的 ssh 客户端利用它的程度。将所有 ssh 公钥指纹与主机名一起存储在那里。

预先实施 DNSSEC 或 DNS over SSL。
http://www.ietf.org/rfc/rfc4255.txt

FreeIPA.org 负责处理主机和用户密钥管理以及 PKI 证书。它还会在创建新密钥时自动上传 SSHFP DNS 记录。

系统安全服务守护进程 (SSSD) 可以配置为缓存和检索主机 SSH 密钥，这样应用程序和服务只需在一个位置查找主机密钥。由于 SSSD 可以使用 FreeIPA 作为其身份信息提供者之一，因此 FreeIPA 提供了一个通用且集中的密钥存储库。管理员无需担心分发、更新或验证主机 SSH 密钥。

http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/host-keys.html

相关内容