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

41

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

随着服务器的更改，重新配置或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.

— 怀特
source

我们有同样的问题。我没有使用NASA的Mesh ti.arc.nasa.gov/opensource/projects/mesh的经验，但这是我要审查的技术列表。

— 安德鲁·吉尔马丁

1

在重新安装/重新分配服务器时，为什么不复制旧密钥呢？

— Random832

@ Random832在拥有大量服务器的情况下，或者在实验室/测试环境中经常回收IP地址的情况下，它无法扩展。或其他情况；在原服务器不可用的情况下计划外更换服务器...

— ewwhite 2012年

3

我有一个大问题：您如何进入这种情况？如果要重新使用主机名，则可能需要重新考虑主机命名标准（tools.ietf.org/html/rfc1178）。如果要重新使用IP地址，则应该使用与关闭该IP地址上的先前服务器相同的过程来停用ssh密钥。如果您在“网络规模”环境中工作，其中IP重复使用是自动发生的，并且半无意义的主机名是强制性的，那么您应该有一个自动化程度足够高的服务器生命周期过程，以便能够修复ssh密钥

— Paul Gear

47

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

ssh-keygen -R las-db1

如果没有该命令，则可以始终使用sed：

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

— 凯尔·勃兰特（Kyle Brandt）
source

3

当出现此问题时，使用ssh-keygen -R解决密钥冲突问题也是Ubuntu中的ssh客户端在错误消息中建议的内容。

— 肯尼·拉沙特

我不知道该ssh-keygen命令的切换。好！

— ewwhite 2012年

10

记住要检查一下，确保没有人真的在“做一些NASTY”！

— 迈克尔·汉普顿

1

确保您不在会议上这样做！

— Paul Gear

2

@ewwhite您/etc/ssh/known_hosts可以使用适当的主机密钥（受管理的w /人偶等）填充网络上的文件，或者填充您的〜/ .ssh / known_hosts个人文件（执行上述任一操作都可以ssh-keyscan在已知良好/安全的环境下运行）连接）。除非您设置了（并且假设您根本不关心安全性）UserKnownHostsFile=/dev/null和StrictHostKeyChecking=no您的设置~/.ssh/config file（或将选项通过ssh传递给ssh -o）

— voretaq7 2012年

25

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

这样，我不必担心删除它们。由于我的代理每三十分钟运行一次，因此有百分之九十九的时间运行了木偶并为我更新了密钥。对我而言，例外非常罕见，因此，如果我不愿意等待，那么我不介意对系统范围内的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,
  }

}

— Zoredache
source

+1整合配置管理工具的好举动。

— ewwhite 2012年

4

我想添加一个建议，它可以在不太关注安全性的特定情况下为您提供帮助。

我在实验室环境中拥有经常重新安装的计算机。每次发生时，都会生成新的主机密钥（我可以将主机密钥保存在某个地方，然后在安装后脚本中进行设置）。

由于在此实验室环境中安全性对我而言不是问题，并且密钥更改如此频繁，因此我的.ssh / config文件中包含以下内容：

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

这样可以确保连接到我的实验室计算机永远不会再次导致该错误，并且我的ssh客户端将仅在不检查主机密钥的情况下进行连接。

只有在安全性根本不涉及您的情况下，才应执行此操作，因为这会使您处于容易受到中间人攻击的位置。

— 肯尼·拉沙特（Kenny Rasschaert）
source

1

似乎有风险。我想保留主机验证，因为其中一些是面向公众的系统。

— ewwhite 2012年

1

这就是为什么他提到此方法仅用于“安全程度较低/无关紧要的情况”的原因。专用网络/实验室环境非常适合此配置。多机自动缩放生产/面向公众的系统，不是很多。

— dannosaur，2014年

4

根据openssh 5.6发行说明，您不再需要使用主机密钥：

基于主机的身份验证现在可以使用证书主机密钥。必须使用sshd（8）中所述的@ cert-authority标记在known_hosts文件中指定CA密钥。

警告：到目前为止，我还从未听说过有人在生产中使用此功能。使用时需要您自担风险（但我相信，openssh开发人员会非常妄想，如果不进行大量测试和代码审核，就不会发布这样的杀手级功能）。

2

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

事先实施DNSSEC或SSL上的DNS。
http://www.ietf.org/rfc/rfc4255.txt

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

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

http://docs.fedoraproject.org/zh-CN/Fedora/17/html/FreeIPA_Guide/host-keys.html

— j
source