Solução de problemas de SSH

Neste documento, descrevemos erros comuns que você pode encontrar ao se conectar a instâncias de máquina virtual (VM) do Linux usando SSH, maneiras de resolver erros e métodos para diagnosticar conexões SSH com falha.

Erros comuns de SSH

Veja a seguir exemplos de erros comuns que podem ser encontrados ao usar o SSH para se conectar a VMs do Compute Engine.

Permissão recusada

O seguinte erro pode ocorrer quando você se conectar à VM:

USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).

Esse erro pode ocorrer por vários motivos. Estas são algumas das causas mais comuns desse erro:

  • Você usou uma chave SSH armazenada nos metadados para se conectar a uma VM que tem o login do SO ativado. Se o Login do SO estiver ativado no projeto, a VM não aceitará chaves SSH armazenadas nos metadados.

    Para resolver esse problema, tente uma das seguintes opções:

  • Você usou uma chave SSH armazenada em um perfil de login do SO para se conectar a uma VM que não tem o login do SO ativado. Se você desativar o login do SO, sua VM não aceitará chaves SSH armazenadas no perfil de login do SO.

    Para resolver esse problema, tente uma das seguintes opções:

  • Sua chave expirou e o Compute Engine excluiu o arquivo ~/.ssh/authorized_keys. Se você tiver adicionado manualmente as chaves SSH à VM e conectado a ela usando o Console do Google Cloud, o Compute Engine criará um novo par de chaves para sua conexão. Depois que o novo par de chaves expirar, o Compute Engine excluirá o arquivo ~/.ssh/authorized_keys na VM, que incluiu a chave SSH adicionada manualmente.

    Para resolver esse problema, tente uma das seguintes opções:

  • Você se conectou usando uma ferramenta de terceiros, e seu comando SSH está mal configurado. Se você se conectar usando o comando ssh, mas não especificar um caminho para a chave privada ou se especificar um caminho incorreto para a chave privada, a VM recusará a conexão.

    Para resolver esse problema, tente uma das seguintes opções:

    • Execute este comando:
      ssh -i PATH_TO_PRIVATE_KEY USERNAME@EXTERNAL_IP

      Substitua:
    • Conecte-se à VM usando o Console do Google Cloud ou a ferramenta de linha de comando gcloud. Quando você usa essas ferramentas para se conectar, o Compute Engine gerencia a criação da chave para você. Para mais informações, consulte Como se conectar a VMs.

  • O daemon sshd não está em execução ou não está configurado corretamente. O daemon sshd ativa conexões SSH. Se ela estiver configurada incorretamente ou não estiver em execução, não será possível se conectar à sua VM.

    Para resolver esse problema, consulte o guia do usuário do seu sistema operacional para garantir que seu sshd_config esteja configurado corretamente.

Falha na conexão

Os seguintes erros podem ocorrer quando você se conecta à sua VM pelo Console do Google Cloud ou pela ferramenta gcloud:

  • O Console do Cloud:

    Connection Failed

We are unable to connect to the VM on port 22.

  • A ferramenta gcloud:

    ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].

Esses erros podem ocorrer por vários motivos. Veja a seguir algumas das causas mais comuns dos erros:

  • A VM está inicializando e sshd ainda não está em execução. Não é possível se conectar a uma VM antes da execução.

    Para resolver esse problema, aguarde a conclusão da inicialização da VM e tente se conectar novamente.

  • A regra de firewall que permite SSH não foi configurada ou está configurada incorretamente. Por padrão, as VMs do Compute Engine permitem acesso SSH na porta 22. Se a regra default-allow-ssh estiver ausente ou configurada incorretamente, não será possível se conectar a VMs.

    Para resolver esse problema, verifique suas regras de firewall e adicione ou reconfigure default-allow-ssh.

  • sshd está sendo executado em uma porta personalizada. Se você configurou sshd para ser executado em uma porta diferente da porta 22, não poderá se conectar à sua VM.

    Para resolver esse problema, crie uma regra de firewall personalizada que permita o tráfego tcp na porta em que o sshd está sendo executado usando o seguinte comando:

    gcloud compute firewall-rules create FIREWALL_NAME \
  --allow tcp:PORT_NUMBER

    Para mais informações sobre como criar regras de firewall personalizadas, consulte Como criar regras de firewall.

  • Sua regra de firewall SSH personalizada não permite o tráfego dos serviços do Google. As conexões SSH do Console do Cloud serão recusadas se as regras de firewall personalizadas não permitirem conexões a partir do intervalo de endereços IP do Google.

    Para resolver esse problema, faça o seguinte:

    1. Reúna os intervalos de endereços IP do Google executando o seguinte comando:

      dig +qr +short txt `dig +short TXT _spf.google.com | grep -oE 'include:\S*' | cut -d':' -f2 | xargs` | grep -oE 'ip[46]:\S*' | sort | uniq

    2. Atualize sua regra de firewall personalizada para permitir o tráfego de endereços IP do Google. Para mais informações, consulte Como atualizar regras de firewall.

  • O daemon sshd não está em execução ou não está configurado corretamente. O daemon sshd ativa conexões SSH. Se ela estiver configurada incorretamente ou não estiver em execução, não será possível se conectar à sua VM.

    Para resolver esse problema, consulte o guia do usuário do seu sistema operacional para garantir que seu sshd_config esteja configurado corretamente.

Falha ao conectar ao back-end

Os seguintes erros podem ocorrer quando você se conecta à sua VM pelo Console do Google Cloud ou pela ferramenta gcloud:

  • O Console do Cloud:

    -- Connection via Cloud Identity-Aware Proxy Failed

-- Code: 4003

-- Reason: failed to connect to backend

  • A ferramenta gcloud:

    ERROR: (gcloud.compute.start-iap-tunnel) Error while connecting [4003: u'failed to connect to backend'].

Esses erros ocorrem quando você tenta usar o SSH para se conectar a uma VM que não tem um endereço IP público e não configurou o Identity-Aware Proxy na porta 22.

Para resolver esse problema, crie uma regra de firewall na porta 22 que permita o tráfego de entrada do Identity-Aware Proxy.

Como diagnosticar conexões SSH com falha

Nas seções a seguir, veja as etapas para diagnosticar a causa das conexões SSH com falha e as etapas para corrigir as conexões.

Antes de diagnosticar conexões SSH com falha, conclua as seguintes etapas:

Testar a conectividade

Talvez não seja possível executar o SSH em uma instância de VM devido a problemas de conectividade vinculados a firewalls, conexão de rede ou conta de usuário. Siga as etapas nesta seção para identificar problemas de conectividade.

Verificar as regras de firewall

O Compute Engine provisiona a cada projeto um conjunto padrão de regras de firewall que permitem o tráfego SSH. Se não for possível acessar a instância, use a ferramenta de linha de comando gcloud compute para verificar a lista de firewalls e garantir a presença da regra default-allow-ssh.

Na estação de trabalho local, execute o comando a seguir:

gcloud compute firewall-rules list

Se você não encontrar a regra de firewall, adicione-a novamente:

gcloud compute firewall-rules create default-allow-ssh \
    --allow tcp:22

Para visualizar todos os dados associados à regra de firewall default-allow-ssh no seu projeto, use o comando gcloud compute firewall-rules describe:

gcloud compute firewall-rules describe default-allow-ssh \
    --project=project-id

Para mais informações sobre regras de firewall, consulte Regras de firewall no Google Cloud.

Testar conexão de rede

Para determinar se a conexão de rede está funcionando, use a ferramenta nmap para se conectar à instância da porta 22. Se você conseguir se conectar e vir 22/tcp open ssh, significará que a conexão de rede está funcionando e é possível descartar os problemas de firewall.

  1. Use a ferramenta gcloud para receber o natIP externo da instância:

    gcloud compute instances describe VM_NAME \
    --format='get(networkInterfaces[0].accessConfigs[0].natIP)'

    Substitua VM_NAME pelo nome da VM à qual você não pode se conectar.

  2. Teste a conexão de rede com a instância.

    Execute o comando nmap para testar a conexão de rede com sua instância, substituindo external-ip pelo IP externo recebido na etapa 1:

    nmap external-ip

    Por exemplo, se a instância tiver o IP externo 198.51.100.1, execute o comando a seguir:

    nmap 198.51.100.1
    Starting Nmap 7.70 ( https://nmap.org ) at 2019-03-18 16:04 Greenwich Standard Time
Nmap scan report for 229.30.196.35.bc.googleusercontent.com (198.51.100.1)
Host is up (0.0061s latency).
Not shown: 998 filtered ports
PORT     STATE  SERVICE
22/tcp   open   ssh
Nmap done: 1 IP address (1 host up) scanned in 6.22 seconds

Conectar-se como um usuário diferente

Talvez o problema que impeça você de fazer login esteja restrito à sua conta de usuário. Por exemplo, pode ser que as permissões no arquivo ~/.ssh/authorized_keys da instância não estejam definidas corretamente para o usuário.

Tente fazer login como um usuário diferente com a ferramenta gcloud. Para isso, especifique ANOTHER_USERNAME com a solicitação SSH. A ferramenta gcloud atualizará os metadados do projeto para adicionar o novo usuário e permitir o acesso por SSH.

gcloud compute ssh ANOTHER_USERNAME@VM_NAME

Substitua:

  • ANOTHER_USERNAME é um nome de usuário diferente do seu próprio nome de usuário;
  • VM_NAME é o nome da VM à qual você quer se conectar.

Depurar o problema no console serial

Recomendamos que você revise os registros do console serial para verificar se há erros de conexão. É possível acessar o console serial na sua estação de trabalho local usando um navegador.

Ative o acesso de leitura e gravação ao console serial de uma instância para que você consiga fazer login no console e solucionar os problemas nela. Isso é útil quando não é possível fazer login com SSH ou quando a instância não tem conexão com a rede. Ainda é possível acessar o console serial em ambas as situações.

Para aprender como ativar o acesso interativo e se conectar ao console serial de uma instância, consulte Como interagir com o console serial.

Inspecionar a instância de VM sem encerrá-la

Talvez você esteja com problemas para se conectar a uma instância que continua a exibir tráfego de produção corretamente. Nesse caso, convém inspecionar o disco sem interromper a instância.

Para inspecionar e resolver problemas do disco:

  1. Faça backup do disco de inicialização criando um snapshot do disco.
  2. Crie um disco permanente regular a partir desse snapshot.
  3. Crie uma instância temporária.
  4. Anexe e ative o disco permanente regular na nova instância temporária.

Esse procedimento cria uma rede isolada que permite apenas conexões SSH. Essa configuração impede que a instância clonada produza efeitos indesejados nos serviços de produção.

  1. Crie uma nova rede VPC para hospedar a instância clonada:

    gcloud compute networks create debug-network

    Substitua NETWORK_NAME pelo nome escolhido para chamar a nova rede.

  2. Adicione uma regra de firewall para possibilitar conexões SSH à rede:

    gcloud compute firewall-rules create debug-network-allow-ssh \
   --network debug-network \
   --allow tcp:22

  3. Crie um snapshot do disco de inicialização.

    gcloud compute disks snapshot BOOT_DISK_NAME \
   --snapshot-names debug-disk-snapshot

    Substitua BOOT_DISK_NAME pelo nome do disco de inicialização.

  4. Crie um novo disco com esse snapshot:

    gcloud compute disks create example-disk-debugging \
   --source-snapshot debug-disk-snapshot

  5. Crie uma instância de depuração sem um endereço IP externo:

    gcloud compute instances create debugger \
   --network debug-network \
   --no-address

  6. Anexe o disco de depuração à instância:

    gcloud compute instances attach-disk debugger \
   --disk example-disk-debugging

  7. Siga as instruções para conectar-se a uma instância sem um endereço IP externo.

  8. Depois de fazer login na instância de depuração, solucione o problema nela. Por exemplo, analise os registros da instância:

    sudo su -

    mkdir /mnt/VM_NAME

    mount /dev/disk/by-id/scsi-0Google_PersistentDisk_example-disk-debugging /mnt/VM_NAME

    cd /mnt/VM_NAME/var/log

    # Identify the issue preventing ssh from working
ls

    Substitua VM_NAME pelo nome da VM à qual você não pode se conectar.

Usar um script de inicialização

Se nenhuma das opções anteriores tiver ajudado, crie um script de inicialização para coletar informações logo após o início da instância. Siga as instruções para executar esse script.

Depois, também será necessário redefinir a instância antes que os metadados entrem em vigor. Para isso, use o comandogcloud compute instances reset.

Como alternativa, é possível recriar a instância executando um script de inicialização de diagnóstico:

  1. Execute gcloud compute instances delete com a sinalização --keep-disks.

    gcloud compute instances delete VM_NAME \
   --keep-disks boot

    Substitua VM_NAME pelo nome da VM à qual você não pode se conectar.

  2. Adicione uma nova instância com o mesmo disco e especifique o script de inicialização.

    gcloud compute instances create NEW_VM_NAME \
   --disk name=BOOT_DISK_NAME,boot=yes \
   --metadata startup-script-url URL

    Substitua:

    • NEW_VM_NAME é o nome da nova VM que você está criando;
    • BOOT_DISK_NAME é o nome do disco de inicialização da VM à qual não é possível se conectar;
    • URL é o URL do Cloud Storage para o script, no formato gs://BUCKET/FILE ou https://storage.googleapis.com/BUCKET/FILE .

Usar seu disco em uma instância nova

Se ainda for necessário recuperar dados do disco de inicialização permanente, desanexe-o e, em seguida, conecte-o como um disco secundário em uma nova instância.

  1. Exclua a VM à qual não é possível se conectar e mantenha o disco de inicialização:

    gcloud compute instances delete VM_NAME \
   --keep-disks=boot

    Substitua VM_NAME pelo nome da VM à qual você não pode se conectar.

  2. Crie uma nova VM com o disco de inicialização da VM antiga:

    gcloud compute instances create NEW_VM_NAME \
   --disk name=BOOT_DISK_NAME,boot=yes,auto-delete=no

    Substitua:

    • NEW_VM_NAME é o nome da nova VM que você está criando;
    • BOOT_DISK_NAME é o nome do disco de inicialização da VM à qual não é possível se conectar.

  3. Conecte-se à nova VM usando SSH:

    gcloud compute ssh NEW_VM_NAME

    Substitua NEW_VM_NAME pelo nome da nova VM.

Verifique se o disco de inicialização da VM está cheio

A VM pode ficar inacessível se o disco de inicialização estiver cheio. Esse cenário pode ser difícil de solucionar, porque nem sempre é óbvio quando o problema de conectividade da VM é devido a um disco de inicialização completo. Para mais informações sobre esse cenário, consulte Como solucionar problemas de uma VM inacessível devido a um disco de inicialização completo.

A seguir