AWS EC2 公钥突然被拒绝

Question

您好，我的 AWS EC2 公钥突然被拒绝了。

我已经根据实例检查了密钥，并且我使用了正确的密钥。

我检查了端口 22 是否可以通过我的安全组访问，这看起来不错。

我没有对 aws 进行任何更改，并且我在实例上的 Web 服务器工作正常，所以我知道该实例可以连接。

有没有可能我的钥匙被人篡改了。

这是我用来访问我的 debian 实例的命令，到目前为止它一直“sshing”很好。

ssh -o "ServerAliveInterval 180" -i key.pem admin@xx.xx.xx.xxx

非常感谢何塞

编辑

这里是详细的输出：

 $ ssh -v -o "ServerAliveInterval 180" -i /Users/Jose/Workspace/build/prod-key.pem admin@52.51.xx.14


OpenSSH_6.9p1, LibreSSL 2.1.8

debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 52.51.xx.14 [52.51.xx.14] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /Users/Jose/Workspace/build/prod-key.pem type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/Jose/Workspace/build/prod-key.pem-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4+deb7u4
debug1: match: OpenSSH_6.0p1 Debian-4+deb7u4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 52.51.xx.14:22 as 'admin'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr umac-64@openssh.com none
debug1: kex: client->server aes128-ctr umac-64@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:ZKUAyMwCyvgy42SSYy8+hNsYKz13m0u0Uwp1RvXSAac
debug1: Host '52.51.xx.14' is known and matches the ECDSA host key.
debug1: Found key in /Users/Jose/.ssh/known_hosts:2
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/Jose/Workspace/build/prod-key.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Answer 1

有没有可能是我的密钥被篡改了？

是的，它总是可能的，你不能排除它，但是它可能是这种情况，我会怀疑。 （当然这取决于你的服务器在做什么）。

大多数情况下，某些服务或某些配置已更改但直到稍后才应用，即服务器重新启动或其他自动进程重新启动。

无论如何here 与您的票非常相似。我在哪里提供了您如何调查同样的问题。

假设您没有异地日志记录、任何远程配置管理软件（Puppet、Ansibel、Cheef 等）或您可以尝试 ssh 的其他用户。

在我看来，进一步调查此问题的唯一选择是（假设您不想关闭服务器）：

1. 拍摄受影响实例的根卷的快照。
2. 从快照中创建一个卷。
3. 在工作良好的实例上安装新卷。
4. 转到已安装的卷并进行调查。