重用弹性 IP 时出现 AWS 实例 SSH 连接问题

mas*_*aki -1 linux ssh amazon-ec2 openvpn amazon-web-services

重建

  1. 创建实例

  2. 为您创建的实例分配并关联一个新的弹性 IP

  3. 通过寻址您在步骤 2 中与您的实例关联的弹性 IP,通过 ssh 连接到一个实例,以查看您是否已经建立了没有问题的连接

    $ ssh -i "YouKey.pem" openvpnas@192.168.0.1

  4. 关闭与您的实例的连接

  5. 终止您的实例

  6. 创建一个具有相同堆栈和配置的新实例

  7. 关联您在步骤 2 中创建的弹性 IP

  8. 尝试通过 ssh 连接您在步骤 6 中创建的实例,方法是通过寻址您在步骤 7 中与新实例关联的弹性 IP

  9. 您将获得主机密钥验证失败,例如:

    $ ssh -i "YourKey.pem" openvpnas@192.168.0.1 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@ @ 警告:远程主机标识已更改!@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@ 有人可能正在做一些令人讨厌的事情!现在有人可能正在窃听你(中间人攻击)!主机密钥也可能刚刚被更改。远程主机发送的 RSA 密钥的指纹为 ff:01:ff:01:ff:01:ff:01:ff:01:ff:01:ff:01:ff:01。请联系您的系统管理员。在“Path-To-Your-Host-Key”/known_hosts 中添加正确的主机密钥以消除此消息。'Path-To-Your-Host-Key'/known_hosts:14 中的违规 RSA 密钥 192.168.0.1 的 RSA 主机密钥已更改,您已要求进行严格检查。主机密钥验证失败。

*仅供参考:StackOverflow 我想按照您的指示将其发布在服务器故障上,但我会保持原样, 因为已经有一段时间了,而且似乎人们可以访问这篇文章。 我认为这可能是不做的一个很好的例子?? 在此处输入图片说明

mas*_*aki 6

原因 此问题是由与旧实例关联的弹性 IP 冲突引起的。在您的 known_hosts 文件中,您的主机地址已与来自主机的指纹相关联。您的客户拒绝了您的请求,因为您的新主机为您的客户提供了新指纹。

解决方案 有几种方法可以解决此问题并与您的实例建立连接,如下所示: A. 分配一个新的弹性 IP 并将其与您的新实例关联或 B. 从您的“known_hosts”文件 192.168.0.1 中删除您的旧主机密钥ssh-rsa "##################### 你很长的(1024 位或更多)RSA 密钥字符串在这里########### ############"

跟进 如果您遇到了这个问题并最终阅读了本文,那么您就已经了解了身份验证如何通过 Mac OS X 终端与您的 ssh 客户端和实例一起工作。当您解决了这个问题并通过 SSH 建立了良好的连接后,现在您就明白了警告“警告:将 '192.168.0.1' (RSA) 永久添加到已知主机列表中”的含义。

$ ssh -i "YourKey.pem" openvpnas@192.168.0.1
The authenticity of host '192.168.0.1 (192.168.0.1)' can't be established.
RSA key fingerprint is ff:01:ff:01:ff:01:ff:01:ff:01:ff:01:ff:01:ff:01.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.1' (RSA) to the list of known hosts.
Welcome to OpenVPN Access Server Appliance 2.0.25


The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
..
Run Code Online (Sandbox Code Playgroud)

  • 根据环境,`ssh -o KnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@host` 是一个有用的解决方法。主机密钥永远不会在 /dev/null 中找到,因此每次连接时都会将其“附加”到其中(ha,ha)。只有在主机被破坏的低风险证明禁用此机制的环境中才有好处。 (3认同)