Perdeu sudo / su na instância do Amazon EC2

Question

Eu tenho uma instância do Amazon EC2. Eu posso logar muito bem, mas nem "su" nem "sudo" funciona agora (eles funcionavam bem anteriormente):

• "su" solicita uma senha, mas eu faço login usando chaves ssh e não acho que o usuário root ainda tem uma senha.

• "sudo <anything> " faz isso:

sudo: /etc/sudoers is owned by uid 222, should be 0 
sudo: no valid sudoers sources found, quitting 

Eu provavelmente fiz "chown ec2-user / etc / sudoers" (ou, mais provavelmente, "chown" -R ec2-user / etc "porque eu estava cansado de rsync falhar), então este é o meu culpa.

Como eu me recupero? Eu parei a instância e tentei o "View / Change User Data "no console do AWS EC2, mas isso não ajudou.

EDIT: Eu percebo que eu poderia matar essa instância e criar uma nova, mas estava esperando evitar algo tão extremo.

    

Answer 1

Nesse tipo de situação, acho que você deve poder usar uma segunda instância para corrigir o problema:

• Desanexe o disco do EBS que contém o sistema quebrado
• Crie outra instância do EC2
• Anexar & monte o disco para a nova instância
• Corrigir as permissões
• Umount, retire & reconecte-se à instância original

Answer 2

1. Pare sua instância atual
2. Desanexar o volume existente
3. Crie um novo volume
4. Anexar novo volume à sua instância como "/ dev / xvda"
5. Inicie sua instância
6. Anexe o volume antigo (que tem um problema de privilégio sudo) de volta à instância enquanto ele está sendo executado como "/ dev / sdf"
7. Faça login na sua instância usando o putty

8. Use o comando lsblk para visualizar seus dispositivos de disco disponíveis e seus pontos de montagem (se aplicável) para ajudá-lo a determinar o nome correto do dispositivo a ser usado.

     ec2-user ~$ lsblk
     NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
     xvdf 202:80 0 100G 0 disk
     xvda1 202:1 0 8G 0 disk /
   

A saída de lsblk remove o prefixo / dev / dos caminhos completos do dispositivo. Neste exemplo, /dev/xvda1 é montado como o dispositivo raiz (observe que MOUNTPOINT está listado como /, a raiz da hierarquia do sistema de arquivos Linux) e /dev/xvdf está anexado, mas ainda não foi montado.

9. Use o seguinte comando para criar um diretório de ponto de montagem para o volume. O ponto de montagem é onde o volume está localizado na árvore do sistema de arquivos e onde você lê e grava arquivos depois de montar o volume. Substitua um local por mount_point, como / data.

   sudo su
   cd /mnt
   mkdir other
   mount /dev/xvdf other
   cd /
   chown -R root:root /mnt/other/etc/
   exit
   

10. Volte para a AWS e pare a instância

11. Desconecte os volumes e reconecte o volume antigo (agora fixo) como / dev / xvda
12. Inicie sua instância e agora suas permissões devem voltar ao que era

Answer 3

Eu estava tendo o mesmo problema e, por ser tão difícil, fiz um vídeo para explicar a solução. Isso é praticamente a mesma coisa que a solução da Rekee na forma de um tutorial em vídeo.

link

Espero que ajude. :)

    

Answer 4

Parece que você respondeu a si mesmo ...

I probably did "chown ec2-user /etc/sudoers" (or, more likely "chown -R ec2-user /etc" because I was sick of rsync failing), so this is my fault.

De qualquer maneira, eu não acho que você possa resolver isso sem ganhar um shell de root. (Não tenho certeza de que métodos de recuperação são possíveis em ec2?)

Se você de fato recursivamente chown / etc, então eu acho que reconstruir o servidor é o melhor caminho a percorrer.