{
  "schemaVersion": "1.0",
  "path": "/guias/vps/ssh-seguro-vps-linux",
  "url": "https://streethosting.com.br/guias/vps/ssh-seguro-vps-linux",
  "markdownUrl": "https://streethosting.com.br/guias/vps/ssh-seguro-vps-linux.md",
  "jsonUrl": "https://streethosting.com.br/guias/vps/ssh-seguro-vps-linux.json",
  "title": "SSH seguro em VPS Linux: chaves, senhas, fail2ban e hábitos que evitam invasão",
  "description": "Endurecimento SSH em servidor público: ED25519, PermitRootLogin, PasswordAuthentication, AllowUsers, fail2ban e relação com firewall UFW.",
  "category": "vps",
  "topics": [
    "seguranca",
    "linux"
  ],
  "difficulty": "intermediario",
  "datePublished": "2026-05-19",
  "dateModified": "2026-05-20",
  "readingMinutes": 4,
  "series": {
    "id": "vps-fundamentos",
    "order": 2
  },
  "h1": "SSH seguro em VPS Linux",
  "excerpt": "SSH costuma ser o primeiro alvo em qualquer VPS com IP público. Este guia mostra um fluxo prático para reduzir risco sem complicar a rotina: chave ED25519, login sem senha, acesso administrativo com sudo, bloqueio de tentativas automáticas e revisão periódica de chaves autorizadas.",
  "author": "Equipe StreetHosting",
  "wordCount": 610,
  "categoryLabel": "VPS",
  "topicLabels": [
    "Segurança e hardening",
    "Administração Linux"
  ],
  "primaryKeyword": "ssh seguro vps linux",
  "secondaryKeywords": [
    "chave ssh ed25519",
    "fail2ban ubuntu",
    "desabilitar senha ssh"
  ],
  "toc": [
    {
      "id": "modelo-de-ameaca-realista",
      "label": "Modelo de ameaça realista"
    },
    {
      "id": "chaves-ed25519-e-agent-forwarding",
      "label": "Chaves ED25519 e agent forwarding"
    },
    {
      "id": "sshd-config-minimo-saudavel",
      "label": "sshd_config mínimo saudável"
    },
    {
      "id": "fail2ban-e-rate-limit",
      "label": "fail2ban e rate limit"
    },
    {
      "id": "operacao-e-auditoria",
      "label": "Operação e auditoria contínua"
    }
  ],
  "faqs": [
    {
      "question": "Mudar porta SSH ajuda?",
      "answer": "Ajuda a reduzir ruído de bots simples, mas não resolve o problema principal. Segurança real vem de chave forte, senha remota desativada e controle de usuários permitidos."
    },
    {
      "question": "Posso manter senha para emergência?",
      "answer": "O caminho mais seguro é usar console de recuperação do provedor e uma política clara de chaves. Se senha for obrigatória por algum motivo, limite acesso por VPN ou faixa de IP específica."
    },
    {
      "question": "fail2ban pode bloquear IP legítimo?",
      "answer": "Sim em NAT corporativo compartilhado. Ajuste findtime, maxretry e whitelist de IPs estáveis da sua equipe."
    },
    {
      "question": "2FA no SSH existe?",
      "answer": "Existe, normalmente por módulos PAM ou bastion com MFA. Vale bastante para times maiores ou ambientes com dados sensíveis, mas exige processo de suporte mais bem definido."
    }
  ],
  "howToSteps": [],
  "relatedProducts": [
    "https://streethosting.com.br/vps/ryzen",
    "https://streethosting.com.br/dedicated"
  ],
  "relatedGuides": [
    "https://streethosting.com.br/guias/vps/firewall-ufw-vps-ubuntu",
    "https://streethosting.com.br/guias/vps/instalar-docker-ubuntu-vps",
    "https://streethosting.com.br/guias/vps/vps-ryzen-vs-vps-xeon"
  ],
  "content": {
    "format": "markdown",
    "body": "> **Resposta rápida**\n>\n> Para endurecer SSH em VPS Linux, o caminho mais seguro é: gerar chave **ED25519**, validar login por chave em uma segunda sessão, desativar senha remota no `sshd_config`, proibir login root direto, permitir apenas usuários necessários e adicionar **fail2ban** junto com firewall coerente. Use este fluxo em etapas para evitar se bloquear fora do servidor.\n\n## Modelo de ameaça realista\n\nEm uma VPS nova, o padrão é receber tentativas de login automáticas poucos minutos após expor o IP. A maior parte desses ataques usa listas de usuário e senha vazadas. O objetivo não é criar uma configuração perfeita em teoria, e sim remover os vetores que mais aparecem em produção.\n\n### O que costuma acontecer na prática\n\n- Bots testam combinações comuns como root, admin e ubuntu sem parar.\n- Chaves antigas permanecem em `authorized_keys` após troca de equipe.\n- Serviço com permissão excessiva facilita movimentação lateral após invasão.\n\n## Chaves ED25519 e agent forwarding\n\nCrie uma chave por pessoa e por dispositivo. Isso simplifica auditoria e revogação quando alguém sai da equipe ou perde um notebook. Em ambiente pequeno, essa organização já evita boa parte dos incidentes operacionais.\n\n1. Gere a chave com passphrase forte no dispositivo de uso diário.\n2. Copie apenas a chave pública para o servidor e confira permissões do diretório `.ssh`.\n3. Teste login em sessão paralela antes de qualquer alteração de política.\n\n> **Dica**\n>\n> Agent forwarding deve ser exceção. Para saltos entre hosts, prefira ProxyJump quando possível por ser mais previsível em auditoria.\n\n## sshd_config mínimo saudável\n\n| Diretiva | Valor sugerido | Motivo |\n| --- | --- | --- |\n| PasswordAuthentication | no | Elimina ataque por senha remota |\n| PermitRootLogin | no ou prohibit-password | Administração com sudo |\n| PubkeyAuthentication | yes | Método principal de autenticação |\n| AllowUsers | lista explícita | Reduz exposição desnecessária |\n\nFaça backup do arquivo antes de editar, valide com `sshd -t` e só reinicie o serviço depois de confirmar que a sintaxe está correta. Em VPS, essa validação simples evita perda de acesso por erro de digitação.\n\n> **Atenção**\n>\n> Nunca feche sua sessão atual antes de abrir e validar uma nova conexão SSH com as regras recém aplicadas.\n\n## fail2ban e rate limit\n\nO fail2ban observa falhas repetidas e bloqueia IPs por um período definido. Ele não substitui autenticação por chave, mas reduz muito o volume de tentativas automáticas no log e o ruído de alerta.\n\nConfigure parâmetros de acordo com sua realidade. Time com IP fixo pode usar bloqueios mais agressivos. Time remoto com redes variáveis precisa de ajuste mais conservador para evitar bloqueio de acesso legítimo.\n\nCombine com regras de [UFW](https://streethosting.com.br/guias/vps/firewall-ufw-vps-ubuntu) compatíveis com a porta real de SSH e revise também a integração com Docker quando houver containers publicados.\n\n## Operação e auditoria contínua\n\nSegurança de SSH não é ação única. Faça revisão trimestral de `authorized_keys`, remova chaves sem dono claro e documente quem tem acesso administrativo. Essa rotina reduz risco sem aumentar complexidade.\n\nPara seguir no hardening da VPS, leia o guia de [instalação de Docker no Ubuntu](https://streethosting.com.br/guias/vps/instalar-docker-ubuntu-vps). Para escolha de hardware, compare também [VPS Ryzen vs VPS Xeon](https://streethosting.com.br/guias/vps/vps-ryzen-vs-vps-xeon). Cargas maiores podem pedir [servidor dedicado](https://streethosting.com.br/dedicated).\n\n- [ ] Backup privado do sshd_config antes de mudanças.\n- [ ] Lista atualizada de usuários autorizados em AllowUsers.\n- [ ] Console de recuperação testado para emergências.\n- [ ] Atualizações de segurança aplicadas em janela recorrente."
  }
}