AWS - Aus EC2 ausgesperrt nach rsync'ed des Verzeichnisses /home/ubuntu

Question

TL;DR
Ich rsynchabe ein paar Verzeichnisse von einem Remote-Server /home/ubuntu(eingestellt auf 777) an meine neue AWS EC2-Instanz gesendet. Aufgrund eines Fehlers kann ich mich jetzt nicht mehr sshdarauf zugreifen Permission denied (publickey).

Ich bin gerade dabei, meine Produktionsumgebung von SoftLayer zu AWS zu migrieren.

Ich musste rsyncmehrere Verzeichnisse zu EC2 (EBS) übertragen und habe dabei einige Verzeichnisse von der alten /home/ubuntu/auf meine aktuelle EC2-Instanz übertragen /home/ubuntu/.

Mein rsyncBefehl (zum Ziel) sah so aus.

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/

Die Dateien wurden erfolgreich übertragen. Als ich das nächste Mal versuchte, mich sshin mein EC2 einzuloggen, erhielt ich ein Permission denied (publickey)Protokoll mit folgender ssh -vOption: (Ich habe private Informationen wie die IP-Adresse im Protokoll unten mit {} maskiert)

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).

Ich bin gestolpert überDasFrage, aber ohne Hilfe. Ich fand auchDasThread im AWS-Forum.

Ich habe die aufgeführten Schritte befolgt:

Gepostet von: mary@AWS:
Könnten Sie bitte die Berechtigungen für das Verzeichnis /home/ubuntu/.ssh und die darin enthaltenen Dateien auf dieser Instanz überprüfen?

Um die Berechtigungen zu überprüfen, können Sie die Instanz stoppen und das Stammvolume trennen (notieren Sie sich das Gerät, an das es angeschlossen ist). Verbinden Sie das Volume dann mit einer anderen Instanz auf einem verfügbaren Gerät. Erstellen Sie bei Bedarf einen Einhängepunkt, z. B. /fixroot, und hängen Sie das Gerät an diesen Einhängepunkt an. Wechseln Sie nach dem Einhängen zu /fixroot/home/ec2-user und überprüfen Sie die Verzeichnis- und Dateiberechtigungen. Das .ssh-Verzeichnis sollte rwx für den Benutzer (Eigentümer) zulassen und die Dateien sollten nur vom Benutzer gelesen werden können.

Außerdem sollten Sie überprüfen, ob die Datei known_hosts keine doppelten Einträge für den Client enthält, von dem aus Sie eine Verbindung herstellen möchten.

Sobald Sie dies getan haben, können Sie das Volume aushängen und von der Instanz trennen. Verbinden Sie es dann wieder mit der ursprünglichen Instanz mit dem Gerät, das Sie im ersten Schritt notiert haben, und starten Sie die Instanz.

Sowie

Gepostet von: yromanenko:
Es stellte sich heraus, dass es an den gelockerten Berechtigungen für den Home/Ubuntu-Ordner lag und nicht an SSH. Ich konnte es beheben, indem ich das Stammvolume abtrennte und die Berechtigungen korrigierte. Das folgende Video war sehr hilfreich und führte mich durch die Schritte:

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

Ich habe eine neue t2.microInstanz erstellt und Marydie Schritte von befolgt, um die Berechtigungen und yromanenkodie 755für das /home/ubuntuVerzeichnis festzulegende Auflösung zu bestätigen.

Ich habe das problematische EBS-Gerät wieder an die erste EC2 angeschlossen /dev/sda1und es erneut versucht, aber derselbe Permission denied (publickey)Fehler ist aufgetreten!!

Folglich erhalte ich jetzt denselben Fehler auf der sekundären t2.microInstanz. :(

Jede Hilfe wäre willkommen!

Answer 1

Ich hatte genau dieses Problem. Ich habe eine Amazon EC2-Instanz verwendet, damit ich eine andere hochfahren und die Unterschiede identifizieren konnte. Die defekte Maschine hatte die /home/user-Berechtigungen 777, die nicht defekte Maschine hatte 700. Aus unerklärlichen Gründen ändert rsyncing mit /home/user die Berechtigungen von /home/user auf 777. Anscheinend erfordert SSH aus Sicherheitsgründen /home/user auf 700. Dies erklärt auch, warum es ganz nach unten geht, rsync erneut und es ist wieder kaputt.

Wenn Sie das Glück haben, auf andere Weise Zugriff auf das Verzeichnis zu haben,

chmod 700 /home/user

behebt das Problem.

Führen Sie in Zukunft eine rsync-Synchronisierung in ein Unterverzeichnis von /home/user durch.