☰

AWS - Заблокирован доступ к EC2 после rsync-синхронизации каталога /home/ubuntu

tag-icon • tag-icon permissions ssh rsync amazon-ec2
AWS - Заблокирован доступ к EC2 после rsync-синхронизации каталога /home/ubuntu

TL;DR
Я rsyncскопировал несколько каталогов из /home/ubuntu(set to 777) одного удаленного сервера в свой новый экземпляр AWS EC2. Теперь я заблокирован из ssh-за ошибки 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 в следующий раз, я получил 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: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: 
<implicit> compression: none
debug1: kex: client->server cipher: [email protected] 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, если необходимо, и смонтируйте устройство в эту точку монтирования. После монтирования перейдите в /fixroot/home/ec2-user и проверьте разрешения на каталог и файлы. Каталог .ssh должен разрешать rwx для пользователя (владельца), а файлы должны быть доступны для чтения только пользователю.

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

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

А также

Разместил: yromanenko:
оказалось, что проблема была в ослабленных разрешениях на папку home/ubuntu, а не в ssh. Мне удалось исправить это, отсоединив корневой том и исправив разрешения. Следующее видео было очень полезным, проведя меня по шагам:

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

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

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

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

Любая помощь будет оценена по достоинству!

решение1

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

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

chmod 700 /home/user

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

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

Связанный контент