Vous avez corrompu la configuration SSH ? Pas de panique, il y a une solution !
Le principe est de monter le volume EBS sur une autre instance, pour recréer le dossier .ssh/ de ec2-user correct.
– Créer une instance (même une nano), dans la même AZ (Availability Zone) et le même subnet que celle à secourir. Utiliser la paire de clé que vous voulez mettre.
– Arrêter l’instance à secourir.
– Détacher son volume
– Attacher ce volume à la nouvelle instance. On peut laisser le device par défaut (/dev/sdf)
– Monter ce volume sur la nouvelle instance, en se connectant dessus via SSH :
# en tant que root sudo -i # on crée le point de montage mkdir /mnt/recovery #on monte le volume mount /dev/sdf1 /mnt/recovery # on restaure la configuration SSH de l'utilisateur ec2-user # (les chemins ne sont valables que pour l'AMI standard d'Amazon Linux) cp /home/ec2-user/.ssh/authorized_keys > /mnt/recovery/home/ec2-user/.ssh/authorized_keys chown ec2-user:ec2-user /mnt/recovery/home/ec2-user/.ssh/authorized_keys chmod 600 /mnt/recovery/home/ec2-user/.ssh/authorized_keys #on peut démonter le volume umount /mnt/recovery/
– Détacher le volume
– Le rattacher à l’instance à secourir. Mettre /dev/xvda pour qu’elle soit bien remontée en Root device. Pour être sûr, regarder la valeur utilisée pour l’instance de secours.
– Démarrer l’instance secourue, vous devriez désormais pouvoir vous y connecter !
– Vous pouvez arrêter l’instance de secours, via un Terminate (suppression totale)
Ouf !
Salut,
Article très intéressant mais petite coquille à cet endroit
chown ec2-user.ec2-user >> chown ec2-user:ec2-user
le . est une ancienne RFC encore admise mais qui peut poser soucis au niveau du noyau…selon le user:groupe tu peux rencontrer des pépins.
Effectivement, merci pour la remarque… et pour le coup de vieux 😉