TL;DR あるリモート サーバーの(に設定)からいくつかのディレクトリを新しい AWS EC2 インスタンスに移動しました。エラーにより、そのインスタンスにアクセスできなくなり
ました。rsync/home/ubuntu777sshPermission denied (publickey)
実稼働環境を SoftLayer から AWS に移行中です。
EC2 (EBS) にいくつかのディレクトリが必要で、その過程で、古い EC2 インスタンスから現在の EC2 インスタンスにrsyncいくつかのディレクトリを転送しました。/home/ubuntu//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 に cd して、ディレクトリとファイルの権限を確認します。.ssh ディレクトリはユーザー (所有者) の rwx を許可し、ファイルはユーザーのみが読み取り可能である必要があります。
その際に確認する必要があるもう 1 つのことは、known_hosts ファイルに、接続しようとしているクライアントの重複エントリがないことです。
これが完了したら、ボリュームをアンマウントしてインスタンスからデタッチできます。次に、最初の手順でメモしたデバイスに元のインスタンスにアタッチし直し、インスタンスを起動します。
同様に
投稿者: yromanenko:
結局、問題は ssh ではなく、home/ubuntu フォルダの権限が緩いことでした。ルート ボリュームをデタッチして権限を修正することで、この問題を解決できました。次のビデオは、手順を説明するのに非常に役立ちました。
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 でした。どういうわけか、/home/user に rsync すると、/home/user の権限が 777 に変更されます。どうやら SSH では、セキュリティ上の理由から /home/user が 700 である必要があるようです。これが、ずっと下まで行き、再び rsync すると再び壊れる理由でもあります。
幸運にも他の方法でディレクトリにアクセスできる場合は、
chmod 700 /home/user
それを修正します。
今後は、/home/user のサブディレクトリに rsync します。