好的，我一直在尝试连接到我的 EC2 实例，但一直收到可怕的错误：权限被拒绝（公钥）。我知道这个问题已经被问了几十次，但我按照我能找到的每一个回复都做了，但都无济于事。我正在 EC2 上运行一个微型实例，试图从 Ubuntu 桌面进行 SSH。这是奇怪的部分。我按照这Ubuntu.com 上的指南，它最初让我进入。我进入，设置了 nginx 和一些其他东西。然而，在一段时间后尝试重新连接时，我得到了上面的错误。我使用以下 SSH 命令：
sudo ssh -v -v -i /home/user/.ec2/keypair.pem [email protected]
Keypair.pem 是我第一次创建实例时创建的私钥，也是我成功登录时使用的私钥。IP 地址是分配给此实例的弹性 IP 地址（我也尝试过公共 DNS，但没有成功）。我安装了 EC2 API 工具，并且能够访问有关我的实例的信息，因此我相信证书正常工作。这是另一件奇怪的事情。当我尝试使用 ec2-user 连接时，我只收到权限被拒绝（公钥）错误；然而，当我尝试以 root 身份连接时（[电子邮件保护]）， 它说：
Authentication succeeded (publickey)
但是之后：
Please login as the ec2-user user rather than root user.
然后继续将我踢出。这会让我相信公钥确实是正确的，但我不确定。我尝试再次重新创建证书（不确定这是否有用），但没有成功。此外，我听说本地权限问题，所以我尝试将私钥的权限调整为 600 和 700，但这并没有解决问题。如果对 SSH 的输出感兴趣，您可以在下面找到它：
OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to x.x.x.x [x.x.x.x] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/user/.ec2/keypair.pem type -1
debug1: identity file /home/user/.ec2/keypair.pem-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],ssh-rsa,[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 134/256
debug2: bits set: 532/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 06:09:47:f7:46:55:8a:b1:9a:18:e4:46:b6:6d:88:7e
debug1: Host 'x.x.x.x' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug2: bits set: 505/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/user/.ec2/keypair.pem ((nil))
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ec2/keypair.pem
debug1: read PEM private key done: type RSA
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
答案1
当你从 A ssh 到 B 时，你需要一份你 ssh 连接的用户的私钥副本。你需要 ssh 连接的用户的主目录中 .ssh/authorized_keys 文件中的公钥内容。
因此例如，如果您从机器 a 上的 bob 通过 ssh 连接到机器 b 上的 fred，则需要 /home/bob/.ssh/some_key 和 /home/fred/.ssh/authorized_keys 来包含 bob 的公钥的副本。
ssh 连接到 root 可以正常工作，这意味着 root 用户的主目录在其 authorized_keys 文件中拥有公钥。您无法连接到其他用户，这表明该用户的 authorized_keys 文件中没有公钥的副本。
sudo 命令仅在您明确指定密钥文件时才有效，通常您会以自己的身份运行 sudo，因为如果您正确设置密钥，您可以从您的帐户连接到任何用户（甚至是 root 用户）。
那么，您是否将公钥内容复制到目标机器上的 ec2-user 的 authorized_keys 文件中？
或者您可能生成了一个新的密钥对并且使用了错误的私钥？
答案2
首先，为什么要使用 sudo 来执行 ssh？
其次，尝试这样做：
sudo ssh -v -v -i /home/user/.ec2/keypair.pem -l ec2-user 107.20.201.235