AWS - Заблокированный из EC2 после rsync'ing/home/ubuntu каталог

TL; DR
Я rsyncредактор несколько каталогов от /home/ubuntu (набор к 777) из одного удаленного сервера к моему новому экземпляру AWS EC2. Я теперь заблокирован из sshлуг в него a Permission denied (publickey) ошибка.

Я нахожусь в процессе миграции моей продуктивной среды от SoftLayer до AWS.

Я имел к rsync несколько каталогов к EC2 (EBS) и в процессе, я действительно передавал несколько каталогов от старого /home/ubuntu/ к моему текущему экземпляру EC2 /home/ubuntu/.

Мой rsync команда (на месте назначения) была похожа на это.

ubuntu@[aws.remote.ec2]:~$ sudo rsync --include 'dir1' --include '*.sh' --include '.py' --include 'api_logs' --include 'database_backups' --exclude '*' -avz -e "ssh -p $portNumber" ubuntu@[softlayer.remote]:/home/ubuntu/ /home/ubuntu/

Файлы были успешно переданы. Когда я пытался ssh в мой EC2 в следующий раз я получил a Permission denied (publickey) со следующим журналом с ssh -v опция: (Я замаскировал частную информацию как IP с {} в журнале ниже),

OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/{localuser}/.ssh/config
debug1: /home/{localuser}/.ssh/config line 1: Applying options for aws-fr-
ec2
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to {aws.ec2.ip} [{aws.ec2.ip}] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/{localuser}/Documents/AWS-Files/EC2-FR.pem type 
-1
debug1: key_load_public: No such file or directory
debug1: identity file /home/{localuser}/Documents/AWS-Files/EC2-FR.pem-cert 
type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 
Ubuntu-4ubuntu2.2
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2 pat OpenSSH* compat 
0x04000000
debug1: Authenticating to {aws.ec2.ip}:22 as 'ubuntu'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: 
<implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: 
<implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 
SHA256:g3nWVGmjJYVrNrwsDJMhzbLSw0FzBOLoUx80seD9qIs
debug1: Host '{aws.ec2.ip}' is known and matches the ECDSA host key.
debug1: Found key in /home/{localhost}/.ssh/known_hosts:11
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/{localhost}/Documents/AWS-Files/EC2-
FR.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Я действительно натыкался на этот вопрос, но без справки. Я также нашел этот поток на Форуме AWS.

Я действительно выполнял перечисленные шаги:

Отправленный: mary@AWS:
Вы могли проверить полномочия на/home/ubuntu/.ssh каталоге и файлах, содержавшихся в нем на этом экземпляре?

Для проверки полномочий можно остановить экземпляр и отсоединиться, корневой объем (сделайте примечание устройства, к которому это присоединено). Затем присоедините объем к другому экземпляру на доступном устройстве. Создайте точку монтирования, такую как/fixroot, в случае необходимости и смонтируйте устройство к этой точке монтирования. После того, как смонтированный, CD к/fixroot/home/ec2-user и проверка каталог и полномочия файла. .ssh каталог должен позволить rwx для пользователя (владелец), и файлы должны быть читаемыми только пользователем.

Другая вещь проверить, в то время как Вы, состоит в том, что known_hosts файл не имеет дублирующихся записей для клиента, от которого Вы пытаетесь соединиться.

После того как Вы сделали это, можно размонтировать объем и отсоединить его от экземпляра. Затем присоедините его назад к исходному экземпляру к устройству, которое Вы отметили в первом шаге, и запустите экземпляр.

А также

Отправленный: yromanenko:
оказывается, что это были расслабленные полномочия на папке дома/человечности, а не ssh. Я смог зафиксировать его путем отсоединения корневого объема и фиксации полномочий. Следующее видео было очень полезно в руководстве меня через шаги:

http://d2930476l2fsmh.cloudfront.net/LostKeypairRecoveryOfLinuxInstance.mp4

Я породил новое t2.micro экземпляр и сопровождаемый Maryшаги для подтверждения полномочий и yromanenkoразрешение для установки 755 на /home/ubuntu каталог.

Я повторно прикрепил проблематичное устройство EBS назад к первому EC2 как /dev/sda1 и попробованный только для сбоя с тем же Permission denied (publickey) ошибка!!

Следовательно, теперь я получаю ту же ошибку на вторичном устройстве t2.micro экземпляр.:(

Любая справка ценилась бы!

1
задан 8 November 2017 в 19:16

1 ответ

У меня была точно такая же проблема. Я использовал инстанс Amazon EC2, чтобы запустить еще один и выявить различия. У сломанной машины были разрешения /home/user 777, у не сломанной машины было 700. По какой-то необъяснимой причине rsyncing to /home/user изменяет разрешения /home/user на 777. Очевидно, SSH требует, чтобы /home/user было 700 по соображениям безопасности. Это также объясняет, почему его черепахи полностью вниз, снова rsync и снова сломаны.

Если вам посчастливилось получить доступ к каталогу другим способом,

chmod 700 /home/user

исправляет это.

В будущем выполните rsync в подкаталог /home/user.

0
ответ дан 29 October 2020 в 02:21

Другие вопросы по тегам:

Похожие вопросы: