TL; DR
Яrsync
редактор несколько каталогов от/home/ubuntu
(набор к777
) из одного удаленного сервера к моему новому экземпляру AWS EC2. Я теперь заблокирован изssh
луг в него aPermission 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
экземпляр.:(
Любая справка ценилась бы!
У меня была точно такая же проблема. Я использовал инстанс 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.