Neste documento, descrevemos 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 o motivo da falha na conexão SSH. A ferramenta de solução de problemas realiza os testes a seguir para verificar a causa das conexões SSH com falha:
- Testes de permissões do usuário: verifica se você tem as permissões necessárias do IAM para se conectar à VM usando SSH.
- Testes de conectividade de rede: verifica se a VM está conectada à rede.
- Testes de status de instâncias de VM: verifica se o status da CPU da VM está em execução
- Testes de configurações de VPC: verifica a porta SSH padrão.
Executar a ferramenta de solução de problemas
É possível usar o Console do Google Cloud ou a CLI do Cloud para solucionar problemas de conexões SSH com falha nas VMs.
Console
Depois que uma conexão SSH falhar, você terá a opção de Tentar novamente ou Resolver problemas usando a ferramenta de solução de problemas do SSH no navegador.
Para executar essa ferramenta, clique em Resolver problemas.
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 pode se conectar.
A ferramenta solicita que você dê permissão para executar os testes de solução de problemas.
Analisar os resultados
Depois de executar a ferramenta de solução de problemas:
- Analise os resultados do teste para entender por que a conexão SSH da VM não está funcionando.
- Resolva conexões SSH executando as etapas de correção fornecidas pela ferramenta.
- Tente se reconectar à VM.
Erros comuns de SSH
Veja a seguir exemplos de erros comuns que podem ser encontrados ao usar o SSH para se conectar a VMs do Compute Engine.
Erros do Linux
Permissão negada (publickey)
O seguinte erro pode ocorrer quando você se conectar à VM:
USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).
Esse erro pode ocorrer por vários motivos. Estas são algumas das causas mais comuns desse erro:
Você usou uma chave SSH armazenada nos metadados para se conectar a uma VM que tem o login do SO ativado. Se o Login do SO estiver ativado no projeto, a VM não aceitará chaves SSH armazenadas nos metadados. Se você não tiver certeza se o Login do SO está ativado, consulte Como verificar se o Login do SO está configurado.
Para resolver esse problema, tente uma das seguintes opções:
- Conecte-se à VM usando o console do Google Cloud ou a Google Cloud CLI. Para mais informações, consulte Como se conectar a VMs.
- Adicione suas chaves SSH ao login do SO. Para mais informações, consulte Adicionar chaves a VMs que usam o Login do SO.
- Desative o Login do SO. Para mais informações, consulte Como desativar o Login do SO.
Você usou uma chave SSH armazenada em um perfil de login do SO para se conectar a uma VM que não tem o login do SO ativado. Se você desativar o login do SO, sua VM não aceitará chaves SSH armazenadas no perfil de login do SO. Se você não tiver certeza de que o Login do SO está ativado, consulte Como verificar se o Login do SO está configurado.
Para resolver esse problema, tente uma das seguintes opções:
- Conecte-se à VM usando o console do Google Cloud ou a Google Cloud CLI. Para mais informações, consulte Como se conectar a VMs.
- Ative o login do SO. Para mais informações, consulte Como ativar o login do SO.
- Adicione suas chaves SSH aos metadados. Para mais informações, consulte Adicionar chaves SSH a VMs que usam chaves SSH com base em metadados.
A VM tem o Login do SO ativado, mas você não tem permissões de IAM suficientes para usar esse recurso. Para se conectar a uma VM com o Login do SO ativado, você vai precisar das permissões necessárias. Se você não tiver certeza 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 de Login do SO necessários.
Sua chave expirou e o Compute Engine excluiu o arquivo
~/.ssh/authorized_keys
. Se você tiver adicionado manualmente as chaves SSH à VM e conectado a ela usando o console do Google Cloud, o Compute Engine criará um novo par de chaves para sua conexão. Depois que o novo par de chaves expirar, o Compute Engine excluirá o arquivo~/.ssh/authorized_keys
na VM, que incluiu a chave SSH adicionada manualmente.Para resolver esse problema, tente uma das seguintes opções:
- Conecte-se à VM usando o console do Google Cloud ou a Google Cloud CLI. Para mais informações, consulte Como se conectar a VMs.
- Adicione novamente sua chave SSH aos metadados. Para mais informações, consulte Adicionar chaves SSH a VMs que usam chaves SSH com base em metadados.
Você se conectou usando uma ferramenta de terceiros, e seu comando SSH está mal configurado. Se você se conectar usando o comando
ssh
, mas não especificar um caminho para a chave privada ou se especificar um caminho incorreto para a chave privada, a VM recusará a conexão.Para resolver esse problema, tente uma das seguintes opções:
- Execute este comando:
ssh -i PATH_TO_PRIVATE_KEY USERNAME@EXTERNAL_IP
Substitua:PATH_TO_PRIVATE_KEY
: o caminho para o arquivo da chave SSH particular.USERNAME
: o nome do usuário que se conecta à instância. Se você gerencia suas chaves SSH em metadados, o nome de usuário será aquele que você especificou quando criou a chave SSH. Em contas do Login do SO, o nome de usuário é definido no seu perfil do Google.EXTERNAL_IP
: o endereço IP externo da VM.
- Conecte-se à VM usando o console do Google Cloud ou a Google Cloud CLI. 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.
- Execute este comando:
O ambiente convidado da VM não está em execução. Se esta for a primeira vez que você está se conectando à VM e o ambiente de convidado não estiver em execução, a VM poderá recusar sua solicitação de conexão SSH.
Para resolver esse problema, faça o seguinte:
- Reinicie a VM.
- 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 mais informações, consulte Como validar o ambiente de convidado.
- Se o ambiente para convidado não estiver em execução, instale-o manualmente clonando o disco de inicialização da VM e usando um script de inicialização.
O daemon
sshd
não está em execução ou não está configurado corretamente. O daemonsshd
ativa conexões SSH. Se ela estiver configurada incorretamente ou não estiver em execução, não será possível se conectar à sua VM.Para resolver esse problema, tente o seguinte:
- Consulte o guia do usuário do seu sistema operacional para garantir que o
sshd_config
esteja configurado corretamente. Se você já tiver modificado as permissões da pasta na VM, altere-as para os padrões:
- 700 no diretório
.ssh
- 644 na chave pública, que é armazenada na pasta
~/.ssh/authorized_keys
Conecte-se ao console serial da VM como o usuário raiz e modifique as permissões da pasta:
chmod 700 /home/USERNAME/.ssh; chmod 644 /home/USERNAME/.ssh/authorized_keys
Substitua USERNAME pelo nome de usuário para o qual você quer modificar as permissões da pasta.
- 700 no diretório
- Consulte o guia do usuário do seu sistema operacional para garantir que o
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, tente uma ou mais destas opções:
- 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ê sabe quais arquivos estão consumindo 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
.
- Confirme se o disco de inicialização está cheio
depurando com o console serial para identificar
As permissões ou a propriedade em
$HOME
,$HOME/.ssh
ou$HOME/.ssh/authorized_keys
estão incorretas.Propriedade: o ambiente convidado armazena a chave SSH pública de um usuário no arquivo
$HOME/.ssh/authorized_keys
. O proprietário do diretório$HOME
, do diretório$HOME/.ssh
e do arquivoauthorized_keys
precisa ser o mesmo que o usuário se conecta à VM.Permissões do Unix: o ambiente convidado exige as seguintes permissões do Unix:
Diretório/Arquivo Permissão obrigatória para o Unix O diretório $HOME
0755
ou0700
O diretório $HOME/.ssh
0700
Arquivo authorized_keys
0600
Falha na conexão
Os seguintes erros podem ocorrer quando você se conecta à sua VM pelo console do Google Cloud ou pela CLI gcloud:
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].
Esses erros podem ocorrer por vários motivos. Veja a seguir algumas das causas mais comuns dos erros:
A VM está inicializando e
sshd
ainda não está em execução. Não é possível se conectar a uma VM antes da execução.Para resolver esse problema, aguarde a conclusão da inicialização da VM e tente se conectar novamente.
A regra de firewall que permite SSH não foi configurada ou está configurada incorretamente. Por padrão, as VMs do Compute Engine permitem acesso SSH na porta 22. Se a regra
default-allow-ssh
estiver ausente ou configurada incorretamente, não será possível se conectar a VMs.Para resolver esse problema, verifique suas regras de firewall e adicione ou reconfigure
default-allow-ssh
.sshd
está sendo executado em uma porta personalizada. Se você configurousshd
para ser executado em uma porta diferente da porta 22, não poderá se conectar à sua VM.Para resolver esse problema, crie uma regra de firewall personalizada que permita o tráfego
tcp
na porta em que osshd
está sendo executado usando o seguinte comando:gcloud compute firewall-rules create FIREWALL_NAME \ --allow tcp:PORT_NUMBER
Para mais informações sobre como criar regras de firewall personalizadas, consulte Como criar regras de firewall.
Sua regra de firewall SSH personalizada não permite o tráfego dos serviços do Google. As conexões SSH do console do Google Cloud serão recusadas se as regras de firewall personalizadas não permitirem conexões a partir do IAP ou do intervalo de endereços IP do Google.
Para resolver esse problema, faça uma das seguintes ações:
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.
- 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. - Conceda permissões para usar o encaminhamento de TCP do IAP, caso ainda não tenha feito isso.
- Atualize a regra de firewall personalizada para permitir o tráfego de
Se você não usa o IAP, atualize sua regra de firewall personalizada para permitir o tráfego de todo o intervalo de IP do Google.
- Atualize a regra de firewall personalizada para permitir o tráfego de endereços IP do Google. Para mais informações, consulte Como atualizar regras de firewall.
A conexão SSH falhou depois que você fez upgrade do kernel da VM. Uma VM pode sofrer um kernel panic após uma atualização do kernel, fazendo com que a VM fique inacessível.
Para resolver esse problema, faça o seguinte:
- Monte o disco em outra VM.
- Atualize o arquivo
grub.cfg
para usar a versão anterior do kernel. - Anexe o disco à VM sem resposta.
- Verifique se o status da VM é
RUNNING
usando o comandogcloud compute instances describe
. - Reinstale o kernel.
- Reinicie a VM.
Como alternativa, se você criou um snapshot do disco de inicialização antes de fazer upgrade da VM, use o snapshot para criar uma VM.
O daemon
sshd
não está em execução ou não está configurado corretamente. O daemonsshd
ativa conexões SSH. Se ela estiver configurada incorretamente ou não estiver em execução, não será possível se conectar à sua VM.Para resolver esse problema, tente o seguinte:
- Consulte o guia do usuário do seu sistema operacional para garantir que o
sshd_config
esteja configurado corretamente. Se você já tiver modificado as permissões da pasta na VM, altere-as para os padrões:
- 700 no diretório
.ssh
- 644 na chave pública, que é armazenada na pasta
~/.ssh/authorized_keys
Conecte-se ao console serial da VM como o usuário raiz e modifique as permissões da pasta:
chmod 700 /home/USERNAME/.ssh; chmod 644 /home/USERNAME/.ssh/authorized_keys
Substitua USERNAME pelo nome de usuário para o qual você quer modificar as permissões da pasta.
- 700 no diretório
- Consulte o guia do usuário do seu sistema operacional para garantir que o
A VM não está inicializando e não é possível se conectar usando SSH ou o console serial. Se a VM estiver inacessível, o sistema operacional poderá estar corrompido. Se o disco de inicialização não for inicializado, será possível diagnosticar o problema. Se você quiser recuperar a VM corrompida e recuperar dados, consulte Como recuperar uma VM corrompida ou um disco de inicialização completo.
A VM está sendo inicializada no modo de manutenção. Ao inicializar no modo de manutenção, a VM não aceita conexões SSH, mas é possível se conectar ao console serial da VM e fazer login como usuário raiz.
Para resolver esse problema, faça o seguinte:
Se você não tiver definido uma senha raiz para a VM, use um script de inicialização de metadados para executar o seguinte comando durante a inicialização:
echo "NEW_PASSWORD" | chpasswd
Substitua
NEW_PASSWORD
por uma senha de sua escolha.Reinicie a VM.
Conecte-se ao console serial da VM e faça login como o usuário raiz.
Falha ao conectar ao back-end
Os seguintes erros podem ocorrer quando você se conecta à sua VM pelo console do Google Cloud ou pela 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: u'failed to connect to backend'].
Esses erros ocorrem quando você tenta usar o SSH para se conectar a uma VM que não tem um endereço IP público e não configurou o Identity-Aware Proxy na porta 22.
Para resolver esse problema, crie uma regra de firewall na porta 22 que permita o tráfego de entrada do Identity-Aware Proxy.
A chave do host não corresponde
O seguinte erro pode ocorrer quando você se conectar à VM:
Host key for server IP_ADDRESS does not match
Esse erro ocorre quando a chave de host no arquivo ~/.ssh/known_hosts
não corresponde à de host da VM.
Para resolver esse problema, exclua a chave de host do arquivo ~/.ssh/known_hosts
e tente a conexão novamente.
O valor dos metadados é muito grande
O seguinte erro pode ocorrer quando você 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 de metadados têm um limite máximo de 256 KB. Para minimizar essa limitação, siga um destes procedimentos:
- Exclua as chaves SSH expiradas ou duplicadas dos metadados do projeto ou da instância. Para mais informações, consulte Atualizar metadados em uma VM em execução.
- Use o Login do SO.
Erros do Windows
Permissão negada. Tente novamente.
O seguinte erro pode ocorrer quando você 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 na VM. Estas são algumas das causas mais comuns desse erro:
Sua versão da CLI gcloud está desatualizada
Se a CLI gcloud estiver desatualizada, é possível que você esteja tentando se conectar usando um nome de usuário não configurado. Para resolver esse problema, atualize a CLI gcloud.
Você tentou se conectar a uma VM do Windows sem o SSH ativado.
Para resolver esse erro, defina a chave
enable-windows-ssh
comoTRUE
nos metadados do projeto ou da instância. Para mais informações sobre como definir metadados, consulte Definir metadados personalizados.
Permissão negada (publickey,keyboard-interactive)
O erro a seguir pode ocorrer quando você se conecta a uma VM que não tem o SSH ativado:
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 mais informações sobre como definir metadados, consulte
Definir metadados personalizados.
Não foi possível executar o SSH na instância
O erro a seguir pode ocorrer quando você se conecta à 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.
Esse erro pode ocorrer por vários motivos. Veja a seguir algumas das causas mais comuns dos erros:
Você tentou se conectar a uma VM do Windows sem o SSH instalado.
Para resolver esse problema, siga as instruções para Ativar o SSH para Windows em uma VM em execução.
O daemon
sshd
não está em execução ou não está configurado corretamente. O daemonsshd
ativa conexões SSH. Se ela estiver configurada incorretamente ou não estiver em execução, não será possível se conectar a uma VM.Para resolver esse problema, consulte Configuração do servidor SSH para Windows Server e Windows para garantir que
sshd
esteja configurado corretamente.
A conexão expirou
Conexões SSH expiradas podem ser causadas por um dos motivos a seguir:
A VM não terminou de ser inicializada. Aguarde um pouco para que a VM seja inicializada.
Para resolver esse problema, aguarde a conclusão da inicialização da VM e tente se conectar novamente.
O pacote SSH não está instalado. As VMs do Windows exigem que você instale o pacote
google-compute-engine-ssh
antes de se conectar usando SSH.Para resolver esse problema, instale o pacote SSH.
Diagnosticar conexões SSH com falha
Nas seções a seguir, veja as etapas para diagnosticar a causa das conexões SSH com falha e as etapas para corrigir as conexões.
Antes de diagnosticar conexões SSH com falha, conclua as seguintes etapas:
- Instale ou atualize para a versão mais recente da Google Cloud CLI.
- Executar testes de conectividade.
- Se você estiver usando uma imagem personalizada do Linux que não está executando o ambiente convidado, instale o ambiente de convidado do Linux.
- Se você usa o login do SO, consulte Solução de problemas de login do SO.
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 provisiona a cada projeto um conjunto padrão de regras de firewall que permitem o tráfego SSH. Se não for possível acessar a instância, use
a ferramenta de linha de comando gcloud compute
para
verificar a lista de firewalls
e garantir a presença da regra default-allow-ssh
.
Na estação de trabalho local, execute o comando a seguir:
gcloud compute firewall-rules list
Se você não encontrar a regra de firewall, adicione-a novamente:
gcloud compute firewall-rules create default-allow-ssh \ --allow tcp:22
Para visualizar todos os dados associados à regra de firewall default-allow-ssh
no seu
projeto, use o
comando gcloud compute firewall-rules describe
:
gcloud compute firewall-rules describe default-allow-ssh \ --project=project-id
Para mais informações sobre regras de firewall, consulte Regras de firewall no Google Cloud.
Testar conexão de rede
Para determinar se a conexão de rede está funcionando, teste o handshake TCP:
Consiga o
natIP
externo da VM:gcloud compute instances describe VM_NAME \ --format='get(networkInterfaces[0].accessConfigs[0].natIP)'
Substitua
VM_NAME
pelo nome da VM à qual você não pode se conectar.Teste a conexão de rede com a VM pela estação de trabalho:
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ê recebeu na etapa anterior;PORT_NUMBER
: o número da porta
Se o handshake TCP for bem-sucedido, a saída será semelhante a esta:
Expire in 0 ms for 6 (transfer 0x558b3289ffb0) Expire in 5000 ms for 2 (transfer 0x558b3289ffb0) Trying 192.168.0.4... TCP_NODELAY set Expire in 200 ms for 4 (transfer 0x558b3289ffb0) Connected to 192.168.0.4 (192.168.0.4) port 443 (#0) > GET / HTTP/1.1 > Host: 192.168.0.4:443 > User-Agent: curl/7.64.0 > Accept: */* > Empty reply from server Connection #0 to host 192.168.0.4 left intact
A linha
Connected to
indica um handshake de TCP bem-sucedido.Windows 2012 e 2016
PS C:> New-Object System.Net.Sockets.TcpClient('EXTERNAL_IP',PORT_NUMBER)
Substitua:
EXTERNAL_IP
: o IP externo que você recebeu na etapa anterior;PORT_NUMBER
: o número da porta
Se o handshake TCP for bem-sucedido, a saída será semelhante a esta:
Available : 0 Client : System.Net.Sockets.Socket Connected : True ExclusiveAddressUse : False ReceiveBufferSize : 131072 SendBufferSize : 131072 ReceiveTimeout : 0 SendTimeout : 0 LingerState : System.Net.Sockets.LingerOption NoDelay : False
A linha
Connected: True
indica um handshake de TCP bem-sucedido.
Se o handshake TCP for concluído com sucesso, uma regra de firewall de software não bloqueará a
conexão, o SO encaminhará pacotes corretamente e um
servidor fará detecções na porta de destino. Se o handshake TCP for concluído
com êxito, mas a VM não aceitar conexões SSH, o problema pode ser
com o daemon sshd
estar configurado incorretamente ou não ser executado corretamente. Consulte
o guia do usuário do seu sistema operacional para garantir que o sshd_config
esteja configurado corretamente.
Para executar testes de conectividade para analisar a configuração do caminho de rede VPC entre duas VMs e verificar se a configuração programada permite o tráfego, consulte Verificar se há regras de firewall configuradas incorretamente no Google Cloud.
Conectar-se como um usuário diferente
Talvez o problema que impeça você de fazer login esteja restrito à sua conta de usuário. Por exemplo, pode ser que as permissões no arquivo ~/.ssh/authorized_keys
da instância não estejam definidas corretamente para o usuário.
Tente fazer login como um usuário diferente com a CLI gcloud.
Para isso, especifique ANOTHER_USERNAME
com a solicitação SSH.
A CLI gcloud atualizará os metadados do projeto para adicionar o
novo usuário e permitir o acesso por SSH.
gcloud compute ssh ANOTHER_USERNAME@VM_NAME
Substitua:
ANOTHER_USERNAME
é um nome de usuário diferente do seu próprio nome de usuário;VM_NAME
é o nome da VM à qual você quer se conectar.
Depurar problemas usando o console serial
Recomendamos que você revise os registros do console serial para verificar se há erros de conexão. É possível acessar o console serial como usuário raiz na estação de trabalho local usando um navegador. Isso é útil quando não é possível fazer login com SSH ou quando a instância não tem conexão com a rede. O console serial ainda pode ser acessado em ambas as situações.
Para fazer login no console serial da VM e resolver problemas com ela, siga estas etapas:
Ative o acesso interativo ao console serial da VM.
Para VMs do Linux, modifique a senha raiz, adicione o seguinte script de inicialização à sua VM:
usermod -p $(echo "PASSWORD" | openssl passwd -1 -stdin) root
Substitua PASSWORD por uma senha de sua escolha.Use o console serial para se conectar à VM.
Para VMs do Linux, após concluir a depuração de todos os erros, desative o login da 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 backup do disco de inicialização criando um snapshot do disco.
- Crie um disco permanente regular a partir desse snapshot.
- Crie uma instância temporária.
- 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.
Crie uma nova rede VPC para hospedar a instância clonada:
gcloud compute networks create debug-network
Substitua
NETWORK_NAME
pelo nome escolhido para chamar a nova rede.Adicione uma regra de firewall para possibilitar conexões SSH à rede:
gcloud compute firewall-rules create debug-network-allow-ssh \ --network debug-network \ --allow tcp:22
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.Crie um novo disco com esse snapshot:
gcloud compute disks create example-disk-debugging \ --source-snapshot debug-disk-snapshot
Crie uma instância de depuração sem um endereço IP externo:
gcloud compute instances create debugger \ --network debug-network \ --no-address
Anexe o disco de depuração à instância:
gcloud compute instances attach-disk debugger \ --disk example-disk-debugging
Siga as instruções para conectar-se a uma instância sem um endereço IP externo.
Depois de fazer login na instância de depuração, solucione o problema nela. Por exemplo, analise os registros da instância:
sudo su -
mkdir /mnt/VM_NAME
mount /dev/disk/by-id/scsi-0Google_PersistentDisk_example-disk-debugging /mnt/VM_NAME
cd /mnt/VM_NAME/var/log
# Identify the issue preventing ssh from working ls
Substitua
VM_NAME
pelo nome da VM à qual você não pode se conectar.
Usar um script de inicialização
Se nenhuma das opções anteriores tiver ajudado, crie um script de inicialização para coletar informações logo após o início da instância. Siga as instruções para executar esse script.
Depois, também será necessário redefinir a instância antes que os metadados entrem em vigor. Para isso, use o comandogcloud compute instances reset
.
Como alternativa, é possível recriar a instância executando um script de inicialização de diagnóstico:
Execute
gcloud compute instances delete
com a sinalização--keep-disks
.gcloud compute instances delete VM_NAME \ --keep-disks boot
Substitua
VM_NAME
pelo nome da VM à qual você não pode se conectar.Adicione uma nova instância com o mesmo disco e especifique o script de inicialização.
gcloud compute instances create NEW_VM_NAME \ --disk name=BOOT_DISK_NAME,boot=yes \ --metadata startup-script-url URL
Substitua:
NEW_VM_NAME
é o nome da nova VM que você está criando;BOOT_DISK_NAME
é o nome do disco de inicialização da VM à qual não é possível se conectar;URL
é o URL do Cloud Storage para o script, no formatogs://BUCKET/FILE
ouhttps://storage.googleapis.com/BUCKET/FILE
.
Usar seu disco em uma instância nova
Se ainda for necessário recuperar dados do disco de inicialização permanente, desanexe-o e, em seguida, conecte-o como um disco secundário em uma nova instância.
Exclua a VM à qual não é possível se conectar e mantenha o disco de inicialização:
gcloud compute instances delete VM_NAME \ --keep-disks=boot
Substitua
VM_NAME
pelo nome da VM à qual você não pode se conectar.Crie uma nova 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.
Conecte-se à nova VM usando SSH:
gcloud compute ssh NEW_VM_NAME
Substitua
NEW_VM_NAME
pelo nome da nova VM.
Verifique se o disco de inicialização da VM está cheio
A VM pode ficar inacessível se o disco de inicialização estiver cheio. Esse cenário pode ser difícil de solucionar, porque nem sempre é óbvio quando o problema de conectividade da VM é devido a um disco de inicialização completo. Para mais informações sobre esse cenário, consulte Como solucionar problemas de uma VM inacessível devido a um disco de inicialização completo.
Métodos de diagnóstico para VMs do Windows
Redefinir metadados SSH
Se não for possível se conectar a uma VM do Windows usando SSH, desative a chave de metadados enable-windows-ssh
e reative o SSH para Windows.
Defina a chave de metadados
enable-windows-ssh
comoFALSE
. Para informações sobre como definir metadados, consulte Definir metadados personalizados.Aguarde alguns segundos para que a alteração seja aplicada.
Conecte-se à VM usando o RDP
Se não for possível diagnosticar e resolver a causa das falhas nas conexões SSH com sua VM do Windows, conecte-se usando o RDP.
Depois de estabelecer uma conexão com a VM, analise os registros do OpenSSH.
A seguir
- Saiba como as conexões SSH com VMs do Linux funcionam no Compute Engine.