我已经对这个问题进行了大量搜索，但没有找到任何特别相关的内容。
我有许多实例分布在各个区域，并分组到不同的负载均衡器中。其中一个组是各种不同应用程序用于执行常见和安全任务的“API”。
在 API 组中，我们有一个使用弹性 IP 的实例，这样我们就可以可靠地使用 cron 执行诸如 rsync 等任务。在我之前，有人也认为以典型的意大利面条式代码（if else forest 风格）将此 IP 硬编码到各种应用程序中是个好主意...长话短说，这是非常重要的实例。
两天前，我突然无法通过 SSH 连接到这个家伙（它是一年多前创建的）。 pem 密钥适用于所有其他实例，这些实例存在的时间相对相同。
这是昨天尝试使用以下方法失败的主计算机连接的输出：ssh -v -i 路径/文件.pem 用户@ip
ssh -v -i <path>/<file>.pem <user>@<ip>
OpenSSH_5.8p1 Debian-7ubuntu1, OpenSSL 1.0.0e 6 Sep 2011
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to <ip> [<ip>] port 22.
debug1: Connection established.
debug1: identity file /home/<user>/.ssh/id_rsa type -1
debug1: identity file /home/<user>/.ssh/id_rsa-cert type -1
debug1: identity file /home/<user>/.ssh/id_dsa type -1
debug1: identity file /home/<user>/.ssh/id_dsa-cert type -1
debug1: identity file /home/<user>/.ssh/id_ecdsa type -1
debug1: identity file /home/<user>/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-7ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 75:43:6d:03:43:f5:89:fa:8d:fe:64:e1:39:9a:73:26
debug1: Host '<ip>' is known and matches the ECDSA host key.
debug1: Found key in /home/<user>/.ssh/known_hosts:78
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: .ssh/<file>.pem
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/<user>/.ssh/id_rsa
debug1: Trying private key: /home/<user>/.ssh/id_dsa
debug1: Trying private key: /home/<user>/.ssh/id_ecdsa
debug1: No more authentication methods to try.
Permission denied (publickey).
最后，在搜索了几个小时该如何处理这个问题之后，我运行ssh -Tvvv -i 路径/文件.pem 用户@ip神奇的是，我与该实例建立了调试连接。
这是在家里的一台机器上完成的。我切断了连接，然后正常连接。没有问题。从办公室的服务器连接也没有问题。
今天我无法从办公室的机器通过 SSH 进入实例，并且所有转换的密钥也不适用于此实例（即 filezilla 的 ppk 密钥等）
以下是来自工作机器（家用机器）的 -v 调试输出
ssh -v -i <path>/<file>.pem <user>@<ip>
OpenSSH_5.8p1 Debian-7ubuntu1, OpenSSL 1.0.0e 6 Sep 2011
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to <ip> [<ip>] port 22.
debug1: Connection established.
debug1: identity file /home/<user>/.ssh/<file>.pem type -1
debug1: identity file /home/<user>/.ssh/<file>.pem-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-7ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 75:43:6d:03:43:f5:89:fa:8d:fe:64:e1:39:9a:73:26
debug1: Host '<ip>' is known and matches the ECDSA host key.
debug1: Found key in /home/<user>/.ssh/known_hosts:78
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: .ssh/<file>.pem
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/<user>/.ssh/<file>.pem
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to <ip> ([<ip>]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: Remote: Ignored authorized keys: bad ownership or modes for directory /home/<user>
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Welcome to blah...
所有密钥的权限在实例之间以及连接到实例的机器之间都是相同的。
有人知道该怎么做才能纠正这个问题吗？
谢谢，-David
- 编辑 -
这是仍然无法建立 SSH 连接的工作机器的 -v 调试输出。
我最近还清除了这台机器上的已知主机。
ssh -v -i <path>/<file>.pem <user>@<ip>
OpenSSH_6.0p1 Debian-3ubuntu1, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to <ip> [<ip>] port 22.
debug1: Connection established.
debug1: identity file /home/<user>/.ssh/<file>.pem type -1
debug1: identity file /home/<user>/.ssh/<file>.pem-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-3ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 75:43:6d:03:43:f5:89:fa:8d:fe:64:e1:39:9a:73:26
debug1: Host '<ip>' is known and matches the ECDSA host key.
debug1: Found key in /home/<user>/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
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: /home/<user>/.ssh/<file>.pem
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
我想重申，无论是否可以建立 ssh 连接，所有转换后的密钥都不适用于 sftp。具体来说，转换后的 .ppk 密钥可用于 filezilla。同样，.ppk 适用于除问题子实例之外的所有其他实例……并且以前也有效。
--编辑2--
我能够连接的机器已重新启动，并且我无法再连接它。
答案1
这是您的问题：
debug1: Remote: Ignored authorized keys: bad ownership or modes for directory /home/<user>
您的用户主目录可能不是组或全局可写的，并且目录.ssh可能.ssh/authorized_keys只有用户可读。修复权限后，您应该会发现您的登录再次可用。
答案2
根据我的经验，我学会了使用以下方法终止行为异常的 EC2 实例极端偏见。由于您的密钥适用于其他实例，而不适用于此特定实例，因此我会将其归结为混乱的实例。如果您确实需要该服务器上的数据，您可以随时关闭它并将 ebs 卷安装到另一个实例上，然后从那里执行恢复。