Conectar via SSH
O SSH é a forma padrão de administrar um servidor Linux remotamente. Esta página cobre o caminho completo: liberar o acesso no firewall, conectar de fato, e depois endurecer esse acesso para que ele não vire uma porta de entrada.
Não é preciso configurar nada para a instância ter um endereço público — ele é atribuído automaticamente na criação. O que impede a conexão, quase sempre, é o firewall.
Etapa 1 — Libere a porta 22 no firewall
Este é o passo que mais trava quem está começando. A VM está no ar, tem IP público, mas o Grupo de Segurança bloqueia todo o tráfego de entrada por padrão. Sem uma regra liberando a porta 22, o ssh fica tentando conectar e estoura em timeout — sem nenhuma mensagem que explique o motivo.
No portal, acesse Rede → Networks → Grupos de segurança, clique no grupo da sua instância e depois em + Adicionar regras. Preencha:
| Campo | Valor |
|---|---|
| Direção de tráfego | ingress |
| Descrição | SSH (texto livre, só para você identificar depois) |
| Protocolo | TCP |
| Porta aberta | 22 |
| Remoto | CIDR |
| CIDR | o seu IP com /32 — veja a recomendação de segurança abaixo |
Clique em Salvar. A regra passa a valer em segundos, sem precisar reiniciar a VM.
O guia completo dos Grupos de Segurança, com as capturas de tela do portal, está em Adicionando uma Regra de Firewall.
0.0.0.0/0 por comodidade0.0.0.0/0 significa "qualquer endereço da internet". Uma porta 22 aberta para o mundo começa a receber tentativas de login automatizadas em questão de minutos — é tráfego de varredura constante, não exceção. Prefira restringir ao seu IP, como explicado na seção de segurança.
Etapa 2 — Reúna os dados de acesso
| Item | Onde encontrar |
|---|---|
| Endereço IP | No card da instância ou na Visão Geral da VM |
| Usuário padrão | Depende do sistema: ubuntu no Ubuntu, root em várias imagens, almalinux / rocky nas respectivas distribuições |
| Autenticação | Chave SSH (recomendado) ou a senha definida na criação da instância |
Se você não souber o usuário da sua imagem, tente root e depois o nome da distribuição. O erro de usuário errado é explícito (Permission denied), diferente do erro de porta fechada (timeout).
Etapa 3 — Conecte
Com chave SSH (recomendado)
ssh -i /caminho/para/sua/chave-privada usuario@ip_da_instancia
Exemplo:
ssh -i ~/.ssh/minha-chave ubuntu@203.0.113.10
Se a chave tiver permissões abertas demais, o cliente SSH recusa usá-la. No Linux e no macOS, corrija com:
chmod 600 ~/.ssh/minha-chave
Com senha
ssh usuario@ip_da_instancia
Exemplo:
ssh root@203.0.113.10
Onde digitar
- Windows — PowerShell ou Prompt de Comando (o cliente SSH já vem instalado no Windows 10 e 11)
- macOS / Linux — o Terminal do sistema
Na primeira conexão o SSH exibe a impressão digital do servidor e pede confirmação. Digite yes — isso só acontece uma vez por servidor.
Recomendações de segurança
Conectar é a parte fácil. As duas mudanças abaixo reduzem bastante o risco de um servidor exposto, e nenhuma delas custa dinheiro.
1. Restrinja o acesso ao seu IP
Em vez de liberar a porta 22 para o mundo, libere só para o endereço de onde você realmente acessa. Na regra de firewall, troque o campo CIDR de 0.0.0.0/0 para SEU.IP.AQUI/32 — o sufixo /32 significa "exatamente este endereço, mais nenhum".
Para descobrir o seu IP público, acesse um site como ifconfig.me ou rode:
curl ifconfig.me
A maioria das conexões residenciais usa IP dinâmico: o endereço muda quando o modem reinicia ou por decisão da operadora. Se isso acontecer, a regra passa a bloquear você, e o acesso só volta pelo Console do portal, que não depende de SSH.
Se você não tem IP fixo, as alternativas são liberar a faixa da sua operadora (menos preciso, mas melhor que o mundo inteiro), usar uma VPN com IP de saída fixo, ou aceitar o 0.0.0.0/0 compensando com chave SSH obrigatória e senha desabilitada.
Se mais de uma pessoa acessa o servidor, crie uma regra por IP, cada uma com sua descrição. Fica mais fácil revogar o acesso de alguém depois.
2. Troque a porta padrão
A porta 22 é a primeira que qualquer varredura automatizada testa. Movê-la para algo como 10022 ou 11022 não torna o servidor invulnerável, mas elimina praticamente todo o ruído de ataque automatizado dos seus logs — o que faz as tentativas realmente direcionadas ficarem visíveis.
São duas mudanças, e a ordem importa:
Primeiro, abra a porta nova no firewall — repita a Etapa 1 com Porta aberta = 11022, mantendo a regra da 22 ainda ativa.
Depois, mude o servidor SSH da VM. Edite /etc/ssh/sshd_config:
sudo nano /etc/ssh/sshd_config
Localize a linha #Port 22, remova o # e troque o número:
Port 11022
Nas distribuições da família Red Hat — AlmaLinux, RockyLinux, CentOS e Fedora — o SELinux precisa autorizar a porta nova antes de reiniciar o serviço:
sudo semanage port -a -t ssh_port_t -p tcp 11022
Reinicie o serviço:
sudo systemctl restart sshd
Não feche o terminal em que você está conectado. Abra um segundo terminal e teste a porta nova:
ssh -p 11022 usuario@ip_da_instancia
Só depois que essa conexão funcionar você deve remover a regra da porta 22 e encerrar a sessão antiga. Se algo deu errado — erro de digitação no sshd_config, SELinux bloqueando — a sessão aberta é o que permite corrigir.
Se mesmo assim você perder o acesso, o Console do portal entra pela VM sem passar por SSH e resolve.
A partir daí, toda conexão precisa do -p:
ssh -p 11022 -i ~/.ssh/minha-chave ubuntu@203.0.113.10
3. Prefira chave a senha
Uma senha pode ser adivinhada por tentativa e erro; uma chave de 4096 bits, não. Se você configurou acesso por chave e confirmou que funciona, desabilite a autenticação por senha no /etc/ssh/sshd_config:
PasswordAuthentication no
Reinicie o sshd depois. Veja como gerar e cadastrar chaves em Chaves SSH.
Problemas Comuns
| Sintoma | Causa provável | Solução |
|---|---|---|
| A conexão fica travada e estoura em timeout | Porta não liberada no Grupo de Segurança | Adicione a regra de ingress TCP/22 — veja como |
Connection refused | A porta está liberada no firewall, mas o serviço SSH não está rodando na VM, ou está em outra porta | Acesse pelo Console e verifique com sudo systemctl status sshd |
Permission denied (publickey) | Chave errada, ou o servidor só aceita chave e você tentou senha | Confira o caminho em -i e o usuário; veja Chaves SSH |
Permission denied com senha | Usuário incorreto para a imagem | Tente root ou o nome da distribuição (ubuntu, almalinux, rocky) |
UNPROTECTED PRIVATE KEY FILE | Permissões da chave privada abertas demais | chmod 600 no arquivo da chave |
| Parou de conectar depois de trocar a porta | Firewall sem a regra da porta nova, ou SELinux bloqueando | Entre pelo Console e confira as duas coisas |
| Parou de conectar e nada foi alterado | Seu IP público mudou e a regra /32 não bate mais | Descubra o IP atual com curl ifconfig.me e atualize a regra |
Recursos Relacionados
- Chaves SSH — gerar, cadastrar e gerenciar chaves de acesso
- Grupos de Segurança — o guia completo do firewall, com prints do portal
- Acesso ao Console — entra na VM pelo navegador, sem SSH; é a saída quando você se tranca do lado de fora
- Conectar via RDP — para instâncias Windows
Você percorreu as quatro etapas do Guia de Início Rápido. Os próximos assuntos costumam ser Gerenciamento de Backups e Snapshots de Instância.