AWS EC2 服务器拒绝连接-卸载替换的 authorized_keys-仍然无法连接

AWS EC2 服务器拒绝连接-卸载替换的 authorized_keys-仍然无法连接

所以我们当时正在为即将投入生产的服务器进行配置。在进行一些配置更改后,我们重新启动了机器,然后收到了可怕的“服务器拒绝连接”消息。

我尝试创建 AMI 并重新启动以尝试替换证书。但这没有奏效。

我还按照说明卸载硬盘并替换 authorized_keys,然后重新连接。我已经这样做了好几次。但这不起作用。

我唯一能想到的是,不久前我们在 sudoer 的文件中添加了一个人。此后,我用我知道有效的副本替换了 sudoers 文件,但这似乎也无济于事。

我该如何调试并修复该问题?我只是想从 AWS 控制台查看日志,但并没有发现太多信息。我有一个旧版本的服务器,它可以作为 AMI 使用,但它缺少我们最近做的很多工作。只是有点偏离正轨,但它在我的待办事项清单上 - 正如您所见,我确实做了备份 - 只是显然没有我应该的那么频繁。

谁能帮我调试一下可能存在的问题?

其他可能性我检查过权限吗?我相信我在 .ssh 文件夹上有 700 个权限,在 authorized_keys 上有 600 个权限

尽管我使用用户 ubuntu 登录,但密钥位于 /home/bitnami 文件夹中。这是基于 bitnami AMI - 我已经验证我确实使用 ubuntu 登录,但只有一个 bitnami 用户。

我使用腻子,但事件日志的样子如下:

2016-03-18 21:31:12 Using SSH protocol version 2
2016-03-18 21:31:12 We claim version: SSH-2.0-PuTTY_Release_0.63
2016-03-18 21:31:12 Doing Diffie-Hellman group exchange
2016-03-18 21:31:12 Doing Diffie-Hellman key exchange with hash SHA-256
2016-03-18 21:31:12 Host key fingerprint is:
2016-03-18 21:31:12 ssh-rsa 2048 1f:25:5b:d4:af:e6:b8:b5:e2:97:a7:76:b7:bf:ca:b2
2016-03-18 21:31:12 Initialised AES-256 SDCTR client->server encryption
2016-03-18 21:31:12 Initialised HMAC-SHA-256 client->server MAC algorithm
2016-03-18 21:31:12 Initialised AES-256 SDCTR server->client encryption
2016-03-18 21:31:12 Initialised HMAC-SHA-256 server->client MAC algorithm
2016-03-18 21:31:12 Reading private key file "C:\Users\mzuniga\keys\abc.ppk"
2016-03-18 21:31:31 Offered public key
2016-03-18 21:31:31 Server refused our key
2016-03-18 21:31:31 Disconnected: No supported authentication methods available (server sent: publickey)

AWS 控制台日志

/opt/bitnami/apache2/scripts/ctl.sh : httpd started at port 80
* Stopping System V runlevel compatibility[74G[ OK ]
     * Starting execute cloud user/final scripts[74G[ OK ]Cloud-init v. 0.7.5 running 'modules:final' at 
    Sat, 19 Mar 2016 04:16:00 +0000. Up 99.63 seconds.
    ci-info: +++++++++Authorized keys from /home/bitnami/.ssh/authorized_keys for user ubuntu++++++++++

看起来操作系统仍然完好无损。我是否可以采取某种策略来替换目录以恢复我需要的内容?我已经尝试替换似乎有密钥的整个 bitnmai 目录 - 然后也许可以尝试 /etc 目录等?

我目前有一个可以工作的旧版本,当前非工作版本安装在 /data 上。我已经验证了工作版本上没有 /home/ubuntu 文件夹。这最初是 magento 的 bitnami ami,工作版本是最近上传的,内容齐全,但没有主要配置。我已经验证了 authorized_keys 位于 /home/bitnami/.ssh/ 文件夹下,尽管我使用 ubuntu 登录,如 AWS 控制台日志中所述,并且经过相当长一段时间的调整。

我还可以验证您无法使用用户 ubuntu 或用户 bitnami 登录,但您可以在较旧的工作版本上使用任一用户。

答案1

为了解决这个问题,我使用了一台较旧的 AMI 并启动了该机器。然后我将当前驱动器安装到旧机器上的名为 /data 的文件夹中

我使用命令复制了 /etc 文件夹

sudo cp -a /etc /data/

我还复制了用户文件夹

sudo cp -a /home/bitnami /data/home

我还复制了根文件夹,因为我注意到其中有一些变化

sudo cp -a /root /data

我反复尝试了好几次,才意识到之前复制时可能没有正确设置权限,然后我看到一篇帖子告诉我在运行 cp 时使用 -a 选项。我复制完所有这些文件夹(包括密钥)后,我就可以再次登录了。

完成所有这些操作后,我在原来的机器上重新安装了驱动器,然后就能再次登录了。

相关内容