Você não pode aplicar um par de chaves a uma instância em execução. Você só pode usar o novo par de chaves para iniciar uma nova instância.
Para recuperação, se for uma AMI de inicialização do EBS, você pode interrompê-lo e fazer uma captura instantânea do volume. Crie um novo volume com base nele. E use-o novamente para iniciar a instância antiga, criar uma nova imagem ou recuperar dados.
Embora os dados no armazenamento efêmero sejam perdidos.
Devido à popularidade desta pergunta e resposta, eu queria capturar as informações no link que Rodney postou em seu comentário.
Crédito para Eric Hammond por esta informação .
Corrigindo arquivos no volume EBS raiz de uma instância do EC2
Você pode examinar e editar arquivos no volume raiz do EBS em uma instância do EC2, mesmo se estiver em uma situação desastrosa como:
- Você perdeu sua chave ssh ou esqueceu sua senha
- Você cometeu um erro ao editar o arquivo / etc / sudoers e não pode mais obter acesso root com o sudo para corrigi-lo
- Sua instância de longa execução está travada por algum motivo, não pode ser contatada e falha ao inicializar corretamente
- Você precisa recuperar arquivos da instância, mas não pode acessá-la
Em um computador físico à sua mesa, você pode simplesmente inicializar o sistema com um CD ou pendrive, montar o disco rígido, fazer o check-out e corrigir os arquivos e, em seguida, reiniciar o computador para voltar aos negócios.
Uma instância remota do EC2, no entanto, parece distante e inacessível quando você está em uma dessas situações. Felizmente, a AWS nos fornece o poder e a flexibilidade para recuperar um sistema como esse, desde que executemos instâncias de inicialização do EBS e não armazenemos a instância.
A abordagem no EC2 é um pouco semelhante à solução física, mas vamos mover e montar o “disco rígido” defeituoso (volume EBS raiz) em uma instância diferente, corrigi-lo e movê-lo de volta.
Em algumas situações, pode ser mais fácil simplesmente iniciar uma nova instância do EC2 e jogar fora a ruim, mas se você realmente deseja corrigir seus arquivos, aqui está a abordagem que funcionou para muitos:
Configuração
Identifique a instância original (A) e o volume que contém o volume EBS raiz quebrado com os arquivos que você deseja exibir e editar.
instance_a=i-XXXXXXXX
volume=$(ec2-describe-instances $instance_a |
egrep '^BLOCKDEVICE./dev/sda1' | cut -f3)
Identifique a segunda instância do EC2 (B) que você usará para corrigir os arquivos no volume EBS original. Esta instância deve estar em execução na mesma zona de disponibilidade da instância A para que possa ter o volume EBS anexado a ela. Se você ainda não possui uma instância em execução, inicie uma temporária.
instance_b=i-YYYYYYYY
Interrompa a instância quebrada A (aguardando a parada completa), desanexe o volume EBS raiz da instância (aguardando a desanexação) e, em seguida, conecte o volume à instância B em um dispositivo não utilizado.
ec2-stop-instances $instance_a
ec2-detach-volume $volume
ec2-attach-volume --instance $instance_b --device /dev/sdj $volume
ssh na instância B e monte o volume para que você possa acessar seu sistema de arquivos.
ssh ...instance b...
sudo mkdir -p 000 /vol-a
sudo mount /dev/sdj /vol-a
Consertá-lo
Nesse ponto, todo o seu sistema de arquivos raiz da instância A está disponível para visualização e edição em / vol-a na instância B. Por exemplo, você pode:
- Coloque as chaves ssh corretas em /vol-a/home/ubuntu/.ssh/authorized_keys
- Edite e corrija / vol-a / etc / sudoers
- Procure mensagens de erro em / vol-a / var / log / syslog
- Copie arquivos importantes de / vol-a /…
Nota: Os uids nas duas instâncias podem não ser idênticos; portanto, tenha cuidado se estiver criando, editando ou copiando arquivos que pertencem a usuários não raiz. Por exemplo, seu usuário mysql na instância A pode ter o mesmo UID que o usuário postfix na instância B, o que pode causar problemas se você exibir arquivos com um nome e depois mover o volume de volta para A.
Embrulhar
Depois de terminar e ficar satisfeito com os arquivos em / vol-a, desmonte o sistema de arquivos (ainda na instância-B):
sudo umount /vol-a
sudo rmdir /vol-a
Agora, de volta ao seu sistema com ec2-api-tools, continue movendo o volume EBS de volta para o seu país na instância original A e inicie a instância novamente:
ec2-detach-volume $volume
ec2-attach-volume --instance $instance_a --device /dev/sda1 $volume
ec2-start-instances $instance_a
Felizmente, você resolveu o problema, a instância A aparece perfeitamente e você pode realizar o que originalmente se propôs a fazer. Caso contrário, talvez seja necessário continuar repetindo essas etapas até que funcione.
Nota: Se você tiver um endereço IP Elastic atribuído à instância A quando o interrompeu, precisará reassociá-lo depois de iniciá-lo novamente.
Lembrar! Se sua instância B foi temporariamente iniciada apenas para esse processo, não se esqueça de encerrá-la agora.
ssh-add
deve fazer o que você precisa.