Neste documento, descrevemos erros comuns que você pode encontrar ao se conectar a instâncias de máquina virtual (VM) do Linux usando SSH, maneiras de resolver erros e métodos para diagnosticar conexões SSH com falha.
Erros comuns de SSH
Veja a seguir exemplos de erros comuns que podem ser encontrados ao usar o SSH para se conectar a VMs do Compute Engine.
Permissão recusada
O seguinte erro pode ocorrer quando você se conectar à VM:
USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).
Esse erro pode ocorrer por vários motivos. Estas são algumas das causas mais comuns desse erro:
Você usou uma chave SSH armazenada nos metadados para se conectar a uma VM que tem o login do SO ativado. Se o Login do SO estiver ativado no projeto, a VM não aceitará chaves SSH armazenadas nos metadados.
Para resolver esse problema, tente uma das seguintes opções:
- Conecte-se à VM usando o Console do Google Cloud ou a ferramenta de linha de comando
gcloud
. Para mais informações, consulte Como se conectar a VMs. - Adicione suas chaves SSH ao login do SO. Para mais informações, consulte Como adicionar chaves SSH a uma conta de usuário.
- Desative o Login do SO. Para mais informações, consulte Como desativar o Login do SO.
- Conecte-se à VM usando o Console do Google Cloud ou a ferramenta de linha de comando
Você usou uma chave SSH armazenada em um perfil de login do SO para se conectar a uma VM que não tem o login do SO ativado. Se você desativar o login do SO, sua VM não aceitará chaves SSH armazenadas no perfil de login do SO.
Para resolver esse problema, tente uma das seguintes opções:
- Conecte-se à VM usando o Console do Google Cloud ou a ferramenta de linha de comando
gcloud
. 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 Como editar metadados de chave SSH pública.
- Conecte-se à VM usando o Console do Google Cloud ou a ferramenta de linha de comando
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 ferramenta de linha de comando
gcloud
. Para mais informações, consulte Como se conectar a VMs. - Adicione novamente sua chave SSH aos metadados. Para mais informações, consulte Como editar metadados de chave SSH pública.
- Conecte-se à VM usando o Console do Google Cloud ou a ferramenta de linha de comando
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 privada.USERNAME
: o nome do usuário que se conecta à instância. Se você gerencia suas chaves SSH em metadados, o nome de usuário será aquele que você especificou quando criou a chave SSH. Em contas do Login do SO, o nome de usuário é definido no seu perfil do Google.EXTERNAL_IP
: o endereço IP externo da VM.
- Conecte-se à VM usando o Console do Google Cloud ou a ferramenta de linha de comando
gcloud
. Quando você usa essas ferramentas para se conectar, o Compute Engine gerencia a criação da chave para você. Para mais informações, consulte Como se conectar a VMs.
- Execute este comando:
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, consulte o guia do usuário do seu sistema operacional para garantir que seu
sshd_config
esteja configurado corretamente.
Falha na conexão
Os seguintes erros podem ocorrer quando você se conecta à sua VM pelo
Console do Google Cloud ou pela ferramenta gcloud
:
O Console do Cloud:
Connection Failed We are unable to connect to the VM on port 22.
A ferramenta
gcloud
:ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].
Esses erros podem ocorrer por vários motivos. Veja a seguir algumas das causas mais comuns dos erros:
A VM está inicializando e
sshd
ainda não está em execução. Não é possível se conectar a uma VM antes da execução.Para resolver esse problema, aguarde a conclusão da inicialização da VM e tente se conectar novamente.
A regra de firewall que permite SSH não foi configurada ou está configurada incorretamente. Por padrão, as VMs do Compute Engine permitem acesso SSH na porta 22. Se a regra
default-allow-ssh
estiver ausente ou configurada incorretamente, não será possível se conectar a VMs.Para resolver esse problema, verifique suas regras de firewall e adicione ou reconfigure
default-allow-ssh
.sshd
está sendo executado em uma porta personalizada. Se você 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 Cloud serão recusadas se as regras de firewall personalizadas não permitirem conexões a partir do intervalo de endereços IP do Google.
Para resolver esse problema, faça o seguinte:
Reúna os intervalos de endereços IP do Google executando o seguinte comando:
dig +qr +short txt `dig +short TXT _spf.google.com | grep -oE 'include:\S*' | cut -d':' -f2 | xargs` | grep -oE 'ip[46]:\S*' | sort | uniq
Atualize sua regra de firewall personalizada para permitir o tráfego de endereços IP do Google. Para mais informações, consulte Como atualizar regras de firewall.
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, consulte o guia do usuário do seu sistema operacional para garantir que seu
sshd_config
esteja configurado corretamente.
Falha ao conectar ao back-end
Os seguintes erros podem ocorrer quando você se conecta à sua VM pelo
Console do Google Cloud ou pela ferramenta gcloud
:
O Console do Cloud:
-- Connection via Cloud Identity-Aware Proxy Failed -- Code: 4003 -- Reason: failed to connect to backend
A ferramenta
gcloud
:ERROR: (gcloud.compute.start-iap-tunnel) Error while connecting [4003: u'failed to connect to backend'].
Esses erros ocorrem quando você tenta usar o SSH para se conectar a uma VM que não tem um endereço IP público e não configurou o Identity-Aware Proxy na porta 22.
Para resolver esse problema, crie uma regra de firewall na porta 22 que permita o tráfego de entrada do Identity-Aware Proxy.
Como diagnosticar conexões SSH com falha
Nas seções a seguir, veja as etapas para diagnosticar a causa das conexões SSH com falha e as etapas para corrigir as conexões.
Antes de diagnosticar conexões SSH com falha, conclua as seguintes etapas:
- Instale a ferramenta de linha de comando
gcloud
ou atualize-a para a versão mais recente. - Executar testes de conectividade.
- Se você estiver usando uma imagem personalizada 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.
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, use a ferramenta nmap
para se conectar à instância da porta 22. Se você conseguir se conectar e vir
22/tcp open ssh
, significará que a conexão de rede está funcionando e é possível
descartar os problemas de firewall.
Use a ferramenta
gcloud
para receber onatIP
externo da instância: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 instância.
Execute o comando
nmap
para testar a conexão de rede com sua instância, substituindoexternal-ip
pelo IP externo recebido na etapa 1:nmap external-ip
Por exemplo, se a instância tiver o IP externo
198.51.100.1
, execute o comando a seguir:nmap 198.51.100.1
Starting Nmap 7.70 ( https://nmap.org ) at 2019-03-18 16:04 Greenwich Standard Time Nmap scan report for 229.30.196.35.bc.googleusercontent.com (198.51.100.1) Host is up (0.0061s latency). Not shown: 998 filtered ports PORT STATE SERVICE 22/tcp open ssh Nmap done: 1 IP address (1 host up) scanned in 6.22 seconds
Conectar-se como um usuário diferente
Talvez o problema que impeça você de fazer login esteja restrito à sua conta de usuário. Por exemplo, pode ser que as permissões no arquivo ~/.ssh/authorized_keys
da instância não estejam definidas corretamente para o usuário.
Tente fazer login como um usuário diferente com a ferramenta gcloud
.
Para isso, especifique ANOTHER_USERNAME
com a solicitação SSH.
A ferramenta gcloud
atualizará os metadados do projeto para adicionar o
novo usuário e permitir o acesso por SSH.
gcloud compute ssh ANOTHER_USERNAME@VM_NAME
Substitua:
ANOTHER_USERNAME
é um nome de usuário diferente do seu próprio nome de usuário;VM_NAME
é o nome da VM à qual você quer se conectar.
Depurar o problema no 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 na sua estação de trabalho local usando um navegador.
Ative o acesso de leitura e gravação ao console serial de uma instância para que você consiga fazer login no console e solucionar os problemas nela. Isso é útil quando não é possível fazer login com SSH ou quando a instância não tem conexão com a rede. Ainda é possível acessar o console serial em ambas as situações.
Para aprender como ativar o acesso interativo e se conectar ao console serial de uma instância, consulte Como interagir com o console serial.
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
.
Como ponto de partida, use o script compute-ssh-diagnostic (em inglês) para coletar informações de diagnóstico dos problemas mais comuns.
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:
gcloud compute instances create NEW_VM_NAME \ --disk name=BOOT_DISK_NAME,boot=yes,auto-delete=no
Substitua:
NEW_VM_NAME
é o nome da nova VM que você está criando;BOOT_DISK_NAME
é o nome do disco de inicialização da VM à qual não é possível se conectar.
Conecte-se à nova VM usando SSH:
gcloud compute ssh NEW_VM_NAME
Substitua
NEW_VM_NAME
pelo nome da nova VM.
A seguir
- Saiba como as conexões SSH com VMs do Linux funcionam no Compute Engine.