Resolução de problemas de erros de SSH

Este documento descreve erros comuns que pode encontrar quando se liga a instâncias de máquinas virtuais (VM) através de SSH, formas de resolver erros e métodos para diagnosticar ligações SSH com falhas.

Ferramenta de resolução de problemas de SSH

Use a ferramenta de resolução de problemas de SSH para ajudar a determinar o motivo pelo qual uma ligação SSH falhou. A ferramenta de resolução de problemas executa os seguintes testes para verificar a causa das ligações SSH com falhas:

  • Testes de autorizações do utilizador: verifica se tem as autorizações de IAM necessárias para estabelecer ligação à VM através de SSH.
  • Testes de conetividade de rede: verifica se a VM está ligada à rede.
  • Testes de estado da instância de VM: verifica o estado da CPU da VM para ver se a VM está em execução.
  • Testes de definições da VPC: verifica a porta SSH predefinida.

Execute a ferramenta de resolução de problemas

Pode usar a Google Cloud consola ou a CLI Google Cloud para verificar se existem problemas de rede e erros de autorização do utilizador que possam fazer com que as ligações SSH falhem.

Consola

Depois de uma ligação SSH falhar, tem a opção de repetir a ligação ou resolver problemas da ligação através da ferramenta de resolução de problemas SSH no navegador.

Para executar a ferramenta de resolução de problemas, clique em Resolver problemas.

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

gcloud

Execute a ferramenta de resolução de problemas através do comando gcloud compute ssh:

gcloud compute ssh VM_NAME \
    --troubleshoot

Substitua VM_NAME pelo nome da VM à qual não consegue ligar-se.

A ferramenta pede-lhe autorização para realizar os testes de resolução de problemas.

Reveja os resultados

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

  1. Reveja os resultados do teste para compreender por que motivo a ligação SSH da VM não está a funcionar.
  2. Resolva as ligações SSH seguindo os passos de correção fornecidos pela ferramenta.

  3. Experimente voltar a estabelecer ligação à VM.

    Se a ligação não for bem-sucedida, experimente resolver os problemas manualmente fazendo o seguinte:

Erros de SSH comuns

Seguem-se exemplos de erros comuns que pode encontrar quando usa o SSH para se ligar a VMs do Compute Engine.

Erros de SSH no navegador

Erro 401 não autorizado

O seguinte erro pode ocorrer quando se liga à VM através do SSH no navegador a partir da Google Cloud consola:

Unauthorized
Error 401

Este erro ocorre se o seu utilizador fizer parte de uma organização que é gerida a partir do Google Workspace e existir uma restrição ativa na política do Workspace que impede os utilizadores de acederem ao SSH no navegador e à consola série no Google Cloud.

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

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

    Se Google Cloud estiver desativado, ative-o e tente novamente estabelecer a ligação.

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

    Se estes serviços estiverem desativados, ative-os e tente novamente estabelecer a ligação.

Se o problema persistir depois de ativar as Google Cloud definições no Google Workspace, faça o seguinte:

  1. Capte o tráfego de rede num ficheiro de formato de arquivo HTTP (HAR) a partir do momento em que inicia a ligação SSH no navegador.

  2. Crie um registo do Cloud Customer Care e anexe o ficheiro HAR.

Não foi possível estabelecer ligação. A tentar novamente…

O seguinte erro pode ocorrer quando inicia uma sessão SSH: 

Could not connect, retrying ...

Não foi possível estabelecer ligação. A tentar novamente

Para resolver este problema, faça o seguinte:

  1. Depois de a VM terminar o arranque, tente novamente a ligação. Se a ligação não for bem-sucedida, verifique se a VM não foi iniciada no modo de emergência executando o seguinte comando:

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

    Se a VM arrancar no modo de emergência, resolva os problemas do processo de arranque da VM para identificar onde o processo de arranque está a falhar.

  2. Verifique se o serviço google-guest-agent.serviceestá em execução executando o seguinte comando na consola série.

    systemctl status google-guest-agent.service

    Se o serviço estiver desativado, ative-o e inicie-o executando os seguintes comandos:

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

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

  4. Confirme que tem as funções necessárias para estabelecer ligação à VM. Se a sua VM usar o Início de sessão do SO, consulte o artigo Atribua a função IAM do Início de sessão do SO. Se a VM não usar o início de sessão no SO, precisa da função de administrador da instância de computação ou da função de utilizador 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 os metadados das chaves SSH da instância ou do projeto.

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

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

  6. Verifique se existe uma rota predefinida para a Internet (ou para o anfitrião bastion). Para mais informações, consulte o artigo Verificar trajetos.

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

  8. Certifique-se de que a VM não ficou 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, estabeleça ligação à consola série para resolver o problema.

Erros do Linux

Autorização recusada (chave pública)

Pode ocorrer o seguinte erro quando se liga à VM:

USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).

Este erro pode ocorrer por vários motivos. Seguem-se algumas das causas mais comuns deste erro:

  • Usou uma chave SSH armazenada em metadados para estabelecer ligação a uma VM com o Início de sessão do SO ativado. Se o início de sessão do SO estiver ativado no seu projeto, a VM não aceita chaves SSH armazenadas em metadados. Se não tiver a certeza de que o Início de sessão do SO está ativado, consulte o artigo Verificar se o Início de sessão do SO está configurado.

    Para resolver este problema, experimente uma das seguintes opções:

  • Usou uma chave SSH armazenada num perfil do Início de sessão do SO para estabelecer ligação a uma VM que não tem o Início de sessão do SO ativado. Se desativar o Início de sessão do SO, a sua VM não aceita chaves SSH que foram armazenadas no seu perfil do Início de sessão do SO. Se não tiver a certeza se o Início de sessão do SO está ativado, consulte Verificar se o Início de sessão do SO está configurado.

    Para resolver este problema, experimente uma das seguintes opções:

  • A VM tem o Início de sessão do SO ativado, mas não tem autorizações de IAM suficientes para usar o Início de sessão do SO. Para se ligar a uma VM com o Início de sessão do SO ativado, tem de ter as autorizações necessárias para o Início de sessão do SO. Se não tiver a certeza de que o Início de sessão do SO está ativado, consulte o artigo Verificar se o Início de sessão do SO está configurado.

    Para resolver este problema, conceda as funções de IAM de início de sessão no SO necessárias.

  • A sua chave expirou e o Compute Engine eliminou o ficheiro ~/.ssh/authorized_keys. Se adicionou manualmente chaves SSH à sua VM e, em seguida, estabeleceu ligação à VM através da Google Cloud consola, o Compute Engine criou um novo par de chaves para a sua ligação. Após a expiração do novo par de chaves, o Compute Engine eliminou o seu ficheiro ~/.ssh/authorized_keys na VM, que incluía a chave SSH adicionada manualmente.

    Para resolver este problema, experimente uma das seguintes opções:

  • Estabeleceu ligação através de uma ferramenta de terceiros e o seu comando SSH está mal configurado. Se se ligar através do comando ssh, mas não especificar um caminho para a chave privada ou especificar um caminho incorreto para a chave privada, a VM recusa a ligação.

    Para resolver este problema, experimente uma das seguintes opções:

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

      Substitua o seguinte:
      • PATH_TO_PRIVATE_KEY: o caminho para o ficheiro de chave SSH privada.
      • USERNAME: o nome de utilizador do utilizador que se está a ligar à instância. Se gerir as suas chaves SSH nos metadados, o nome de utilizador é o que especificou quando criou a chave SSH. Para contas de início de sessão do SO, o nome de utilizador é definido no seu perfil do Google.
      • EXTERNAL_IP: O endereço IP externo da sua VM.
    • Estabeleça ligação à sua VM através da Google Cloud consola ou da CLI Google Cloud. Quando usa estas ferramentas para estabelecer ligação, o Compute Engine gere a criação de chaves por si. Para mais informações, consulte o artigo Estabelecer ligação a VMs.

  • O ambiente convidado da VM não está em execução. Se esta for a primeira vez que se está a ligar à VM e o ambiente convidado não estiver em execução, a VM pode recusar o seu pedido de ligação SSH.

    Para resolver este problema, faça o seguinte:

    1. Reinicie a VM.
    2. Na Google Cloud consola, inspecione os registos de arranque do sistema na saída da porta série para determinar se o ambiente convidado está em execução. Para mais informações, consulte o artigo Validar o ambiente convidado.
    3. Se o ambiente convidado não estiver em execução, instale manualmente o ambiente convidado clonando o disco de arranque da VM e usando um script de arranque.

  • O daemon OpenSSH (sshd) não está em execução ou não está configurado corretamente. O sshd fornece acesso remoto seguro ao sistema através do protocolo SSH. Se estiver mal configurado ou não estiver em execução, não pode estabelecer ligação à VM através de SSH.

    Para resolver este problema, experimente uma ou mais das seguintes opções:

    • Reveja o guia do utilizador do seu sistema operativo para garantir que o sshd_config está configurado corretamente.

    • Certifique-se de que tem as definições de propriedade e autorização necessárias para o seguinte:

      • $HOME e $HOME/.ssh diretórios
      • Ficheiro $HOME/.ssh/authorized_keys

      Propriedade

      O ambiente convidado armazena chaves públicas de SSH autorizadas no ficheiro $HOME/.ssh/authorized_keys. O proprietário dos diretórios $HOME e $HOME/.ssh, e do ficheiro $HOME/.ssh/authorized_keys, tem de ser o mesmo que o utilizador que se liga à VM.

      Autorizações

      O ambiente convidado requer as seguintes autorizações do Linux:

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

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

      Em alternativa, pode criar uma nova VM com base na mesma imagem e verificar as respetivas autorizações predefinidas para $HOME.

      Para saber como alterar as autorizações e a propriedade, leia os artigos sobre chmod e chown.

    • Reinicie o sshd executando o seguinte comando:

      systemctl restart sshd.service

      Verifique se existem erros no estado executando o seguinte comando:

      systemctl status sshd.service

      O resultado do estado pode conter informações como o código de saída, o motivo da falha, etc. Pode usar estes detalhes para resolver problemas adicionais.

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

    Para resolver este problema, faça uma ou mais das seguintes ações:

    • Confirme se o disco de arranque está cheio depurando com a consola série para identificar no space left errors.
    • Redimensione o disco.
    • Se souber que ficheiros estão a usar o espaço no disco, crie um script de arranque que elimine ficheiros desnecessários e liberte espaço. Depois de iniciar a VM e estabelecer ligação à mesma, elimine os metadados startup-script.

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

    Propriedade

    O ambiente convidado armazena chaves públicas de SSH autorizadas no ficheiro $HOME/.ssh/authorized_keys. O proprietário dos diretórios $HOME e $HOME/.ssh, e do ficheiro $HOME/.ssh/authorized_keys, tem de ser o mesmo que o utilizador que se liga à VM.

    Autorizações

    O ambiente convidado requer as seguintes autorizações do Linux:

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

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

    Em alternativa, pode criar uma nova VM com base na mesma imagem e verificar as respetivas autorizações predefinidas para $HOME.

    Para saber como alterar as autorizações e a propriedade, leia os artigos sobre chmod e chown.

Ocorreu uma falha na ligação

Podem ocorrer os seguintes erros quando se liga à VM a partir da Google Cloud consola, da CLI gcloud, de um anfitrião de bastião ou de um cliente local:

  • A Google Cloud consola:

    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 bastion host ou um cliente local:

    port 22: Connection timed out.

    port 22: Connection refused

Estes erros podem ocorrer por vários motivos. Seguem-se algumas das causas mais comuns dos erros:

  • A VM está a arrancar e o sshd ainda não está em execução. Não pode estabelecer ligação a uma VM antes de esta estar em execução.

    Para resolver este problema, aguarde até que a VM tenha terminado de arrancar e tente estabelecer ligação novamente.

  • O sshd está a ser executado numa porta personalizada. Se configurou o sshd para ser executado numa porta diferente da porta 22, não vai conseguir estabelecer ligação à VM.

    Para resolver este problema, crie uma regra de firewall personalizada que permita o tráfego tcp na porta em que o sshd está a ser executado através do 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 o artigo Criar regras de firewall.

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

    Para resolver este problema, faça uma das seguintes ações:

    • Se usar o Identity-Aware Proxy (IAP) para o encaminhamento TCP, atualize a regra de firewall personalizada para aceitar tráfego do IAP e, em seguida, verifique as suas autorizações do IAM.

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

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

      1. Atualize a sua regra de firewall personalizada para permitir ligações SSH de entrada a VMs.

  • A ligação SSH falhou depois de atualizar o kernel da VM. Uma VM pode ter um kernel panic após uma atualização do kernel, o que faz com que a VM fique inacessível.

    Para resolver este problema, faça o seguinte:

    1. Monte o disco noutra MV.
    2. Atualize o ficheiro grub.cfg para usar a versão anterior do kernel.
    3. Anexe o disco à VM que não responde.
    4. Verifique se o estado da VM é RUNNING através do comando gcloud compute instances describe.
    5. Reinstale o kernel.
    6. Reinicie a VM.

    Em alternativa, se criou um instantâneo do disco de arranque antes de atualizar a VM, use o instantâneo para criar uma VM.

  • O daemon OpenSSH (sshd) não está em execução ou não está configurado corretamente. O sshd fornece acesso remoto seguro ao sistema através do protocolo SSH. Se estiver mal configurado ou não estiver em execução, não pode estabelecer ligação à VM através de SSH.

    Para resolver este problema, experimente uma ou mais das seguintes opções:

    • Reveja o guia do utilizador do seu sistema operativo para garantir que o sshd_config está configurado corretamente.

    • Certifique-se de que tem as definições de propriedade e autorização necessárias para o seguinte:

      • $HOME e $HOME/.ssh diretórios
      • Ficheiro $HOME/.ssh/authorized_keys

      Propriedade

      O ambiente convidado armazena chaves públicas de SSH autorizadas no ficheiro $HOME/.ssh/authorized_keys. O proprietário dos diretórios $HOME e $HOME/.ssh, e do ficheiro $HOME/.ssh/authorized_keys, tem de ser o mesmo que o utilizador que se liga à VM.

      Autorizações

      O ambiente convidado requer as seguintes autorizações do Linux:

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

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

      Em alternativa, pode criar uma nova VM com base na mesma imagem e verificar as respetivas autorizações predefinidas para $HOME.

      Para saber como alterar as autorizações e a propriedade, leia os artigos sobre chmod e chown.

    • Reinicie o sshd executando o seguinte comando:

      systemctl restart sshd.service

      Verifique se existem erros no estado executando o seguinte comando:

      systemctl status sshd.service

      O resultado do estado pode conter informações como o código de saída, o motivo da falha, etc. Pode usar estes detalhes para resolver problemas adicionais.

  • A VM não está a ser iniciada e não consegue estabelecer ligação através do SSH nem da consola série. Se a VM estiver inacessível, o SO pode estar corrompido. Se o disco de arranque não arrancar, pode diagnosticar o problema. Se quiser recuperar a VM danificada e obter dados, consulte o artigo Recuperar uma VM danificada ou um disco de arranque completo.

  • A VM está a ser iniciada no modo de manutenção. Quando arranca no modo de manutenção, a VM não aceita ligações SSH, mas pode ligar-se à consola série da VM e iniciar sessão como utilizador root.

    Para resolver este problema, faça o seguinte:

    1. Se não tiver definido uma palavra-passe de raiz para a VM, use um script de arranque de metadados para executar o seguinte comando durante o arranque:

      echo 'root:NEW_PASSWORD' | chpasswd

      Substitua NEW_PASSWORD por uma palavra-passe à sua escolha.

    2. Reinicie a VM.

    3. Estabeleça ligação à consola série da VM e inicie sessão como utilizador root.

Erro inesperado

Pode ocorrer o seguinte erro quando tenta estabelecer ligação 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.

Este problema pode ocorrer por vários motivos. Seguem-se algumas causas comuns do erro:

  • O daemon OpenSSH (sshd) não está em execução ou não está configurado corretamente. O sshd fornece acesso remoto seguro ao sistema através do protocolo SSH. Se estiver mal configurado ou não estiver em execução, não pode estabelecer ligação à VM através de SSH.

    Para resolver este problema, experimente uma ou mais das seguintes opções:

    • Reveja o guia do utilizador do seu sistema operativo para garantir que o sshd_config está configurado corretamente.

    • Certifique-se de que tem as definições de propriedade e autorização necessárias para o seguinte:

      • $HOME e $HOME/.ssh diretórios
      • Ficheiro $HOME/.ssh/authorized_keys

      Propriedade

      O ambiente convidado armazena chaves públicas de SSH autorizadas no ficheiro $HOME/.ssh/authorized_keys. O proprietário dos diretórios $HOME e $HOME/.ssh, e do ficheiro $HOME/.ssh/authorized_keys, tem de ser o mesmo que o utilizador que se liga à VM.

      Autorizações

      O ambiente convidado requer as seguintes autorizações do Linux:

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

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

      Em alternativa, pode criar uma nova VM com base na mesma imagem e verificar as respetivas autorizações predefinidas para $HOME.

      Para saber como alterar as autorizações e a propriedade, leia os artigos sobre chmod e chown.

    • Reinicie o sshd executando o seguinte comando:

      systemctl restart sshd.service

      Verifique se existem erros no estado executando o seguinte comando:

      systemctl status sshd.service

      O resultado do estado pode conter informações como o código de saída, o motivo da falha, etc. Pode usar estes detalhes para resolver problemas adicionais.

  • Problema desconhecido do daemon SSH. Para diagnosticar um problema desconhecido do daemon SSH, verifique os registos da consola série para ver se existem erros.

    Consoante a saída dos registos da consola série, tente recuperar a VM e corrigir os problemas relacionados com o daemon SSH fazendo o seguinte:

    1. Anexe o disco a outra VM do Linux.
    2. Ligue-se à VM que tem o disco montado.
    3. Monte o disco no SO num diretório MOUNT_DIR na VM.
    4. Veja os registos relacionados com SSH, /var/log/secure ou /var/log/auth.log para verificar se existem problemas/erros. Se vir problemas que pode corrigir, tente corrigi-los. Caso contrário, crie um registo de apoio ao cliente e anexe os registos.

    5. Desmonte o disco do SO através do comando umount:

      cd ~/
umount /mnt

    6. Desanexe o disco da VM.

    7. Anexe o disco à VM original.

    8. Inicie a VM.

Falha ao estabelecer ligação ao back-end

Podem ocorrer os seguintes erros quando se liga à VM a partir da consolaGoogle Cloud ou da CLI gcloud:

  • A Google Cloud consola:

    -- 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'].

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

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

A chave do anfitrião não corresponde

Pode ocorrer o seguinte erro quando se liga à VM:

Host key for server IP_ADDRESS does not match

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

Para resolver este problema, elimine a chave do anfitrião do ficheiro ~/.ssh/known_hosts e, em seguida, tente novamente a ligação.

O valor dos metadados é demasiado elevado

Pode ocorrer o seguinte erro quando tenta 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 dos metadados têm um limite máximo de 256 KB. Para mitigar esta limitação, efetue uma das seguintes ações:

Não estão disponíveis métodos de autenticação suportados

Pode ocorrer o seguinte erro quando se liga a uma VM:

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

Este erro ocorre mais frequentemente devido a um cliente SSH desatualizado. Os clientes SSH mais antigos podem não suportar os tipos de chaves ECDSA e os algoritmos de hash SHA-2 necessários pelas VMs mais recentes.

Por exemplo, este erro ocorre se tentar estabelecer ligação a uma VM do Red Hat Enterprise Linux (RHEL) através de uma versão do PuTTY anterior à 0.75.

Para resolver este erro, atualize o cliente SSH para a versão estável mais recente. Depois de atualizar o cliente SSH, tente novamente a ligação SSH.

Erros do Windows

Autorização recusada. Tente novamente.

Pode ocorrer o seguinte erro quando se liga à VM:

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

Este erro indica que o utilizador que está a tentar estabelecer ligação à VM não existe na VM. Seguem-se algumas das causas mais comuns deste erro:

  • A sua versão da CLI gcloud está desatualizada

    Se a CLI gcloud estiver desatualizada, pode estar a tentar estabelecer ligação com um nome de utilizador que não está configurado. Para resolver este problema, atualize a CLI gcloud.

  • Tentou estabelecer ligação a uma VM do Windows que não tem o SSH ativado.

    Para resolver este erro, defina a chave enable-windows-ssh como TRUE nos metadados do projeto ou da instância. Para mais informações sobre a definição de metadados, consulte o artigo Defina metadados personalizados.

Autorização recusada (publickey,keyboard-interactive)

O seguinte erro pode ocorrer quando se liga a uma VM que não tem o SSH ativado:

Permission denied (publickey,keyboard-interactive).

Para resolver este erro, defina a chave enable-windows-ssh como TRUE nos metadados do projeto ou da instância. Para mais informações sobre a definição de metadados, consulte o artigo Defina metadados personalizados.

Não foi possível estabelecer ligação SSH à instância

Pode ocorrer o seguinte erro quando se liga à VM a partir 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. Seguem-se algumas das causas mais comuns dos erros:

  • Tentou estabelecer ligação a uma VM do Windows que não tem o SSH instalado.

    Para resolver este problema, siga as instruções para ativar o SSH para Windows numa 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 através do protocolo SSH. Se estiver mal configurado ou não estiver em execução, não pode estabelecer ligação à VM através de SSH.

    Para resolver este problema, reveja a configuração do servidor OpenSSH para o Windows Server e o Windows para garantir que sshd está configurado corretamente.

A ligação excedeu o tempo limite

As ligações SSH com tempo limite excedido podem dever-se a um dos seguintes motivos:

  • A VM não terminou o arranque. Aguarde um pouco para que a VM seja iniciada.

    Para resolver este problema, aguarde até que a VM tenha terminado de arrancar e tente estabelecer ligação novamente.

  • O pacote SSH não está instalado. As VMs do Windows requerem a instalação do pacote google-compute-engine-ssh antes de poder estabelecer ligação através do SSH.

    Para resolver este problema, instale o pacote SSH.

Diagnostique falhas nas ligações SSH

As secções seguintes descrevem os passos que pode realizar para diagnosticar a causa das ligações SSH com falhas e os passos que pode realizar para corrigir as suas ligações.

Antes de diagnosticar ligações SSH com falhas, conclua os seguintes passos:

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

Teste a conetividade

Pode não conseguir estabelecer uma ligação SSH a uma instância de VM devido a problemas de conetividade relacionados com firewalls, a ligação de rede ou a conta de utilizador. Siga os passos nesta secção para identificar problemas de conetividade.

Verifique as regras de firewall

O Compute Engine aprovisiona cada projeto com um conjunto predefinido de regras de firewall que permitem o tráfego SSH. Se não conseguir aceder à sua instância, use a ferramenta de linha de comandos gcloud compute para verificar a sua lista de firewalls e certifique-se de que a regra default-allow-ssh está presente.

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

gcloud compute firewall-rules list

Se a regra de firewall estiver em falta, volte a adicioná-la:

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

Para ver 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 as regras de firewall, consulte o artigo Regras de firewall no Google Cloud.

Teste a ligação de rede

Para determinar se a ligação de rede está a funcionar, teste o handshake TCP:

  1. Obtenha o natIP externo para a sua VM:

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

    Substitua VM_NAME pelo nome da VM à qual não consegue estabelecer ligação.

  2. Teste a ligação de rede à VM a partir da sua 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 obteve no passo anterior
    • PORT_NUMBER: o número da porta

    Se o handshake TCP for bem-sucedido, o resultado é semelhante ao seguinte:

    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 estabelecimento de ligação TCP bem-sucedido.

    Windows 2012 e 2016 

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

    Substitua o seguinte:

    • EXTERNAL_IP: o IP externo que obteve no passo anterior
    • PORT_NUMBER: o número da porta

    Se o handshake TCP for bem-sucedido, o resultado é semelhante ao seguinte:

    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 estabelecimento de ligação TCP bem-sucedido.

Se o handshake TCP for concluído com êxito, significa que uma regra de firewall de software não está a bloquear a ligação, o SO está a encaminhar pacotes corretamente e um servidor está a ouvir na porta de destino. Se o handshake TCP for concluído com êxito, mas a VM não aceitar ligações SSH, o problema pode estar relacionado com o facto de o daemon sshd estar mal configurado ou não estar a ser executado corretamente. Reveja o guia do utilizador do seu sistema operativo para garantir que o sshd_config está configurado corretamente.

Para executar testes de conetividade para analisar a configuração do caminho da rede VPC entre duas VMs e verificar se a configuração programada deve permitir o tráfego, consulte o artigo Verifique se existem regras de firewall configuradas incorretamente no Google Cloud.

Estabeleça ligação como um utilizador diferente

O problema que impede o início de sessão pode estar limitado à sua conta de utilizador. Por exemplo, as autorizações no ficheiro ~/.ssh/authorized_keys na instância podem não estar definidas corretamente para o utilizador.

Experimente iniciar sessão como um utilizador diferente com a CLI gcloud especificando ANOTHER_USERNAME com o pedido SSH. A CLI gcloud atualiza os metadados do projeto para adicionar o novo utilizador e permitir o acesso SSH.

gcloud compute ssh ANOTHER_USERNAME@VM_NAME

Substitua o seguinte:

  • ANOTHER_USERNAME é um nome de utilizador diferente do seu
  • VM_NAME é o nome da VM à qual quer estabelecer ligação

Corrija problemas através da consola de série

Recomendamos que reveja os registos da consola série para verificar se existem erros de ligação. Pode aceder à consola série como utilizador root a partir da sua estação de trabalho local através de um navegador. Esta abordagem é útil quando não consegue iniciar sessão com SSH ou se a instância não tiver ligação à rede. A consola série permanece acessível em ambas as situações.

Para iniciar sessão na consola série da VM e resolver problemas com a VM, siga estes passos:

  1. Ative o acesso interativo à consola de série da VM.

  2. Para VMs do Linux, modifique a palavra-passe de raiz e adicione o seguinte script de arranque à sua VM: 

    echo root:PASSWORD | chpasswd

    Substitua PASSWORD por uma palavra-passe à sua escolha.

  3. Use a consola série para estabelecer ligação à sua VM.

  4. Para VMs do Linux, depois de terminar a depuração de todos os erros, desative o início de sessão da conta de raiz: 

    sudo passwd -l root

Métodos de diagnóstico para VMs Linux

Inspeção da instância de VM sem a encerrar

Pode ter uma instância à qual não consegue estabelecer ligação, mas que continua a publicar corretamente tráfego de produção. Neste caso, pode querer inspecionar o disco sem interromper a instância.

Para inspecionar e resolver problemas do disco:

  1. Faça uma cópia de segurança do disco de arranque criando um instantâneo do disco.
  2. Crie um disco persistente normal a partir desse instantâneo.
  3. Crie uma instância temporária.
  4. Anexe e monte o disco persistente normal à nova instância temporária.

Este procedimento cria uma rede isolada que só permite ligações SSH. Esta configuração evita quaisquer consequências não intencionais da instância clonada que interfiram com os seus serviços de produção.

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

    gcloud compute networks create debug-network

    Substitua NETWORK_NAME pelo nome que quer dar à sua nova rede.

  2. Adicione uma regra de firewall para permitir ligaçõ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 arranque.

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

    Substitua BOOT_DISK_NAME pelo nome do disco de arranque.

  4. Crie um novo disco com o instantâneo que 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 estabelecer ligação a uma VM através de um anfitrião bastion.

  8. Depois de iniciar sessão na instância do depurador, resolva os problemas da instância. Por exemplo, pode consultar os registos 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 não consegue estabelecer ligação.

Use um script de arranque

Se nenhuma das opções anteriores ajudou, pode criar um script de arranque para recolher informações imediatamente após o início da instância. Siga as instruções para executar um script de arranque.

Posteriormente, também tem de repor a instância antes de os metadados entrarem em vigor através de gcloud compute instances reset.

Em alternativa, também pode recriar a instância executando um script de início 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 à qual não consegue estabelecer ligação.

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

    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 está a criar
    • BOOT_DISK_NAME é o nome do disco de arranque da VM à qual não consegue estabelecer ligação
    • URL é o URL do Cloud Storage para o script, no formato gs://BUCKET/FILE ou https://storage.googleapis.com/BUCKET/FILE.

Use o disco numa nova instância

Se ainda precisar de recuperar dados do disco de arranque persistente, pode desassociar o disco de arranque e, em seguida, associá-lo como um disco secundário numa nova instância.

  1. Elimine a VM à qual não consegue estabelecer ligação e mantenha o respetivo disco de arranque:

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

    Substitua VM_NAME pelo nome da VM à qual não consegue estabelecer ligação.

  2. Crie uma nova VM com o disco de arranque da VM antiga. Especifique o nome do disco de arranque da VM que acabou de eliminar.

  3. Estabeleça ligação à nova VM através do SSH:

    gcloud compute ssh NEW_VM_NAME

    Substitua NEW_VM_NAME pelo nome da nova VM.

Verifique se o disco de arranque da VM está cheio

A sua VM pode ficar inacessível se o respetivo disco de arranque estiver cheio. Este cenário pode ser difícil de resolver, uma vez que nem sempre é óbvio quando o problema de conetividade da VM se deve a um disco de arranque cheio. Para mais informações sobre este cenário, consulte o artigo Resolução de problemas de uma VM inacessível devido a um disco de arranque cheio.

Métodos de diagnóstico para VMs do Windows

Reponha os metadados de SSH

Se não conseguir estabelecer ligação a uma VM do Windows através de SSH, experimente anular a definição da 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 o artigo Defina metadados personalizados.

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

  2. Reative o SSH para Windows

  3. Estabeleça novamente ligação à VM.

Estabeleça ligação à VM através do RDP

Se não conseguir diagnosticar e resolver a causa das ligações SSH falhadas à sua VM do Windows, estabeleça ligação através do RDP.

Depois de estabelecer uma ligação à VM, reveja os registos do OpenSSH.

What's Next?