Acessar sua VPS por SSH

SSH é o jeito padrão de operar uma VPS Linux: um shell remoto dentro de um canal cifrado. É por ele que você instala pacotes, edita configuração, lê logs e reinicia serviços. Se você acabou de criar o servidor em Criar sua primeira VPS, este é o próximo passo.

O que você precisa antes de começar

Três informações:

• O endereço do servidor. O IPv4 público (ou o IPv6, ou um nome DNS que aponte para ele). Ele aparece no painel, junto com os dados da máquina.
• O usuário. Em imagens Linux, quase sempre root. Algumas imagens criam um usuário comum com sudo — ubuntu, debian, almalinux — e desabilitam login direto como root.
• A credencial. Uma senha inicial ou, preferencialmente, uma chave SSH cuja parte pública foi instalada no servidor no momento da criação.

A porta padrão é a 22/TCP. Guarde isso: quase todo problema de conexão é uma questão de rota, porta ou credencial, nessa ordem.

Conectar do Linux ou do macOS

O cliente OpenSSH já vem instalado nos dois. No terminal:

ssh root@203.0.113.10

Se o usuário for outro, troque antes do @. Se a chave que você quer usar não é a padrão (~/.ssh/id_ed25519 ou ~/.ssh/id_rsa), aponte para ela:

ssh -i ~/.ssh/easyops_ed25519 root@203.0.113.10

A primeira conexão e o fingerprint

Na primeira vez, o cliente mostra:

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

Isso não é erro. O cliente nunca viu esse servidor e está pedindo que você confirme a identidade dele. O jeito correto de confirmar é comparar esse fingerprint com o que o próprio servidor reporta pelo console no browser, executando lá dentro:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Se bater, responda yes. A chave vai para ~/.ssh/known_hosts e nas próximas conexões a checagem é automática. Aceitar sem comparar funciona, mas abre uma janela para interceptação na primeira conexão.

Conectar do Windows

Duas pegadinhas. O PuTTY não lê chaves no formato OpenSSH: converta com o PuTTYgen ou gere a chave já no formato dele. E no OpenSSH nativo as chaves ficam em C:\Users\<você>\.ssh\ — a privada precisa estar legível somente pelo seu usuário, ou o cliente recusa usá-la.

Se a sua VPS é Windows, o caminho normal é RDP e não SSH, como explicado em Linux ou Windows: qual escolher.

Chave em vez de senha

Senha em porta 22 aberta na internet recebe força bruta em minutos. Chave elimina essa classe de ataque. Gere o par no seu computador:

ssh-keygen -t ed25519 -C "notebook-crystian"

Aceite o caminho sugerido e defina uma passphrase — ela protege a chave privada caso o notebook seja perdido. Depois, instale a parte pública no servidor:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10

O comando só funciona se você ainda tiver login por senha. Se não tiver, use o console no browser e acrescente a linha da chave pública a ~/.ssh/authorized_keys do usuário. O passo a passo, incluindo como desligar a autenticação por senha sem se trancar fora, está em Usar chaves SSH em vez de senha.

Encurtar o comando

Digitar IP e usuário toda vez convida a erro. Crie ~/.ssh/config no seu computador:

Host app
  HostName 203.0.113.10
  User root
  IdentityFile ~/.ssh/easyops_ed25519
  ServerAliveInterval 30

Agora ssh app basta. O ServerAliveInterval manda um pacote a cada 30 segundos e evita que a sessão morra sozinha quando você fica um tempo sem digitar.

Quando a conexão é recusada

Leia a mensagem exata. Cada uma aponta para uma camada diferente do problema.

Para ver o que está acontecendo por baixo, repita a conexão em modo verboso:

ssh -vvv root@203.0.113.10

A saída mostra até onde você foi: se o TCP nem estabeleceu, o problema é rede; se estabeleceu e falhou depois de Offering public key, é credencial.

Timeout com IP certo quase sempre é regra de firewall. Confira o que está liberado na entrada seguindo Configurar regras de firewall — e lembre do ufw de dentro da máquina, camada independente e igualmente capaz de te bloquear.

No caso do host key mudado, remova a entrada antiga e confirme o novo fingerprint pelo console antes de aceitar:

ssh-keygen -R 203.0.113.10

Só faça isso se você souber por que a chave mudou. Se ninguém reinstalou nem restaurou nada, trate como incidente e fale com o suporte.

Se você se trancou fora

Acontece: uma regra de firewall errada, PasswordAuthentication no sem chave funcionando, um AllowUsers restritivo demais. O console no browser não passa pela porta 22 nem pelo sshd, então continua funcionando quando o SSH não. Use ele para desfazer a mudança.

Antes de mexer em /etc/ssh/sshd_config, valide a sintaxe e mantenha a sessão atual aberta:

sudo sshd -t && sudo systemctl reload sshd

O sshd -t recusa arquivo inválido em vez de derrubar o serviço, e o reload não corta sessões já estabelecidas. Abra uma segunda conexão para testar antes de fechar a primeira. Se a mudança é maior que isso, tire um snapshot primeiro — o raciocínio está em Snapshot antes de uma mudança arriscada.