Resolver erros do SSH

Neste documento, descrevemos erros comuns que podem acontecer ao se conectar a instâncias de máquina virtual (VM) usando SSH, maneiras de resolvê-los e métodos para diagnosticar conexões SSH com falha.

Ferramenta de solução de problemas de SSH

Use a ferramenta de solução de problemas de SSH para determinar o motivo de uma falha na conexão SSH. Essa ferramenta realiza os seguintes testes 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 o status da CPU da VM para saber se a VM está em execução.
  • Testes de configurações de VPC: verifica a porta SSH padrão.

Executar a ferramenta de solução de problemas

Use o console do Google Cloud ou a CLI do Google Cloud para verificar se há problemas de rede e erros de permissão do usuário que podem causar falha nas conexões SSH.

Console

Quando uma conexão SSH falha, você tem a opção de Tentar novamente ou Resolver problemas usando a ferramenta de solução de problemas de SSH no navegador.

Para executar essa ferramenta, clique em Resolver problemas.

Inicie a ferramenta de solução de problemas de 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 a que você não consegue se conectar.

A ferramenta vai solicitar sua permissão para executar os testes de solução de problemas.

Analisar os resultados

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

  1. Analise os resultados do teste para entender por que a conexão SSH da VM não está funcionando.
  2. Resolva os problemas em conexões SSH seguindo as etapas de correção fornecidas pela ferramenta.

  3. Tente se reconectar à VM.

    Se a conexão não funcionar, tente solucionar os problemas manualmente fazendo o seguinte:

Erros comuns de SSH

Confira a seguir exemplos de erros comuns que podem acontecer ao usar SSH para se conectar a VMs do Compute Engine.

Erros de SSH no navegador

Erro 401: acesso não autorizado

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

Unauthorized
Error 401

Esse erro acontece quando usuários fazem parte de uma organização gerenciada no Google Workspace e há uma restrição ativa na política do Workspace que os impede de acessar o SSH no navegador e o console serial no Google Cloud.

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

  1. Confirmar se o Google Cloud está ativado para a organização.

    Se o Google Cloud estiver desativado, será preciso ativá-lo e tentar estabelecer novamente a conexão.

  2. Verificar se os serviços que não são controlados individualmente estão ativados.

    Se esses serviços estiverem desativados, será preciso ativá-los e tentar estabelecer novamente a conexão.

Se o problema persistir após a ativação das configurações do Google Cloud no Google Workspace, será preciso fazer o seguinte:

  1. Capturar o tráfego da rede em um arquivo HTTP Archive (HAR) a partir do início da conexão SSH no navegador.

  2. Criar um caso do Cloud Customer Care e anexar o arquivo HAR.

Não foi possível estabelecer uma conexão. Tentando novamente…

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

Could not connect, retrying ...

Não foi possível estabelecer uma conexão. Tentando novamente…

Para resolver esse problema, faça o seguinte:

  1. Depois da inicialização da VM, tente se conectar novamente. Se não for possível se conectar, execute o seguinte comando para verificar se a VM não foi inicializada no modo de emergência:

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

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

  2. Execute o comando abaixo no console serial para verificar se o serviço google-guest-agent.service está em execução.

    systemctl status google-guest-agent.service

    Se o serviço estiver desativado, execute os seguintes comandos para ativá-lo e iniciá-lo:

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

  3. Verifique se os scripts do agente do Google para Linux estão instalados e em execução. Para mais informações, consulte Como determinar o status do agente do Google. Se o agente do Google para Linux não estiver instalado, faça a reinstalação.

  4. Verifique se você tem os papéis necessários para se conectar à VM. Se a VM usar o Login do SO, consulte Atribuir um papel do IAM para o Login do SO. Se a VM não usar o Login do SO, você vai precisar do papel de administrador da instância do Compute ou do papel de usuário da conta de serviço, se a VM estiver configurada para execução como uma conta de serviço. Os papéis são necessários para atualizar os metadados das chaves SSH da instância ou do projeto.

  5. Execute o seguinte comando para verificar se há uma regra de firewall que permita o acesso SSH:

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

  6. Verifique se há uma rota padrão para a Internet (ou para o Bastion Host). Para mais informações, consulte Como verificar rotas.

  7. Verifique se o volume raiz não está sem espaço em disco. Para mais informações, consulte Como solucionar problemas de discos sem espaço e redimensionamento de discos.

  8. Execute o seguinte comando para verificar se a VM não ficou sem memória:

    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 resolver o problema.

Erros do Linux

Permissão negada (chave pública)

Este erro pode acontecer ao se conectar à VM:

USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).

Esse erro pode acontecer por vários motivos. Estas são algumas das causas mais comuns para o 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 vai aceitar chaves SSH armazenadas nos metadados. Para confirmar se o Login do SO está ativado, consulte Como verificar se o Login do SO está configurado.

    Para resolver o problema, teste uma das seguintes opções:

  • Você usou uma chave SSH armazenada em um perfil do Login do SO para se conectar a uma VM em que ele não está ativado. Se você desativar o Login do SO, a VM não vai aceitar chaves SSH armazenadas em um perfil do Login do SO. Para confirmar se o Login do SO está ativado, consulte Como verificar se o Login do SO está configurado.

    Para resolver o problema, teste uma das seguintes opções:

  • O Login do SO está ativado na VM, mas você não tem permissões do IAM suficientes para usar esse recurso. Para se conectar a uma VM em que o Login do SO está ativado, você vai precisar das permissões necessárias. Para confirmar se o Login do SO está ativado, consulte Como verificar se o Login do SO está configurado.

    Para resolver esse problema, conceda os papéis do IAM necessários para o Login do SO.

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

    Para resolver o problema, teste uma das seguintes opções:

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

    Para resolver o problema, teste uma das seguintes opções:

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

      Substitua:
      • PATH_TO_PRIVATE_KEY: o caminho do arquivo da chave SSH privada.
      • USERNAME: o nome do usuário que se conecta à instância. Se você gerencia as chaves SSH nos metadados, o nome do usuário será aquele que você especificou quando criou a chave SSH. Em Contas do Login do SO, o nome do 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 CLI do Google Cloud. 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ê se conecta à VM e o ambiente de convidado não estiver em execução, a VM poderá recusar a 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 de convidado está em execução. Para mais informações, consulte Como validar o ambiente de convidado.
    3. Se o ambiente de 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 do OpenSSH (sshd) não está em execução ou configurado corretamente. O sshd fornece acesso remoto seguro ao sistema com o protocolo SSH. Se ele estiver configurado incorretamente ou não estiver em execução, não será possível se conectar à VM usando SSH.

    Para resolver o problema, teste uma ou mais destas opções:

    • Consulte o guia do usuário do sistema operacional para conferir se sshd_config está configurado corretamente.

    • Verifique se você tem as configurações de propriedade e permissão necessárias para:

      • Os diretórios $HOME e $HOME/.ssh.
      • O arquivo $HOME/.ssh/authorized_keys.

      Propriedade

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

      Permissões

      O ambiente de convidado exige as seguintes permissões do Linux:

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

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

      Também é possível criar uma VM com base na mesma imagem e verificar as permissões padrão de $HOME.

      Para saber como mudar as permissões e a propriedade, leia sobre chmod e chown.

    • Execute este comando para reiniciar sshd:

      systemctl restart sshd.service

      Execute este comando para verificar se há erros no status:

      systemctl status sshd.service

      A saída do status pode conter informações como o código de saída, o motivo da falha etc. Use esses detalhes na solução de problemas.

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

    Para resolver o problema, teste uma ou mais destas opções:

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

    Propriedade

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

    Permissões

    O ambiente de convidado exige as seguintes permissões do Linux:

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

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

    Também é possível criar uma VM com base na mesma imagem e verificar as permissões padrão de $HOME.

    Para saber como mudar as permissões e a propriedade, leia sobre chmod e chown.

Falha na conexão

Os seguintes erros podem acontecer ao se conectar à VM usando o console doGoogle Cloud , a gcloud CLI, um Bastion Host ou um cliente local:

  • O console do Google Cloud :

    Connection Failed

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

  • A gcloud CLI:

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

  • Um Bastion Host ou um cliente local:

    port 22: Connection timed out.

    port 22: Connection refused

Esses erros podem acontecer por vários motivos. Confira abaixo algumas das causas mais comuns dos erros:

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

    Para resolver o problema, aguarde até que a VM seja inicializada e tente se conectar novamente.

  • sshd está sendo executado em uma porta personalizada. Se você tiver configurado sshd para ser executado em uma porta diferente da porta 22, não será possível estabelecer conexão com a VM.

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

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

    Para saber como criar regras de firewall personalizadas, consulte Como criar regras de firewall.

  • A regra de firewall de SSH está ausente ou não permite o 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 do tráfego de entrada TCP ou do IAP para o intervalo de IPs 0.0.0.0/0.

    Para resolver o problema, siga um destes procedimentos:

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

      1. Atualize a 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 o encaminhamento de TCP. Para mais informações, consulte Criar uma regra de firewall.
      2. Conceda permissões para usar o encaminhamento de TCP do IAP, se ainda não tiver feito isso.

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

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

  • 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, o que faz com que ela 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.

    Se você tiver criado um snapshot do disco de inicialização antes de fazer upgrade da VM, também será possível usar o snapshot para criar uma VM.

  • O Daemon do OpenSSH (sshd) não está em execução ou configurado corretamente. O sshd fornece acesso remoto seguro ao sistema com o protocolo SSH. Se ele estiver configurado incorretamente ou não estiver em execução, não será possível se conectar à VM usando SSH.

    Para resolver o problema, teste uma ou mais destas opções:

    • Consulte o guia do usuário do sistema operacional para conferir se sshd_config está configurado corretamente.

    • Verifique se você tem as configurações de propriedade e permissão necessárias para:

      • Os diretórios $HOME e $HOME/.ssh.
      • O arquivo $HOME/.ssh/authorized_keys.

      Propriedade

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

      Permissões

      O ambiente de convidado exige as seguintes permissões do Linux:

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

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

      Também é possível criar uma VM com base na mesma imagem e verificar as permissões padrão de $HOME.

      Para saber como mudar as permissões e a propriedade, leia sobre chmod e chown.

    • Execute este comando para reiniciar sshd:

      systemctl restart sshd.service

      Execute este comando para verificar se há erros no status:

      systemctl status sshd.service

      A saída do status pode conter informações como o código de saída, o motivo da falha etc. Use esses detalhes na solução de problemas.

  • A VM não está sendo inicializada e não é possível se conectar usando SSH ou o console serial. Se a VM está inacessível, o SO pode estar corrompido. Se o disco de inicialização não for inicializado, tente diagnosticar o problema. Para recuperar a VM corrompida e os dados, consulte Como recuperar uma VM corrompida ou um disco de inicialização cheio.

  • A VM está sendo inicializada no modo de manutenção. Ao ser inicializada no modo de manutenção, a VM não aceita conexões SSH, mas é possível se conectar ao console serial dela 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 '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 raiz.

Erro inesperado

O seguinte erro pode acontecer ao tentar se conectar a uma VM do 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 acontecer por vários motivos. Confira algumas causas comuns desse erro:

  • O Daemon do OpenSSH (sshd) não está em execução ou configurado corretamente. O sshd fornece acesso remoto seguro ao sistema com o protocolo SSH. Se ele estiver configurado incorretamente ou não estiver em execução, não será possível se conectar à VM usando SSH.

    Para resolver o problema, teste uma ou mais destas opções:

    • Consulte o guia do usuário do sistema operacional para conferir se sshd_config está configurado corretamente.

    • Verifique se você tem as configurações de propriedade e permissão necessárias para:

      • Os diretórios $HOME e $HOME/.ssh.
      • O arquivo $HOME/.ssh/authorized_keys.

      Propriedade

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

      Permissões

      O ambiente de convidado exige as seguintes permissões do Linux:

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

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

      Também é possível criar uma VM com base na mesma imagem e verificar as permissões padrão de $HOME.

      Para saber como mudar as permissões e a propriedade, leia sobre chmod e chown.

    • Execute este comando para reiniciar sshd:

      systemctl restart sshd.service

      Execute este comando para verificar se há erros no status:

      systemctl status sshd.service

      A saída do status pode conter informações como o código de saída, o motivo da falha etc. Use esses detalhes na solução de problemas.

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

    Dependendo da saída dos registros do console serial, faça o seguinte para tentar recuperar a VM e corrigir os problemas relacionados ao daemon SSH:

    1. Anexe o disco a outra VM do Linux.
    2. Conecte-se à VM em que o disco está montado.
    3. Monte o disco no SO em um diretório MOUNT_DIR na VM.
    4. Confira os registros relacionados ao SSH, /var/log/secure ou /var/log/auth.log, em busca de problemas ou erros. Se você encontrar algum problema que possa ser corrigido, tente corrigi-lo. Caso contrário, abra um caso de suporte e anexe os registros.

    5. Desconecte o disco do SO usando o comando umount:

      cd ~/
umount /mnt

    6. Desconecte o disco da VM.

    7. Anexe o disco à VM original.

    8. Inicie a VM.

Falha de conexão com o back-end

Os seguintes erros podem acontecer ao se conecta à VM usando o console doGoogle Cloud ou a gcloud CLI:

  • O console do Google Cloud :

    -- Connection via Cloud Identity-Aware Proxy Failed

-- Code: 4003

-- Reason: failed to connect to backend

  • A gcloud CLI:

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

Esses erros acontecem ao tentar usar SSH para se conectar a uma VM que não tem um endereço IP público e o Identity-Aware Proxy configurado na porta 22.

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

Chave do host sem correspondência

Este erro pode acontecer ao se conectar à VM:

Host key for server IP_ADDRESS does not match

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

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

O valor dos metadados é muito grande

O seguinte erro pode acontecer 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 minimizar essa limitação, siga um destes procedimentos:

Nenhum método de autenticação aceito está disponível

O seguinte erro pode acontecer ao se conectar à VM:

No supported authentication methods available (server sent: publickey,gssapi-keyex,gssapi-with-mic)

Esse erro acontece com mais frequência devido a um cliente SSH desatualizado. Os clientes SSH mais antigos podem não aceitar os tipos de chaves ECDSA e os algoritmos de hash SHA-2 exigidos por VMs mais recentes.

Por exemplo, esse erro acontece ao tentar se conectar a uma VM do Red Hat Enterprise Linux (RHEL) usando uma versão do PuTTY anterior à 0.75.

Para resolver o problema, atualize o cliente SSH para a versão estável mais recente. Depois de atualizar o cliente SSH, tente se conectar novamente.

Erros do Windows

Permissão negada. Tente novamente.

Este erro pode acontecer ao se conectar à VM:

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

Esse erro indica que o usuário que está tentando se conectar à VM não existe nela. Estas são algumas das causas mais comuns desse erro:

  • Sua versão da gcloud CLI está desatualizada.

    Quando a gcloud CLI está desatualizada, é possível que um nome de usuário não configurado seja usado para estabelecer a conexão. Para resolver o problema, atualize a gcloud CLI.

  • Você tentou se conectar a uma VM do Windows sem ativar o SSH.

    Para resolver o problema, defina a chave enable-windows-ssh como TRUE nos metadados do projeto ou da instância. Para saber como definir metadados, consulte Definir metadados personalizados.

Permissão negada (chave pública, interação por teclado)

Este erro pode acontecer ao se conectar a uma VM em que o SSH não está ativado:

Permission denied (publickey,keyboard-interactive).

Para resolver o problema, defina a chave enable-windows-ssh como TRUE nos metadados do projeto ou da instância. Para saber como definir metadados, consulte Definir metadados personalizados.

Não foi possível se conectar por SSH à instância

Este erro pode acontecer ao se conectar à VM usando a gcloud CLI:

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.

Esse erro pode acontecer por vários motivos. Confira abaixo algumas das causas mais comuns dos erros:

  • Você tentou se conectar a uma VM do Windows sem instalar o SSH.

    Para resolver o problema, siga as instruções para Ativar o SSH para o 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 com o protocolo SSH. Se ele estiver configurado incorretamente ou não estiver em execução, não será possível se conectar à VM usando SSH.

    Para resolver o problema, consulte Configuração do servidor SSH para Windows Server e Windows para conferir se sshd está configurado corretamente.

A conexão atingiu o tempo limite

Confira alguns motivos para conexões SSH que atingem o tempo limite:

  • A inicialização da VM não foi concluída. Aguarde algum tempo até que a VM seja inicializada.

    Para resolver o problema, aguarde até que a VM seja inicializada e tente se conectar novamente.

  • O pacote SSH não está instalado. Para se conectar por SSH às VMs do Windows, você precisa instalar o pacote google-compute-engine-ssh.

    Para resolver o problema, instale o pacote SSH.

Diagnosticar conexões SSH com falha

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

Antes de diagnosticar conexões SSH com falha, faça o seguinte:

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

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 fornece 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 conferir se a regra default-allow-ssh está presente.

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

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 exibir todos os dados associados à regra de firewall default-allow-ssh no 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 a conexão de rede

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

  1. Confira qual é 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 a que você não consegue se conectar.

  2. Na estação de trabalho, teste a conexão de rede com a VM:

    Linux, Windows 2019/2022 e macOS 

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

    Substitua:

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

    Se tudo der certo com o handshake TCP, a saída será parecida com 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 que tudo deu certo com o handshake TCP.

    Windows 2012 e 2016 

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

    Substitua:

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

    Se tudo der certo com o handshake TCP, a saída será parecida com 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 que tudo deu certo com o handshake TCP.

Se tudo der certo com o handshake TCP, uma regra de firewall de software não vai bloquear a conexão, o SO vai encaminhar pacotes corretamente e um servidor vai fazer detecções na porta de destino. Quando tudo dá certo com o handshake TCP, mas a VM não aceita conexões SSH, é possível que o daemon sshd esteja configurado ou sendo executado incorretamente. Consulte o guia do usuário do sistema operacional para conferir se o sshd_config está configurado corretamente.

Para executar testes de conectividade, analisar a configuração do caminho da 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, as permissões no arquivo ~/.ssh/authorized_keys da instância podem não estar definidas corretamente para o usuário.

Tente fazer login como um usuário diferente usando a gcloud CLI. Para isso, especifique ANOTHER_USERNAME com a solicitação SSH. A gcloud CLI vai 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.
  • VM_NAME é o nome da VM a que você quer se conectar.

Depurar problemas usando o console serial

Em caso de erros de conexão, recomendamos que você confira os registros do console serial. É possível acessá-lo como usuário raiz usando um navegador na estação de trabalho local. Isso é útil quando não é possível fazer login com SSH ou a instância não tem conexão com a rede. Nessas situações, ainda é possível acessar o console serial.

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 VMs do Linux, modifique a senha raiz e adicione o seguinte script de inicialização à VM: 

    echo root:PASSWORD | chpasswd

    Substitua PASSWORD por uma senha de sua escolha.

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

  4. Para VMs do Linux, após a depuração de todos os erros, desative o login com a conta raiz: 

    sudo passwd -l root

Métodos de diagnóstico para VMs do Linux

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, faça o seguinte:

  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 rede VPC para hospedar a instância clonada:

    gcloud compute networks create debug-network

    Substitua NETWORK_NAME pelo nome escolhido por você para a nova rede.

  2. Adicione uma regra de firewall para permitir conexões SSH com a 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 disco com o snapshot criado:

    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 VM usando um Bastion Host.

  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 a que você não consegue 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 um script de inicialização.

Depois, redefina a instância antes que os metadados entrem em vigor. Para isso, use gcloud 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 flag --keep-disks.

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

    Substitua VM_NAME pelo nome da VM a que você não consegue 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 sendo criada.
    • BOOT_DISK_NAME é o nome do disco de inicialização da VM a que 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.

Usar seu disco em uma nova instância

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

  1. Exclua a VM a que você não consegue 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 a que você não consegue se conectar.

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

  3. Conecte-se por SSH à nova VM:

    gcloud compute ssh NEW_VM_NAME

    Substitua NEW_VM_NAME pelo nome da nova VM.

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

A VM poderá 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 cheio. Para mais informações sobre esse cenário, consulte Como solucionar problemas de uma VM inacessível devido a um disco de inicialização cheio.

Métodos de diagnóstico para VMs do Windows

Redefinir metadados de SSH

Se não for possível se conectar por SSH a uma VM do Windows, desative a chave de metadados enable-windows-ssh e reative o SSH para Windows.

  1. Defina a chave de metadados de enable-windows-ssh como FALSE. Para saber como definir metadados, consulte Definir metadados personalizados.

    Aguarde alguns segundos para que a alteração seja aplicada.

  2. Reative o SSH para Windows.

  3. Reconecte-se à VM.

Conectar-se a uma VM usando o protocolo RDP

Se não for possível diagnosticar e resolver a causa das falhas de conexões SSH com a VM do Windows, conecte-se usando o protocolo RDP.

Depois de estabelecer uma conexão com a VM, analise os registros do OpenSSH.

A seguir