Solução de erros de SSH

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

Ferramenta de solução de problemas SSH

Use a ferramenta de solução de problemas SSH para ajudar a determinar por que uma conexão SSH falhou. A ferramenta de solução de problemas realiza os seguintes testes para verificar a causa das falhas nas conexões SSH:

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

Execute a ferramenta de solução de problemas

Você pode usar o console do Google Cloud ou a CLI do Google Cloud para verificar problemas de rede e erros de permissão do usuário que podem causar falhas nas conexões SSH.

Console

Depois que uma conexão SSH falhar, você terá a opção de tentar novamente a conexão ou solucionar problemas de conexão usando a ferramenta de solução de problemas de SSH no navegador.

Para executar a ferramenta de solução de problemas, clique em Solução de problemas .

Inicie a ferramenta de solução de problemas SSH.

gcloud

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

gcloud compute ssh VM_NAME \
    --troubleshoot

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

A ferramenta solicita que você forneça permissão para realizar os testes de solução de problemas.

Revise os resultados

Depois de executar a ferramenta de solução de problemas, faça o seguinte:

  1. Revise os resultados do teste 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.

  3. Tente reconectar-se à VM.

    Se a conexão não for bem-sucedida, tente solucionar problemas manualmente fazendo o seguinte:

Erros comuns de SSH

Veja a seguir exemplos de erros comuns que você pode encontrar ao usar SSH para se conectar a VMs do Compute Engine.

Erros de SSH no navegador

Erro não autorizado 401

O seguinte erro pode ocorrer quando você se conecta à sua VM usando o SSH no navegador do console do Google Cloud:

Unauthorized
Error 401

Este erro ocorre se o usuário fizer parte de uma organização gerenciada no Google Workspace e houver uma restrição ativa na política do Workspace que impede os usuários de acessar o SSH no navegador e o console serial no Google Cloud.

Para resolver esse problema, peça a um administrador do Google Workspace que faça o seguinte:

  1. Confirme isso Google Cloud está habilitado para a organização .

    Se Google Cloud está desativado, ative-o e tente novamente a conexão.

  2. Confirme se os serviços que não são controlados individualmente estão habilitados.

    Se esses serviços estiverem desabilitados, habilite-os e tente novamente a conexão.

Se o problema persistir após ativar Google Cloud configurações no Google Workspace, faça o seguinte:

  1. Capture o tráfego de rede em um arquivo HTTP Archive Format (HAR) a partir do momento em que você inicia a conexão SSH no navegador.

  2. Crie um caso do Cloud Customer Care e anexe o arquivo HAR.

Não foi possível conectar, tentando novamente...

O seguinte erro pode ocorrer ao iniciar uma sessão SSH:

Could not connect, retrying ...

Não foi possível conectar, tentando novamente

Para resolver esse problema, faça o seguinte:

  1. Após a inicialização da VM, tente novamente a conexão. Se a conexão não for bem-sucedida, verifique se a VM não inicializou no modo de emergência executando o seguinte comando:

    gcloud compute instances get-serial-port-output VM_NAME \
| grep "emergency mode"

    Se a VM inicializar no modo de emergência, solucione problemas no processo de inicialização da VM para identificar onde o processo de inicialização está falhando.

  2. Verifique se o serviço google-guest-agent.service está em execução executando o seguinte comando no console serial .

    systemctl status google-guest-agent.service

    Se o serviço estiver desabilitado, habilite e inicie o serviço executando os seguintes comandos:

    systemctl enable google-guest-agent.service
systemctl start google-guest-agent.service

  3. Verifique se os scripts do Linux Google Agent estão instalados e em execução. Para obter mais informações, consulte Determinação do status do agente do Google . Se o Linux Google Agent não estiver instalado, reinstale-o .

  4. Verifique se você tem as funções necessárias para se conectar à VM. Se sua VM usar o login do sistema operacional, consulte Atribuir função IAM de login do sistema operacional . Se a VM não usar o Login do SO, você precisará da função de administrador da instância de computação ou da função de usuário da conta de serviço (se a VM estiver configurada para ser executada como uma conta de serviço). As funções são necessárias para atualizar a instância ou os metadados de chaves SSH do projeto.

  5. Verifique se existe uma regra de firewall que permite acesso SSH executando o seguinte comando:

    gcloud compute firewall-rules list | grep "tcp:22"

  6. Verifique se existe uma rota padrão para a Internet (ou para o host bastião). Para obter mais informações, consulte Verificando rotas .

  7. Certifique-se de que o volume raiz não esteja sem espaço em disco. Para obter mais informações, consulte Solução de problemas de discos cheios e redimensionamento de disco .

  8. Certifique-se de que a VM não esteja sem memória executando o seguinte comando:

    gcloud compute instances get-serial-port-output instance-name \
| grep "Out of memory: Kill process" - e "Kill process" -e "Memory cgroup out of memory" -e "oom"

    Se a VM estiver sem memória, conecte-se ao console serial para solucionar problemas.

Erros do Linux

Permissão negada (chave pública)

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

USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).

Este erro pode ocorrer por vários motivos. A seguir estão algumas das causas mais comuns desse erro:

  • Você usou uma chave SSH armazenada em metadados para se conectar a uma VM que tem o Login do SO habilitado. Se o Login do SO estiver ativado no seu projeto, o seu VM não aceita chaves SSH armazenadas em metadados. Se você não tiver certeza se o Login do SO está ativado, consulte Verificando se o Login do SO está configurado .

    Para resolver esse problema, tente um dos seguintes:

  • 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 habilitado. Se você desabilitar o Login do SO, sua VM não aceitará chaves SSH que foram armazenadas no seu perfil de Login do SO. Se você não tiver certeza se o Login do SO está ativado, consulte Verificando se o Login do SO está configurado .

    Para resolver esse problema, tente um dos seguintes:

  • A VM tem o Login do SO habilitado, mas você não tem permissões de IAM suficientes para usar o Login do SO. Para se conectar a uma VM que tenha o Login do SO habilitado, você deve ter as permissões necessárias para o Login do SO. Se você não tiver certeza se o Login do SO está ativado, consulte Verificando se o Login do SO está configurado .

    Para resolver esse problema, conceda as funções necessárias do IAM de login do SO .

  • Sua chave expirou e o Compute Engine excluiu seu arquivo ~/.ssh/authorized_keys . Se você adicionou chaves SSH manualmente à sua VM e depois se conectou à VM usando o console do Google Cloud, o Compute Engine criou um novo par de chaves para sua conexão. Depois que o novo par de chaves expirou, o Compute Engine excluiu o arquivo ~/.ssh/authorized_keys da VM, que incluía a chave SSH adicionada manualmente.

    Para resolver esse problema, tente um dos seguintes:

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

    Para resolver esse problema, tente um dos seguintes:

    • Execute o seguinte comando: 
      ssh -i PATH_TO_PRIVATE_KEY USERNAME@EXTERNAL_IP

      Substitua o seguinte:
      • PATH_TO_PRIVATE_KEY : o caminho para seu arquivo de chave SSH privado.
      • USERNAME : o nome de usuário do usuário que se conecta à instância. Se você gerencia suas chaves SSH em metadados, o nome de usuário é o que você especificou quando criou a chave SSH . Para contas de login do sistema operacional , o nome de usuário é definido no seu perfil do Google.
      • EXTERNAL_IP : o endereço IP externo da sua VM.
    • Conecte-se à sua VM usando o console do Google Cloud ou a CLI do Google Cloud. Quando você usa essas ferramentas para se conectar, o Compute Engine gerencia a criação de chaves para você. Para obter mais informações, consulte Conectando-se a VMs .

  • O ambiente convidado da sua VM não está em execução. Se esta for a primeira vez que você está se conectando à sua VM e o ambiente 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 Google Cloud, inspecione os registros de inicialização do sistema na saída da porta serial para determinar se o ambiente convidado está em execução. Para obter mais informações, consulte Validando o ambiente convidado .
    3. Se o ambiente 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 OpenSSH Daemon ( sshd ) não está em execução ou configurado corretamente. O sshd fornece acesso remoto seguro ao sistema via protocolo SSH. Se estiver configurado incorretamente ou não estiver em execução, você não poderá se conectar à sua VM via SSH.

    Para resolver esse problema, tente um ou mais dos seguintes procedimentos:

    • Revise o guia do usuário do seu sistema operacional para garantir que o sshd_config esteja configurado corretamente.

    • Certifique-se de ter as configurações de propriedade e permissão necessárias para o seguinte:

      • Diretórios $HOME e $HOME/.ssh
      • Arquivo $HOME/.ssh/authorized_keys

      Propriedade

      O ambiente convidado armazena chaves públicas SSH autorizadas no arquivo $HOME/.ssh/authorized_keys . O proprietário dos diretórios $HOME e $HOME/.ssh e do arquivo $HOME/.ssh/authorized_keys deve ser o mesmo do usuário que está se conectando à VM.

      Permissões

      O ambiente convidado requer as seguintes permissões do Linux:

      Caminho Permissões
      /home 0755
      $HOME 0700 ou 0750 ou 0755 *
      $HOME/.ssh 0700
      $HOME/.ssh/authorized_keys 0600

      * Para descobrir qual das opções é a permissão padrão correta para o seu diretório $HOME , consulte a documentação oficial da sua distribuição Linux específica.

      Alternativamente, você pode criar uma nova VM baseada na mesma imagem e verificar suas permissões padrão para $HOME .

      Para saber como alterar permissões e propriedade, leia sobre chmod e chown .

    • Reinicie o sshd executando o seguinte comando: 

      systemctl restart sshd.service

      Verifique se há algum erro no status executando o seguinte comando: 

      systemctl status sshd.service

      A saída de status pode conter informações como o código de saída, o motivo da falha, etc. Você pode usar esses detalhes para solucionar problemas adicionais.

  • O disco de inicialização da VM está cheio. Quando uma conexão SSH é estabelecida, o ambiente convidado adiciona a chave SSH pública da sessão ao arquivo ~/.ssh/authorized_keys . Se o disco estiver cheio, a conexão falhará.

    Para resolver esse problema, siga um ou mais destes procedimentos:

    • Confirme se o disco de inicialização está cheio depurando com o console serial para identificar no space left errors .
    • Redimensione o disco.
    • Se você souber quais arquivos estão usando o espaço em disco, crie um script de inicialização que exclua arquivos desnecessários e libere espaço. Depois que a VM for iniciada e você se conectar a ela, exclua os metadados startup-script .

  • As permissões ou propriedade em $HOME , $HOME/.ssh ou $HOME/.ssh/authorized_keys estão erradas.

    Propriedade

    O ambiente convidado armazena chaves públicas SSH autorizadas no arquivo $HOME/.ssh/authorized_keys . O proprietário dos diretórios $HOME e $HOME/.ssh e do arquivo $HOME/.ssh/authorized_keys deve ser o mesmo do usuário que está se conectando à VM.

    Permissões

    O ambiente convidado requer as seguintes permissões do Linux:

    Caminho Permissões
    /home 0755
    $HOME 0700 ou 0750 ou 0755 *
    $HOME/.ssh 0700
    $HOME/.ssh/authorized_keys 0600

    * Para descobrir qual das opções é a permissão padrão correta para o seu diretório $HOME , consulte a documentação oficial da sua distribuição Linux específica.

    Alternativamente, você pode criar uma nova VM baseada na mesma imagem e verificar suas permissões padrão para $HOME .

    Para saber como alterar permissões e propriedade, leia sobre chmod e chown .

Falha na conexão

Os erros a seguir podem ocorrer quando você se conecta à VM por meio do console do Google Cloud, da CLI gcloud, de um bastion host ou de um cliente local:

  • O console do Google Cloud: 

    Connection Failed

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

  • A CLI gcloud: 

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

  • Um host bastião ou um cliente local: 

    port 22: Connection timed out.

    port 22: Connection refused

Esses erros podem ocorrer por vários motivos. A seguir estão algumas das causas mais comuns dos erros:

  • A VM está inicializando e sshd ainda não está em execução. Você não pode se conectar a uma VM antes de ela estar em execução.

    Para resolver esse problema, aguarde até que a VM termine a inicialização e tente conectar-se novamente.

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

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

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

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

  • A regra de firewall SSH está ausente ou não permite tráfego do IAP ou da Internet pública. As conexões SSH serão recusadas se as regras de firewall não permitirem conexões de tráfego de entrada IAP ou TCP para o intervalo de IP 0.0.0.0/0 .

    Para resolver esse problema, siga um destes procedimentos:

    • Se você usar o Identity-Aware Proxy (IAP) para encaminhamento de TCP, atualize sua regra de firewall personalizada para aceitar o tráfego do IAP e verifique suas permissões do IAM.

      1. Atualize sua regra de firewall personalizada para permitir o tráfego de 35.235.240.0/20 , o intervalo de endereços IP que o IAP usa para encaminhamento de TCP. Para obter mais informações, consulte Criar uma regra de firewall .
      2. Conceda permissões para usar o encaminhamento TCP do IAP , caso ainda não tenha feito isso.

    • Se você não usa o IAP, atualize sua regra de firewall personalizada para permitir o tráfego SSH de entrada.

      1. Atualize sua regra de firewall personalizada para Permitir conexões SSH de entrada para VMs .

  • A conexão SSH falhou depois que você atualizou o 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 que não responde.
    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 instantâneo do disco de inicialização antes de atualizar a VM, use o instantâneo para criar uma VM .

  • O OpenSSH Daemon ( sshd ) não está em execução ou configurado corretamente. O sshd fornece acesso remoto seguro ao sistema via protocolo SSH. Se estiver configurado incorretamente ou não estiver em execução, você não poderá se conectar à sua VM via SSH.

    Para resolver esse problema, tente um ou mais dos seguintes procedimentos:

    • Revise o guia do usuário do seu sistema operacional para garantir que o sshd_config esteja configurado corretamente.

    • Certifique-se de ter as configurações de propriedade e permissão necessárias para o seguinte:

      • Diretórios $HOME e $HOME/.ssh
      • Arquivo $HOME/.ssh/authorized_keys

      Propriedade

      O ambiente convidado armazena chaves públicas SSH autorizadas no arquivo $HOME/.ssh/authorized_keys . O proprietário dos diretórios $HOME e $HOME/.ssh e do arquivo $HOME/.ssh/authorized_keys deve ser o mesmo do usuário que está se conectando à VM.

      Permissões

      O ambiente convidado requer as seguintes permissões do Linux:

      Caminho Permissões
      /home 0755
      $HOME 0700 ou 0750 ou 0755 *
      $HOME/.ssh 0700
      $HOME/.ssh/authorized_keys 0600

      * Para descobrir qual das opções é a permissão padrão correta para o seu diretório $HOME , consulte a documentação oficial da sua distribuição Linux específica.

      Alternativamente, você pode criar uma nova VM baseada na mesma imagem e verificar suas permissões padrão para $HOME .

      Para saber como alterar permissões e propriedade, leia sobre chmod e chown .

    • Reinicie o sshd executando o seguinte comando: 

      systemctl restart sshd.service

      Verifique se há algum erro no status executando o seguinte comando: 

      systemctl status sshd.service

      A saída de status pode conter informações como o código de saída, o motivo da falha, etc. Você pode usar esses detalhes para solucionar problemas adicionais.

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

  • A VM está inicializando no modo de manutenção. Ao inicializar no modo de manutenção, a VM não aceita conexões SSH, mas você pode conectar-se ao console serial da VM e fazer login como usuário root.

    Para resolver esse problema, faça o seguinte:

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

      echo 'root: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 usuário root.

Erro inesperado

O seguinte erro pode ocorrer quando você tenta se conectar a uma VM Linux: 

Connection Failed
You cannot connect to the VM instance because of an unexpected error. Wait a few moments and then try again.

Esse problema pode ocorrer por vários motivos. A seguir estão algumas causas comuns do erro:

  • O OpenSSH Daemon ( sshd ) não está em execução ou configurado corretamente. O sshd fornece acesso remoto seguro ao sistema via protocolo SSH. Se estiver configurado incorretamente ou não estiver em execução, você não poderá se conectar à sua VM via SSH.

    Para resolver esse problema, tente um ou mais dos seguintes procedimentos:

    • Revise o guia do usuário do seu sistema operacional para garantir que o sshd_config esteja configurado corretamente.

    • Certifique-se de ter as configurações de propriedade e permissão necessárias para o seguinte:

      • Diretórios $HOME e $HOME/.ssh
      • Arquivo $HOME/.ssh/authorized_keys

      Propriedade

      O ambiente convidado armazena chaves públicas SSH autorizadas no arquivo $HOME/.ssh/authorized_keys . O proprietário dos diretórios $HOME e $HOME/.ssh e do arquivo $HOME/.ssh/authorized_keys deve ser o mesmo do usuário que está se conectando à VM.

      Permissões

      O ambiente convidado requer as seguintes permissões do Linux:

      Caminho Permissões
      /home 0755
      $HOME 0700 ou 0750 ou 0755 *
      $HOME/.ssh 0700
      $HOME/.ssh/authorized_keys 0600

      * Para descobrir qual das opções é a permissão padrão correta para o seu diretório $HOME , consulte a documentação oficial da sua distribuição Linux específica.

      Alternativamente, você pode criar uma nova VM baseada na mesma imagem e verificar suas permissões padrão para $HOME .

      Para saber como alterar permissões e propriedade, leia sobre chmod e chown .

    • Reinicie o sshd executando o seguinte comando: 

      systemctl restart sshd.service

      Verifique se há algum erro no status executando o seguinte comando: 

      systemctl status sshd.service

      A saída de status pode conter informações como o código de saída, o motivo da falha, etc. Você pode usar esses detalhes para solucionar problemas adicionais.

  • Problema desconhecido no daemon SSH . Para diagnosticar um problema desconhecido do daemon SSH, verifique se há erros nos logs do console serial .

    Dependendo da saída dos logs do console serial, tente resgatar a VM e corrigir os problemas relacionados ao daemon SSH fazendo o seguinte:

    1. Anexe o disco a outra VM Linux.
    2. Conecte-se à VM que possui o disco montado.
    3. Monte o disco dentro do SO em um diretório MOUNT_DIR dentro da VM.
    4. Visualize os logs relacionados ao SSH, /var/log/secure ou /var/log/auth.log para quaisquer problemas/erros. Se você encontrar algum problema que possa corrigir, tente corrigi-lo. Caso contrário, crie um caso de suporte e anexe os logs.

    5. Desmonte o disco do sistema operacional usando o comando umount : 

      cd ~/
umount /mnt

    6. Desconecte o disco da VM.

    7. Anexe o disco à VM original.

    8. Inicie a VM.

Falha ao conectar ao back-end

Os seguintes erros podem ocorrer quando você se conecta à VM por meio do console do Google Cloud ou da CLI gcloud:

  • O console do Google Cloud: 

    -- Connection via Cloud Identity-Aware Proxy Failed

-- Code: 4003

-- Reason: failed to connect to backend

  • A CLI gcloud: 

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

Esses erros ocorrem quando você tenta usar o SSH para se conectar a uma VM que não possui um endereço IP público e para a qual você 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.

A chave do host não corresponde

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

Host key for server IP_ADDRESS does not match

Este erro ocorre quando a chave do host no arquivo ~/.ssh/known_hosts não corresponde à chave do host da VM.

Para resolver esse problema, exclua a chave do host do arquivo ~/.ssh/known_hosts e tente novamente a conexão.

O valor dos metadados é muito grande

O seguinte erro pode ocorrer ao tentar adicionar uma nova chave SSH aos metadados: 

ERROR:"Value for field 'metadata.items[X].value' is too large: maximum size 262144 character(s); actual size NUMBER_OF_CHARACTERS."

Os valores de metadados têm um limite máximo de 256 KB . Para atenuar essa limitação, siga um destes procedimentos:

Erros do Windows

Permissão negada, tente novamente

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

USERNAME@compute.INSTANCE_ID's password:
Permission denied, please try again.

Este erro indica que o usuário que está tentando se conectar à VM não existe na VM. A seguir estão algumas das causas mais comuns desse erro:

  • Sua versão da CLI gcloud está desatualizada

    Se a CLI gcloud estiver desatualizada, você pode estar tentando se conectar usando um nome de usuário que não está configurado. Para resolver esse problema, atualize a CLI gcloud .

  • Você tentou se conectar a uma VM do Windows que não tem SSH habilitado.

    Para resolver esse erro, defina a chave enable-windows-ssh como TRUE nos metadados do projeto ou da instância. Para obter mais informações sobre como configurar metadados, consulte Definir metadados personalizados .

Permissão negada (chave pública, teclado interativo)

O seguinte erro pode ocorrer quando você se conecta a uma VM que não tem SSH habilitado: 

Permission denied (publickey,keyboard-interactive).

Para resolver esse erro, defina a chave enable-windows-ssh como TRUE nos metadados do projeto ou da instância. Para obter mais informações sobre como configurar metadados, consulte Definir metadados personalizados .

Não foi possível usar SSH na instância

O seguinte erro pode ocorrer quando você se conecta à VM por meio da CLI gcloud: 

ERROR: (gcloud.compute.ssh) Could not SSH into the instance.
It is possible that your SSH key has not propagated to the instance yet.
Try running this command again.  If you still cannot connect, verify that the firewall and instance are set to accept ssh traffic.

Este erro pode ocorrer por vários motivos. A seguir estão algumas das causas mais comuns dos erros:

  • Você tentou se conectar a uma VM do Windows que não tem SSH instalado.

    Para resolver esse problema, siga as instruções para Habilitar SSH para Windows em uma VM em execução .

  • O servidor OpenSSH ( sshd ) não está em execução ou não está configurado corretamente. O sshd fornece acesso remoto seguro ao sistema via protocolo SSH. Se estiver configurado incorretamente ou não estiver em execução, você não poderá se conectar à sua VM via SSH.

    Para resolver esse problema, revise a configuração do OpenSSH Server para Windows Server e Windows para garantir que sshd esteja configurado corretamente.

A conexão expirou

As conexões SSH expiradas podem ser causadas por um dos seguintes motivos:

  • A VM não concluiu a inicialização. Aguarde um pouco para a VM inicializar.

    Para resolver esse problema, aguarde até que a VM termine a inicialização e tente conectar-se novamente.

  • O pacote SSH não está instalado. As VMs do Windows exigem que você instale o pacote google-compute-engine-ssh antes de poder se conectar usando SSH.

    Para resolver esse problema, instale o pacote SSH .

Diagnosticar conexões SSH com falha

As seções a seguir descrevem as etapas que você pode seguir para diagnosticar a causa das falhas nas conexões SSH e as etapas que você pode seguir para corrigir suas conexões.

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

Métodos de diagnóstico para VMs Linux e Windows

Testar conectividade

Talvez você não consiga fazer SSH para 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 quaisquer problemas de conectividade.

Verifique suas regras de firewall

O Compute Engine provisiona cada projeto com um conjunto padrão de regras de firewall que permitem o tráfego SSH. Se você não conseguir acessar sua instância, use a ferramenta de linha de comando gcloud compute para verificar sua lista de firewalls e garantir que a regra default-allow-ssh esteja presente.

Na sua estação de trabalho local, execute o seguinte comando: 

gcloud compute firewall-rules list

Se a regra de firewall estiver faltando, 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 obter mais informações sobre regras de firewall, consulte Regras de firewall em Google Cloud .

Teste a conexão de rede

Para determinar se a conexão de rede está funcionando, teste o handshake TCP:

  1. Obtenha o natIP externo para sua 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 consegue se conectar.

  2. Teste a conexão de rede com sua VM na estação de trabalho:

    Linux, Windows 2019/2022 e macOS 

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

    Substitua o seguinte:

    • EXTERNAL_IP : o endereço IP externo que você obteve 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 TCP bem-sucedido.

    Janelas 2012 e 2016 

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

    Substitua o seguinte:

    • EXTERNAL_IP : o IP externo que você obteve 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 TCP bem-sucedido.

Se o handshake TCP for concluído com êxito, uma regra de firewall de software não está bloqueando a conexão, o sistema operacional está encaminhando pacotes corretamente e um servidor está escutando na porta de destino. Se o handshake TCP for concluído com sucesso, mas a VM não aceitar conexões SSH, o problema pode ser que o daemon sshd esteja configurado incorretamente ou não esteja funcionando corretamente. Revise 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 deve permitir o tráfego, consulte Verificar regras de firewall mal configuradas no Google Cloud .

Conecte-se como um usuário diferente

O problema que impede você de fazer login pode estar limitado à sua conta de usuário. Por exemplo, as permissões no arquivo ~/.ssh/authorized_keys na instância podem não estar configuradas corretamente para o usuário.

Tente fazer login como um usuário diferente com a CLI gcloud especificando ANOTHER_USERNAME com a solicitação SSH. A CLI gcloud atualiza os metadados do projeto para adicionar o novo usuário e permitir acesso SSH. 

gcloud compute ssh ANOTHER_USERNAME@VM_NAME

Substitua o seguinte:

  • ANOTHER_USERNAME é um nome de usuário diferente do seu
  • VM_NAME é o nome da VM à qual você deseja se conectar

Depurar problemas usando o console serial

Recomendamos que você revise os logs do console serial em busca de erros de conexão. Você pode acessar o console serial como usuário root a partir de sua estação de trabalho local usando um navegador. Essa abordagem é útil quando você não consegue fazer login com SSH ou se a instância não tiver conexão com a rede. O console serial permanece acessível em ambas as situações.

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

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

  2. Para VMs Linux, modifique a senha raiz e adicione o seguinte script de inicialização à sua VM: 

    echo root:PASSWORD | chpasswd

    Substitua PASSWORD por uma senha de sua preferência.

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

  4. Para VMs Linux, depois de depurar todos os erros, desative o login da conta root: 

    sudo passwd -l root

Métodos de diagnóstico para VMs Linux

Inspecione a instância da VM sem desligá-la

Você pode ter uma instância à qual não consegue se conectar e que continua atendendo corretamente ao tráfego de produção. Nesse caso, talvez você queira inspecionar o disco sem interromper a instância.

Para inspecionar e solucionar problemas do disco:

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

Este procedimento cria uma rede isolada que permite apenas conexões SSH. Essa configuração evita quaisquer consequências não intencionais da instância clonada interferindo nos seus serviços de produção.

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

    gcloud compute networks create debug-network

    Substitua NETWORK_NAME pelo nome que você deseja chamar para sua nova rede.

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

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

  3. Crie um instantâneo 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 o snapshot que você acabou de criar: 

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

  5. Crie uma nova 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 VM usando um host bastião .

  8. Depois de fazer login na instância do depurador, solucione o problema da instância. Por exemplo, você pode consultar os logs 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 consegue se conectar.

Use um script de inicialização

Se nenhuma das opções anteriores ajudou, você poderá criar um script de inicialização para coletar informações logo após o início da instância. Siga as instruções para executar um script de inicialização .

Depois disso, você também precisará redefinir sua instância antes que os metadados entrem em vigor usando gcloud compute instances reset .

Como alternativa, você também pode recriar sua 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 consegue se conectar.

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

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

    Substitua o seguinte:

    • 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 você não consegue se conectar
    • URL é o URL do Cloud Storage para o script, no formato gs:// BUCKET / FILE ou https://storage.googleapis.com/ BUCKET / FILE .

Use seu disco em uma nova instância

Se ainda precisar recuperar dados do disco de inicialização persistente, você poderá desanexar o disco de inicialização e, em seguida, anexar esse disco como um disco secundário em uma nova instância.

  1. Exclua a VM à qual você não consegue se conectar e mantenha seu disco de inicialização: 

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

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

  2. Crie uma nova VM com o disco de inicialização da sua VM antiga . Especifique o nome do disco de inicialização da VM que você acabou de excluir.

  3. Conecte-se à sua nova VM usando SSH: 

    gcloud compute ssh NEW_VM_NAME

    Substitua NEW_VM_NAME pelo nome da sua nova VM.

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

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

Métodos de diagnóstico para VMs do Windows

Redefinir metadados SSH

Se você não conseguir se conectar a uma VM do Windows usando SSH, tente desabilitar a chave de metadados enable-windows-ssh e reativar o SSH para Windows.

  1. Defina a chave de metadados enable-windows-ssh como FALSE . Para obter informações sobre como definir metadados, consulte Definir metadados personalizados .

    Aguarde alguns segundos para que a alteração ocorra.

  2. Reativar SSH para Windows

  3. Reconecte-se à VM .

Conecte-se à VM usando RDP

Se você não conseguir diagnosticar e resolver a causa da falha nas conexões SSH com sua VM do Windows, conecte-se usando RDP .

Depois de estabelecer uma conexão com a VM, revise os logs do OpenSSH .

O que vem a seguir?