Como acessar SSH: guia prático para conectar em servidores Linux

SSH (Secure Shell) é o protocolo padrão pra administrar servidores Linux remotos. Se você acabou de provisionar uma VPS ou recebeu credenciais de acesso a um servidor, o primeiro passo é abrir uma sessão SSH — todo o resto (deploy, instalação de pacotes, configuração de serviços) depende disso funcionar.

Este tutorial cobre o caminho completo: conexão inicial com senha, geração e uso de chaves SSH, configuração do arquivo ~/.ssh/config pra simplificar comandos repetitivos, e resolução dos erros mais comuns que aparecem no primeiro acesso. O foco é uso prático em ambientes Linux e macOS, com observações pontuais pra Windows via OpenSSH nativo ou WSL.

Tempo estimado de execução: 15 a 25 minutos, incluindo geração de chaves e ajustes de configuração.

Pré-requisitos

Antes de tentar a conexão, confirme que você tem os dados de acesso do servidor e um cliente SSH disponível na sua máquina local.

Os dados típicos que você recebe ao contratar uma VPS são:

Guarde esses valores — você vai usá-los nos próximos passos. Se a senha veio por e-mail em texto plano, considere alterá-la na primeira conexão.

Primeira conexão via senha

O comando ssh segue o formato ssh usuario@host -p porta. Pra uma conexão básica com as credenciais do exemplo acima:

ssh [email protected]

ssh [email protected] -p 2222

The authenticity of host '203.0.113.42 (203.0.113.42)' can't be established.
ED25519 key fingerprint is SHA256:abc123...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

root@servidor:~#

Autenticação por chave SSH

Chaves SSH usam criptografia assimétrica: você gera um par (chave privada + chave pública), guarda a privada na sua máquina local e envia a pública pro servidor. A autenticação acontece sem nunca transmitir segredos pela rede.

Gerar o par de chaves

ssh-keygen -t ed25519 -C "[email protected]"

ssh-copy-id [email protected]

cat ~/.ssh/id_ed25519.pub | ssh [email protected] "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

ssh [email protected]

Configurando ~/.ssh/config

Digitar ssh [email protected] -p 2222 -i ~/.ssh/chave_especifica toda vez é cansativo. O arquivo ~/.ssh/config permite criar aliases por servidor.

nano ~/.ssh/config

Host producao
    HostName 203.0.113.42
    User root
    Port 22
    IdentityFile ~/.ssh/id_ed25519

Host staging
    HostName 198.51.100.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_staging

chmod 600 ~/.ssh/config

ssh producao

Endurecendo o acesso SSH

Com chave funcionando, o próximo passo é fechar o acesso por senha e ajustar o serviço SSH no servidor.

sudo nano /etc/ssh/sshd_config

PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes

sudo sshd -t

sudo systemctl reload ssh

Verificação

Confirme que tudo funciona como esperado:

ssh -v producao

O modo verbose (-v) mostra cada etapa: leitura do config, negociação de algoritmos, oferta de chaves. Procure por:

debug1: Authentication succeeded (publickey).

Isso confirma que a autenticação foi feita por chave, não por senha. Se aparecer password, alguma coisa não está aplicada.

Do lado do servidor, verifique tentativas recentes:

sudo journalctl -u ssh --since "10 minutes ago"

Você vê linhas tipo Accepted publickey for root from ... port ... ssh2.

Resolução de problemas

Permission denied (publickey)

A chave pública não está em ~/.ssh/authorized_keys no servidor, ou as permissões estão erradas. No servidor:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Verifique também se a chave correspondente está sendo oferecida pelo cliente — use ssh -v e procure por Offering public key.

Connection refused

O serviço SSH não está rodando, ou o firewall bloqueia a porta. No servidor:

sudo systemctl status ssh
sudo ss -tlnp | grep ssh

Se estiver ativo, confira o firewall (sudo ufw status ou as regras do provedor).

Connection timed out

Geralmente é problema de rede ou IP errado. Teste conectividade básica:

ping 203.0.113.42
nc -zv 203.0.113.42 22

Se nc falhar mas ping funcionar, a porta está bloqueada em algum ponto do caminho.

Host key verification failed

A fingerprint do servidor mudou desde a última conexão (servidor reinstalado, IP reciclado). Remova a entrada antiga:

ssh-keygen -R 203.0.113.42

E conecte novamente — o cliente vai pedir confirmação da nova fingerprint.

Próximos passos

Com SSH funcionando de forma segura, o servidor está pronto pra trabalho real. Algumas direções pra aprofundar:

• Configure fail2ban pra banir IPs com tentativas excessivas de autenticação.
• Use mosh em conexões instáveis (mobile, Wi-Fi ruim) — mantém a sessão viva mesmo com mudanças de rede.
• Aprenda port forwarding (ssh -L e ssh -R) pra acessar serviços internos do servidor sem expô-los à internet.
• Configure ssh-agent pra carregar a passphrase uma vez por sessão de trabalho.
• Estude Match blocks no sshd_config pra políticas diferentes por usuário ou rede.

Se você está colocando um projeto em produção e quer evitar dor de cabeça com SSH e firewall mal configurados, uma VPS Hostini já vem com SSH habilitado, IPv4 dedicado e acesso root imediato — basta seguir os passos deste tutorial a partir do e-mail de provisionamento.