AWS Impossible de se connecter avec SSH

Question

Après la modification du propriétaire du dossier .ssh de l'utilisateur à la racine, je ne peux pas me connecter au serveur distant avec ssh. Voici le message d'erreur:

OpenSSH_6.9p1, LibreSSL 2.1.7 
debug1: Reading configuration data /Users/qj/.ssh/config 
debug1: Reading configuration data /etc/ssh/ssh_config 
debug1: /etc/ssh/ssh_config line 20: Applying options for * 
debug1: Connecting to ec2-52-193-83-231.ap-northeast-1.compute.amazonaws.com [52.193.83.231] port 22. 
debug1: Connection established. 
debug1: key_load_public: No such file or directory 
debug1: identity file gmail.pem type -1 
debug1: key_load_public: No such file or directory 
debug1: identity file gmail.pem-cert type -1 
debug1: Enabling compatibility mode for protocol 2.0 
debug1: Local version string SSH-2.0-OpenSSH_6.9 
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000 
debug1: Authenticating to ec2-52-193-83-231.ap-northeast-1.compute.amazonaws.com:22 as 'ec2-user' 
debug1: SSH2_MSG_KEXINIT sent 
debug1: SSH2_MSG_KEXINIT received 
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none 
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none 
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY 
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:EahONyMKzM6Q4tdEBSa9LwyOFI65KB02GesJGuGE9Ss 
debug1: Host 'ec2-52-193-83-231.ap-northeast-1.compute.amazonaws.com' is known and matches the ECDSA host key. 
debug1: Found key in /Users/qj/.ssh/known_hosts:25 
debug1: SSH2_MSG_NEWKEYS sent 
debug1: expecting SSH2_MSG_NEWKEYS 
debug1: SSH2_MSG_NEWKEYS received 
debug1: Roaming not allowed by server 
debug1: SSH2_MSG_SERVICE_REQUEST sent 
debug1: SSH2_MSG_SERVICE_ACCEPT received 
debug1: Authentications that can continue: publickey 
debug1: Next authentication method: publickey 
debug1: Offering RSA public key: /Users/qj/.ssh/dqj 
debug1: Authentications that can continue: publickey 
debug1: Trying private key: gmail.pem 
debug1: Authentications that can continue: publickey 
debug1: No more authentication methods to try. 
Permission denied (publickey). 

C'est vraiment ma faute de changer le propriétaire du dossier .ssh. Toute personne m'aide ~

Answer 1

Si vous avez vraiment besoin de conserver le serveur, vous pouvez essayer de créer une AMI à partir de la machine. Puis relancer de cela. AWS tentera alors de mettre à nouveau votre clé publique dans authorized_keys, et pourrait bien résoudre le problème d'autorisations en le faisant. Si ce n'est pas le cas, vous pouvez toujours lancer un nouveau serveur et attacher le volume EBS des serveurs rompus au nouveau serveur pour corriger les autorisations sur le dossier. Si vous avez un système de stockage éphémère ou un système de fichiers bizarre, vous n'êtes pas prêt à travailler.

Answer 2

Je trouve la réponse de https://forums.aws.amazon.com/thread.jspa?threadID=133054&tstart=0 Voici la réponse:

1. Arrêtez l'instance
2. Détacher le volume racine
3. Lancer une autre instance (ou si vous en avez un, vous pouvez déjà sauter cette étape)
4. Ci-joint le volume 2 du nouveau (ou déjà existant autre) par exemple
5. Connexion dans l'instance
6. Montez le volume
7. Modifiez les autorisations de dossier, selon le cas
8. Umount du volume et détachez
9. Attachez-retour à l'instace d'origine
10. Démarrez l'instance et connectez

Il se produit une problèmes à l'étape 6 lors du montage du volume à la nouvelle instance en utilisant le shell mount xvdf /ebs/ -t ext4 (mkdir/ebs// ce dossier est un point de montage, plus de détails de Making an Amazon EBS Volume Available for Use). Le message d'erreur est:

mount: wrong fs type, bad option, bad superblock on /dev/xvdf, 
     missing codepage or helper program, or other error 

     In some cases useful info is found in syslog - try 
     dmesg | tail or so. 

Étant donné que le système de fichiers pour le volume est GPT. Heureusement, j'ai eu la raison de ce poste Problem mounting GPT disk partition. Et la solution est que j'ai besoin de monter /dev/xvdf1, pas seulement /dev/xvdf, comme mount xvdf1 /ebs/ -t ext4. Enfin, le montage du volume est réussi.