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.

Antes de começar

Ferramenta de solução de problemas SSH

Use a ferramenta de solução de problemas SSH para ajudar a determinar o motivo da falha na conexão SSH. A ferramenta de solução de problemas realiza os testes a seguir para verificar a causa das conexões SSH com falha:

  • Testes de permissões do usuário: verifica se você tem as permissões necessárias do IAM para se conectar à VM usando SSH.
  • Testes de conectividade de rede: verifica se a VM está conectada à rede.
  • Testes de status de instâncias de VM: verifica se o status da CPU da VM está em execução
  • Testes de configurações de VPC: verifica a porta padrão SSH e o encaminhamento de portas do IAP

Executar a ferramenta de solução de problemas

Execute a ferramenta de solução de problemas usando o comando gcloud beta compute ssh:

gcloud beta compute ssh VM_NAME --troubleshoot

Substitua VM_NAME pelo nome da VM a que você não pode se conectar.

A ferramenta solicita que você dê permissão para executar os testes de solução de problemas.

Depois de executar a ferramenta de solução de problemas:

  1. Analise os resultados do teste na saída do console do gcloud para entender por que a conexão SSH da VM não está funcionando.
  2. Resolva conexões SSH executando as etapas de correção fornecidas pela ferramenta.

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:
      • PATH_TO_PRIVATE_KEY: o caminho para o arquivo da chave SSH particular.
      • USERNAME: o nome do usuário que se conecta à instância. Se você gerencia suas chaves SSH em metadados, o nome de usuário será aquele que você especificou quando criou a chave SSH. Em contas do Login do SO, o nome de usuário é definido no seu perfil do Google.
      • EXTERNAL_IP: o endereço IP externo da VM.
    • 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 ambiente convidado da VM não está em execução. Se esta for a primeira vez que você está se conectando à VM e o ambiente de convidado não estiver em execução, a VM poderá recusar sua solicitação de conexão SSH.

    Para resolver esse problema, faça o seguinte:

    1. Reinicie a VM.
    2. No Console do Cloud, inspecione os registros de inicialização do sistema na saída da porta serial para determinar se o ambiente convidado está sendo executado. Para mais informações, consulte Como validar o ambiente de convidado.
    3. Se o ambiente para convidado não estiver em execução, instale-o manualmente clonando o disco de inicialização da VM e usando um script de inicialização.
  • 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, tente o seguinte:

    • Consulte o guia do usuário do seu sistema operacional para garantir que o sshd_config esteja configurado corretamente.
    • Se você já tiver modificado as permissões da pasta na VM, altere-as para os padrões:

      • 700 no diretório .ssh
      • 644 na chave pública, que é armazenada na pasta ~/.ssh/authorized_keys

      Conecte-se ao console serial da VM como o usuário raiz e modifique as permissões da pasta:

      chmod 700 /home/USERNAME/.ssh; chmod 644 /home/USERNAME/.ssh/authorized_keys

      Substitua USERNAME pelo nome de usuário para o qual você quer modificar as permissões da pasta.

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.

  • A conexão SSH falhou depois que você fez upgrade do kernel da VM. Uma VM pode sofrer um kernel panic após uma atualização do kernel, fazendo com que a VM fique inacessível.

    Para resolver esse problema, faça o seguinte:

    1. Monte o disco em outra VM.
    2. Atualize o arquivo grub.cfg para usar a versão anterior do kernel.
    3. Anexe o disco à VM sem resposta.
    4. Verifique se o status da VM é RUNNING usando o comando gcloud compute instances describe.
    5. Reinstale o kernel.
    6. Reinicie a VM.

    Como alternativa, se você criou um snapshot do disco de inicialização antes de fazer upgrade da VM, use o snapshot para criar uma VM.

  • 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, tente o seguinte:

    • Consulte o guia do usuário do seu sistema operacional para garantir que o sshd_config esteja configurado corretamente.
    • Se você já tiver modificado as permissões da pasta na VM, altere-as para os padrões:

      • 700 no diretório .ssh
      • 644 na chave pública, que é armazenada na pasta ~/.ssh/authorized_keys

      Conecte-se ao console serial da VM como o usuário raiz e modifique as permissões da pasta:

      chmod 700 /home/USERNAME/.ssh; chmod 644 /home/USERNAME/.ssh/authorized_keys

      Substitua USERNAME pelo nome de usuário para o qual você quer modificar as permissões da pasta.

  • A VM não está inicializando e não é possível se conectar usando SSH ou o console serial. Se a VM estiver inacessível, o sistema operacional poderá estar corrompido. Se o disco de inicialização não for inicializado, será possível diagnosticar o problema. Se você quiser recuperar a VM corrompida e recuperar dados, consulte Como recuperar uma VM corrompida ou um disco de inicialização completo.

  • A VM está sendo inicializada no modo de manutenção. Ao inicializar no modo de manutenção, a VM não aceita conexões SSH, mas é possível se conectar ao console serial da VM e fazer login como usuário raiz.

    Para resolver esse problema, faça o seguinte:

    1. Se você não tiver definido uma senha raiz para a VM, use um script de inicialização de metadados para executar o seguinte comando durante a inicialização:

      echo "NEW_PASSWORD" | chpasswd

      Substitua NEW_PASSWORD por uma senha de sua escolha.

    2. Reinicie a VM.

    3. Conecte-se ao console serial da VM e faça login como o usuário raiz.

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, teste o handshake TCP:

  1. Consiga o natIP externo da VM:

    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 VM pela estação de trabalho:

    Linux, Windows 2019 e macOS

    curl -vso /dev/null --connect-timeout 5 EXTERNAL_IP:PORT_NUMBER
    

    Substitua:

    • EXTERNAL_IP: o endereço IP externo que você recebeu na etapa anterior;
    • PORT_NUMBER: o número da porta

    Se o handshake TCP for bem-sucedido, a saída será semelhante a esta:

    Expire in 0 ms for 6 (transfer 0x558b3289ffb0)
    Expire in 5000 ms for 2 (transfer 0x558b3289ffb0)
    Trying 192.168.0.4...
    TCP_NODELAY set
    Expire in 200 ms for 4 (transfer 0x558b3289ffb0)
    Connected to 192.168.0.4 (192.168.0.4) port 443 (#0)
    > GET / HTTP/1.1
    > Host: 192.168.0.4:443
    > User-Agent: curl/7.64.0
    > Accept: */*
    >
    Empty reply from server
    Connection #0 to host 192.168.0.4 left intact
    

    A linha Connected to indica um handshake de TCP bem-sucedido.

    Windows 2012 e 2016

    PS C:> New-Object System.Net.Sockets.TcpClient('EXTERNAL_IP',PORT_NUMBER)
    

    Substitua:

    • EXTERNAL_IP: o IP externo que você recebeu na etapa anterior;
    • PORT_NUMBER: o número da porta

    Se o handshake TCP for bem-sucedido, a saída será semelhante a esta:

    Available           : 0
    Client              : System.Net.Sockets.Socket
    Connected           : True
    ExclusiveAddressUse : False
    ReceiveBufferSize   : 131072
    SendBufferSize      : 131072
    ReceiveTimeout      : 0
    SendTimeout         : 0
    LingerState         : System.Net.Sockets.LingerOption
    NoDelay             : False
    

    A linha Connected: True indica um handshake de TCP bem-sucedido.

Se o handshake TCP for concluído com sucesso, uma regra de firewall de software não bloqueará a conexão, o SO encaminhará pacotes corretamente e um servidor fará detecções na porta de destino. Se o handshake TCP for concluído com êxito, mas a VM não aceitar conexões SSH, o problema pode ser com o daemon sshd estar configurado incorretamente ou não ser executado corretamente. Consulte o guia do usuário do seu sistema operacional para garantir que o sshd_config esteja configurado corretamente.

Para executar testes de conectividade para analisar a configuração do caminho de rede VPC entre duas VMs e verificar se a configuração programada permite o tráfego, consulte Verificar se há regras de firewall configuradas incorretamente no Google Cloud.

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 problemas usando o 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 como usuário raiz na estação de trabalho local usando um navegador. Isso é útil quando não é possível fazer login com SSH ou quando a instância não tem conexão com a rede. O console serial ainda pode ser acessado em ambas as situações.

Para fazer login no console serial da VM e resolver problemas com ela, siga estas etapas:

  1. Ative o acesso interativo ao console serial da VM.

  2. Para modificar a senha raiz, adicione o seguinte script de inicialização à VM:

    usermod -p $(echo "PASSWORD" | openssl passwd -1 -stdin) root
    Substitua PASSWORD por uma senha de sua escolha.

  3. Use o console serial para se conectar à VM.

  4. Depois de depurar todos os erros, desative o login da conta raiz:

    sudo passwd -l root

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