Como resolvo os erros de “Permissão negada (chave pública)” ou “Falha na autenticação, permissão negada” quando acesso minha instância do EC2?

Breve descrição

Os erros de Permissão negada (chave pública) e Falha na autenticação, permissão negada ocorrem pelos seguintes motivos:

• Você usa o nome de usuário errado para sua imagem de máquina da Amazon (AMI) ao se conectar.
• Você tem permissões de arquivo incorretas no sistema operacional (SO) da instância.
• O arquivo authorized_keys tem o arquivo de chave pública SSH (.pub) incorreto ou você iniciou sua instância sem uma chave.
• Seu arquivo authorized_keys autorizado ou pasta .ssh não estão nomeados corretamente.
• Seu arquivo authorized_keys ou pasta .ssh foram excluídos.
• (Somente Ubuntu 20.x) Você usa AuthorizedKeysCommand na sua configuração SSH.

Resolução

Verifique se você tem o nome de usuário correto para sua AMI

Certifique-se de usar um nome de usuário válido para sua AMI.

Verifique se as permissões de arquivo no sistema operacional estão corretas e se a chave pública SSH correta está no arquivo authorized_keys

Para verificar sua configuração, use um dos métodos a seguir.

Use o Console de Série do EC2

Se você ativou o Console de Série do EC2 par Linux, poderá usá-lo para solucionar problemas de tipos de instância baseados em Nitro compatíveis. O console de série se conecta à sua instância sem a necessidade de uma conexão de rede. É possível acessar o console de série por meio do console do Amazon EC2 ou da AWS Command Line Interface (AWS CLI).

Antes de usar o console de série, conceda acesso a ele no nível da conta da AWS. Em seguida, crie políticas do AWS Identity and Access Management (AWS IAM) que concedam acesso ao console aos seus usuários do IAM. Cada instância que usa o console de série deve incluir pelo menos um usuário baseado em senha. Para obter informações sobre como configurar o Console de Série do EC2 para Linux, consulte Configurar o acesso ao Console de Série do EC2.

Se sua instância estiver inacessível e você não tiver configurado o acesso ao console serial, use outro método para verificar sua configuração.

Observação: se você receber erros ao executar comandos da AWS CLI, consulte Solucionar erros da AWS CLI. Além disso, verifique se você está usando a versão mais recente da AWS CLI.

Use o Gerenciador de sessões do Systems Manager

Observação: para usar esse método, você deve instalar o SSM Agent. Para obter uma lista de pré-requisitos para usar o Systems Manager, consulte a Etapa 1: Cumpra os pré-requisitos do Gerenciador de sessões.

Use o Gerenciador de sessões do AWS Systems Manager para fazer login na instância e fazer correções. Siga estas etapas:

1. Abra o console do Systems Manager.

2. Inicie uma sessão.

3. Para verificar se as permissões dos arquivos no diretório home estão corretas, execute o comando ls-ld:

   ls -ld /home/ec2-user/

   Observação: substitua ec2-user pelo seu nome de usuário com base na sua instância de imagem de máquina da Amazon (AMI).
   Você recebe uma saída semelhante à seguinte:

   drwx------ 3 ec2-user ec2-user 4096 Apr  1 08:31 /home/ec2-user/

   O exemplo a seguir mostra uma lista das permissões corretas necessárias:
   Para o diretório inicial do Linux /home, use (0755/drwxr-xr-x).
   Para o diretório inicial do usuário /home/ec2-user/, use (0700/drwx------).
   Para a permissão do diretório .ssh /home/ec2-user/.ssh, use (0700/drwx------).
   Para a permissão de arquivo /home/ec2-user/.ssh/authorized_keys authorized_keys, use (0600/-rw-------).

4. No computador local, verifique se você usa uma chave pública SSH.

5. Se a assinatura da chave pública SSH não estiver presente na saída, atualize o arquivo authorized_keys para permitir sua chave SSH. Execute o seguinte comando:

   echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDVogCW5eZogRp+vF6Ut360b0bYyTmqgYaCXOyiW77I916AS5jFL3zsCtONbGn4hnG/UGGWXpLfUV85qpVJb38fskPZNuyZtjGjXM2W7qqbCZ1N9HBb6IPBaL97tmqBi+8rD7mSkoHc40sIV+KxkQSvD6AAFjQruCjxzfGIApnOvuj6IMsVEuFHBx4QhkbCzafxo02D9BZT4+dMy7tmyuC+UiNEQpgfFoszl+4VNFTIPlQQyn6CpUiV/rFXIadXsHqc+UOdVnfEXP+30YL75RHabze/1F5MY6t94AEcmcb05Dq4vwN9IjcxKmwgvxLOXzryytepvHQU+PobBEXAMPLE' >> /home/ec2-user/.ssh/authorized_keys

   Observação: substitua a chave de exemplo pela chave pública SSH.

6. Para corrigir as permissões, execute os seguintes comandos na sua instância do EC2:

   sudo chown root:root /home
   sudo chmod 755 /home
   sudo chown ec2-user:ec2-user /home/ec2-user -R
   sudo chmod 700 /home/ec2-user /home/ec2-user/.ssh
   sudo chmod 600 /home/ec2-user/.ssh/authorized_keys

7. Encerre a sessão.

8. Use SSH para se conectar à instância.

Execute o runbook de automação AWSSupport-TroubleshootSSH

Use o AWSSupport-TroubleshootSSH para verificar e corrigir problemas que causam erros de conexão remota com uma máquina Linux por meio de SSH. Para obter mais informações, consulte Estou recebendo erros ao tentar me conectar à minha instância do EC2 usando SSH. Como posso usar o fluxo de trabalho de automação AWSSupport-TroubleshootSSH para solucionar problemas de conexão SSH?

Use um script de dados do usuário para reparar permissões do SSH e adicione a chave pública SSH correta ao arquivo authorized_keys

Importante: para usar esse método, você precisa interromper a instância. Quando você interrompe a instância, ocorrem os seguintes efeitos:

• Se sua instância for apoiada por um armazenamento de instâncias do Amazon Elastic Block Storage (Amazon EBS) ou tiver volumes de armazenamento de instâncias com dados, os dados serão perdidos.
• Se sua instância fizer parte de um grupo do Amazon EC2 Auto Scaling, a Amazon EC2 Auto Scaling poderá encerrar a instância. As instâncias executadas com o Amazon EMR, o AWS CloudFormation ou o AWS Elastic Beanstalk podem fazer parte de um grupo do Auto Scaling. O encerramento da instância nesse caso depende das configurações de proteção contra redução de escala horizontal da instância para seu grupo do Auto Scaling. Se sua instância fizer parte de um grupo do Auto Scaling, remova temporariamente a instância do grupo do Auto Scaling antes de realizar as seguintes etapas.
• O endereço IP público da instância muda. Ao rotear tráfego externo para sua instância, é prática recomendada usar um endereço IP elástico em vez de um endereço IP público.

Para reparar suas permissões de SSH, siga estas etapas:

1. Abra o console do Amazon EC2.

2. Escolha Instâncias no painel de navegação e selecione a instância à qual você deseja executar.

3. Interrompa a instância.

4. Escolha Ações e, em seguida, escolha Configurações da instância.

5. Escolha Editar dados do usuário.

6. Em Editar dados do usuário, insira o seguinte script de dados do usuário:

   Content-Type: multipart/mixed; boundary="//"
   MIME-Version: 1.0
   
   --//
   Content-Type: text/cloud-config; charset="us-ascii"
   MIME-Version: 1.0
   Content-Transfer-Encoding: 7bit
   Content-Disposition: attachment; filename="cloud-config.txt"
   
   #cloud-config
   cloud_final_modules:
   - [scripts-user, always]
   
   --//
   Content-Type:
       text/x-shellscript; charset="us-ascii"
   MIME-Version: 1.0
   Content-Transfer-Encoding: 7bit
   Content-Disposition: attachment; filename="userdata.txt"
   
   #!/bin/bash
   OS_USER=os-user
   chown root:root /home
   chmod 755 /home
   chown $OS_USER:$OS_USER /home/$OS_USER -R
   chmod 700 /home/$OS_USER
   chmod 700 /home/$OS_USER/.ssh
   chmod 600 /home/$OS_USER/.ssh/authorized_keys
   --//

   Observação: substitua os-user pelo nome de usuário associado à AMI que você usou para executar sua instância.

7. Escolha Salvar.

8. No computador local, verifique se você usa uma chave pública SSH.

9. Se a assinatura da chave pública SSH não estiver na saída, adicione a chave ao script de dados do usuário. Se a assinatura corresponder, prossiga para a próxima etapa.

   Exemplo de script de dados do usuário com uma chave pública SSH:

   Content-Type: multipart/mixed; boundary="//"
   MIME-Version: 1.0
   
   --//
   Content-Type: text/cloud-config; charset="us-ascii"
   MIME-Version: 1.0
   Content-Transfer-Encoding: 7bit
   Content-Disposition: attachment; filename="cloud-config.txt"
   
   #cloud-config
   cloud_final_modules:
   - [scripts-user, always]
   
   --//
   Content-Type:
       text/x-shellscript; charset="us-ascii"
   MIME-Version: 1.0
   Content-Transfer-Encoding: 7bit
   Content-Disposition: attachment; filename="userdata.txt"
   
   #!/bin/bash
   OS_USER=os-user
   chown root:root /home
   chmod 755 /home
   chmod 700 /home/$OS_USER
   chmod 700 /home/$OS_USER/.ssh
   chmod 600 /home/$OS_USER/.ssh/authorized_keys
   echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDVogCW5eZogRp+vF6Ut360b0bYyTmqgYaCXOyiW77I916AS5jFL3zsCtONbGn4hnG/UGGWXpLfUV85qpVJb38fskPZNuyZtjGjXM2W7qqbCZ1N9HBb6IPBaL97tmqBi+8rD7mSkoHc40sIV+KxkQSvD6AAFjQruCjxzfGIApnOvuj6IMsVEuFHBx4QhkbCzafxo02D9BZT4+dMy7tmyuC+UiNEQpgfFoszl+4VNFTIPlQQyn6CpUiV/rFXIadXsHqc+UOdVnfEXP+30YL75RHabze/1F5MY6t94AEcmcb05Dq4vwN9IjcxKmwgvxLOXzryytepvHQU+PobBEXAMPLE' >> /home/$OS_USER/.ssh/authorized_keys
   chown $OS_USER:$OS_USER /home/$OS_USER -R
   --//

10. Inicie sua instância.

Observação: o script de dados do usuário anterior é definido para ser executado a cada reinicialização da instância. Depois de recuperar o acesso à sua instância, remova o script de dados do usuário.

(Somente Ubuntu 20.x) Verifique o AuthorizedKeysCommand para a configuração SSH

No Ubuntu 20.x, o EC2 Instance Connect é instalado por padrão. Quando você define as configurações do AuthorizedKeysCommand e AuthorizedKeysCommandUser para autenticação SSH, a instalação do EC2 Instance Connect não atualiza essas configurações. Como resultado, não é possível usar o EC2 Instance Connect. Para resolver esse problema, remova AuthorizedKeysCommand e AuthorizedKeysCommandUser da sua configuração SSH.

Informações relacionadas

Como posso solucionar problemas de conexão com minha instância Linux do Amazon EC2 usando SSH?

Perdi minha chave privada. Como posso me conectar à instância?

Como faço para me conectar à minha instância do Amazon EC2 se eu perder meu par de chaves SSH após a execução da instância?