在同一个IP地址但是不同的操作系统上进行SSH登录？

Question 1

有几种潜在的解决方案。

最简单的解决方案是 davidgo 在他的回答中提出的解决方案，正如他提到的那样，这会让您容易受到 MitM 攻击（不太可能，但即使在私人情况下也应采取良好的安全措施）。

  Host 192.168.5.163
      StrictHostKeyChecking no
      UserKnownHostsFile /dev/null

正如 Eugen Rieck 所建议的，一个稍微好一点的解决方案是/etc/ssh/ssh_host_*key*在两个目标操作系统之间同步文件。

更可靠的方法是专门决定要连接到哪个操作系统，这样如果连接到错误的操作系统，您就会收到错误。例如，如果使用 ssh 的脚本针对错误的操作系统，则会导致脚本失败。
您可以通过在中有效地使用别名来实现这一点~/.ssh/ssh_config。

Host raspbian-pi
  Hostname 192.168.5.163
  UserKnownHostsFile ~/.ssh/known_hosts_raspbian

Host centos-pi
  Hostname 192.168.5.163
  UserKnownHostsFile ~/.ssh/known_hosts_centos

然后，您可以连接ssh <your_user>@raspbian-pi以检索 Raspbian OS 密钥，然后在 Raspberry Pi 上切换到 CentOS，执行相同操作ssh <your_user>@centos-pi以获取 CentOS 密钥。然后，将来，每当您连接到错误的操作系统时，您都会收到主机密钥错误。确保第一次使用 SSH 命令时使用正确的操作系统，这样您就不会意外地将 CentOS 主机密钥存储在 Raspbian 已知主机文件中。

免责声明：我从未使用过这个解决方案，也无法对其进行测试，但根据我的理解和 ssh 文档，它应该可以正常工作。

Answer

有几种潜在的解决方案。

最简单的解决方案是 davidgo 在他的回答中提出的解决方案，正如他提到的那样，这会让您容易受到 MitM 攻击（不太可能，但即使在私人情况下也应采取良好的安全措施）。

  Host 192.168.5.163
      StrictHostKeyChecking no
      UserKnownHostsFile /dev/null

正如 Eugen Rieck 所建议的，一个稍微好一点的解决方案是/etc/ssh/ssh_host_*key*在两个目标操作系统之间同步文件。

更可靠的方法是专门决定要连接到哪个操作系统，这样如果连接到错误的操作系统，您就会收到错误。例如，如果使用 ssh 的脚本针对错误的操作系统，则会导致脚本失败。
您可以通过在中有效地使用别名来实现这一点~/.ssh/ssh_config。

Host raspbian-pi
  Hostname 192.168.5.163
  UserKnownHostsFile ~/.ssh/known_hosts_raspbian

Host centos-pi
  Hostname 192.168.5.163
  UserKnownHostsFile ~/.ssh/known_hosts_centos

然后，您可以连接ssh <your_user>@raspbian-pi以检索 Raspbian OS 密钥，然后在 Raspberry Pi 上切换到 CentOS，执行相同操作ssh <your_user>@centos-pi以获取 CentOS 密钥。然后，将来，每当您连接到错误的操作系统时，您都会收到主机密钥错误。确保第一次使用 SSH 命令时使用正确的操作系统，这样您就不会意外地将 CentOS 主机密钥存储在 Raspbian 已知主机文件中。

免责声明：我从未使用过这个解决方案，也无法对其进行测试，但根据我的理解和 ssh 文档，它应该可以正常工作。

Question 2

您可以按照错误中的说明解决当前问题（每次切换盒子时都必须这样做） -

ssh-keygen -f "/home/joedoe/.ssh/known_hosts" -R "192.168.5.163"

您遇到的问题是，您的计算机检测到其登录的系统与之前看到的系统不同，并且发出警告是为了防止中间人攻击。

有多种方法可以正确处理此问题。它们包括：

为每个框设置名称/etc/hosts，然后通过名称而不是 IP 引用 SSH 连接。这样 SSH 就会将不同的服务器指纹与每个名称关联起来。
忽略检查（这会使你遭受中间人攻击，因此只有当你理解并能承受风险时才可以这样做。）你可以通过-o UserKnownHostsFile=/dev/null在 ssh 命令中添加以下内容来忽略此检查，或者-o StrictHostKeyChecking=no

2a. 您可以通过将以下内容放入以下配置中来创建仅忽略一个 IP 的密钥检查的配置~/.ssh/config

主机 192.168.5.163 StrictHostKeyChecking 没有 UserKnownHostsFile=/dev/null
除非机器充当相同的角色，否则我不建议这样做，但您可以/etc/ssh在两台服务器（以及您更改的那台服务器）上将主机密钥设置为相同restart sshd。这样，两台服务器在客户端看来就是一样的。

Answer

您可以按照错误中的说明解决当前问题（每次切换盒子时都必须这样做） -

ssh-keygen -f "/home/joedoe/.ssh/known_hosts" -R "192.168.5.163"

您遇到的问题是，您的计算机检测到其登录的系统与之前看到的系统不同，并且发出警告是为了防止中间人攻击。

有多种方法可以正确处理此问题。它们包括：

为每个框设置名称/etc/hosts，然后通过名称而不是 IP 引用 SSH 连接。这样 SSH 就会将不同的服务器指纹与每个名称关联起来。
忽略检查（这会使你遭受中间人攻击，因此只有当你理解并能承受风险时才可以这样做。）你可以通过-o UserKnownHostsFile=/dev/null在 ssh 命令中添加以下内容来忽略此检查，或者-o StrictHostKeyChecking=no

2a. 您可以通过将以下内容放入以下配置中来创建仅忽略一个 IP 的密钥检查的配置~/.ssh/config

主机 192.168.5.163 StrictHostKeyChecking 没有 UserKnownHostsFile=/dev/null
除非机器充当相同的角色，否则我不建议这样做，但您可以/etc/ssh在两台服务器（以及您更改的那台服务器）上将主机密钥设置为相同restart sshd。这样，两台服务器在客户端看来就是一样的。

Question 3

最简单的方法是/etc/ssh/ssh_host_*_key*从一个安装复制到另一个安装 - 这将为两个操作系统提供相同的主机密钥，从而提供指纹。

Answer

最简单的方法是/etc/ssh/ssh_host_*_key*从一个安装复制到另一个安装 - 这将为两个操作系统提供相同的主机密钥，从而提供指纹。

Question 4

我个人为所有 Linux 服务器使用 OpenSSH 证书颁发机构。这节省了我以前设置新证书颁发机构和协调终端设备（台式机、笔记本电脑和跳转主机）的很多麻烦。博客中提到。

虽然此功能最初并非为这种（不寻常的）用例而设计的，但它为该问题提供了另一种解决方案。只需使用 CA 的私钥对两个主机密钥进行签名，并将公共部分添加到您的文件中，您的 SSH 客户端就会自动信任这两组主机密钥，而不会向您大喊大叫，告知您存在差异。不过，known_hosts您可能仍需要事先删除任何记住的主机密钥。ssh-keygen -R

这样做的好处是，两个系统都可以保持主机密钥的独立性和差异性，这样你就可以通过主机密钥（和证书 - 有一个“身份”字段，你可以在签署证书时自定义）来区分它们。这也是安全的，因为你不必盲目地信任出现在特定 IP 地址上的任意主机。

即使你想保护自己免遭密钥泄露，你也可以在签署证书时将“允许的名称/IP 地址”添加为“主体”，例如：

ssh-keygen -s my_ca -I "RaspOS on RPi" -h -n 192.0.2.0 ssh_host_rsa_key.pub

该证书将不是除非来自主机，否则不予信任192.0.2.0，除非攻击者以某种方式劫持您的流量此外主机密钥和证书。

好吧，现在我不得不承认，在两个操作系统之间复制主机密钥更容易，因为它们毕竟在同一台物理机器上。

Answer