Solution 1 :
J'espère que vous utilisez un volume racine EBS. Si c'est le cas, la solution n'est pas trop difficile.
Essentiellement, vous attachez le volume EBS à une autre instance, apportez les modifications et rattachez-le à l'instance d'origine :
- Arrêtez (ne résiliez pas) l'instance d'origine
- Détacher le volume EBS
- Lancer une autre instance
- Associez votre volume EBS actuel à la nouvelle instance
- SSH dans la nouvelle instance, montez le volume EBS et apportez les modifications nécessaires
- Démontez le volume EBS (par exemple,
umount -d /dev/xvdhouumount -d /dev/sdh) - Détachez le volume EBS de la nouvelle instance et attachez-le en tant que volume racine (par exemple,
/dev/sda1) de l'ancienne instance - Démarrer l'ancienne instance
- Si tout fonctionne, mettez fin à la nouvelle instance
La raison pour laquelle cela fonctionne, c'est que sur la nouvelle instance fraîche, vous disposez des autorisations appropriées - son volume racine est intact - ce qui fait du fichier sudoers de votre instance d'origine un autre fichier que vous pouvez modifier.
Si vous avez un volume racine de stockage d'instance, malheureusement, vous ne pourrez probablement pas résoudre le problème et devrez revenir à une AMI que vous avez créée précédemment en tant que sauvegarde.
Solution 2 :
Cela dépend s'il s'agit d'un périphérique racine AMI ou EBS.
S'il s'agit d'une AMI et que vous n'avez pas le mot de passe root, et que l'AMI ne configure pas l'accès SSH root, vous ne pouvez rien faire.
S'il s'agit d'une racine EBS, vous pouvez la résilier et attacher le volume à une autre instance (en tant que disque supplémentaire, pas la racine). Vous pouvez alors soit accéder aux données, soit corriger le fichier sudoers et lancer une nouvelle instance en utilisant le volume.