Guia de porta SSH: acesso seguro ao servidor remoto

SSH cria um canal criptografado entre um cliente e um servidor remoto. Durante a configuração da conexão, o cliente verifica a chave do host do servidor, ambos os lados negociam a criptografia e o usuário autentica com uma senha, chave SSH, certificado, chave apoiada por hardware ou outro método configurado.

Após a autenticação, o SSH pode fornecer um shell interativo, executar um único comando remoto, encaminhar portas, copiar arquivos ou ferramentas poderosas como Git, rsync, Ansible e pipelines de implantação. Essa flexibilidade é a razão pela qual o SSH é operacionalmente importante e a razão pela qual a exposição necessita de uma política cuidadosa.

Abra SSH quando administradores, ferramentas de automação, trabalhos de CI/CD, gerenciamento de configuração, serviços Git ou fluxos de trabalho de segurança precisarem de acesso remoto a um servidor ou dispositivo. Para servidores de nuvem pública, o SSH costuma ser o primeiro caminho de gerenciamento usado antes da instalação de ferramentas de nível superior.

Não publique SSH para toda a Internet se apenas um pequeno grupo precisar de acesso. Prefira VPN, hosts bastiões, acesso de confiança zero, consoles seriais em nuvem, listas de permissões de IP de origem ou conectividade de rede privada, quando possível. Se o SSH público for inevitável, aplique autenticação e monitoramento fortes desde o início.

Antes de abrir a porta 22, confirme se o sshd está rodando, escutando na interface pretendida e configurado para o modelo de autenticação que você realmente deseja. Decida se as senhas são permitidas, quais usuários podem fazer login, se o login root está desabilitado e como as ações administrativas serão auditadas.

Um verificador de porta pode confirmar se o TCP 22 está acessível de fora da sua rede, mas não pode provar que um usuário pode efetuar login com segurança. Use ssh -vvv, logs de servidor e testes em nível de conta para validar a confiança da chave do host, permissões de chave, políticas de MFA, acesso ao shell e regras sudo.

No Windows Server, instale e habilite o OpenSSH Server, inicie o serviço sshd e permita o TCP 22 de entrada no Firewall do Windows Defender. Os servidores Windows hospedados na nuvem também precisam de regras correspondentes de firewall na nuvem ou de grupo de segurança.

No Linux, instale o OpenSSH Server, verifique sshd_config e permita o TCP 22 através do firewall do host, como ufw, firewalld, nftables ou iptables. As instâncias de nuvem também exigem que o grupo de segurança do provedor permita as mesmas redes de origem.

No macOS, ative o login remoto quando o SSH for necessário em redes confiáveis. Para exposição na Internet, aplique os mesmos controles de um servidor: autenticação baseada em chave, escopo de firewall, registro em log e atualizações oportunas.

Comece com uma verificação de porta externa em relação ao nome de host público ou endereço IP e porta 22. Se o resultado for aberto, o caminho TCP para SSH estará acessível. Em seguida, execute ssh user@example.com ou ssh -vvv user@example.com para verificar a chave do host, o método de autenticação e a configuração da sessão.

No servidor, confirme o ouvinte com ss -tlnp, netstat ou PowerShell. Se um servidor em nuvem estiver envolvido, compare as regras de firewall do host com o grupo de segurança em nuvem, pois qualquer camada pode bloquear o SSH mesmo quando a outra parece correta.

Se a porta 22 estiver fechada, o sshd pode ser interrompido, instalado em uma porta diferente, vinculado apenas a uma interface privada ou bloqueado pelo firewall do host. Se a verificação expirar, os pacotes poderão ser descartados por um grupo de segurança de nuvem, regra NAT do roteador, filtro ISP, política VPN ou lista de permissões de IP de origem.

Se a porta estiver aberta, mas o login falhar, inspecione o nome de usuário, as permissões de chave, o arquivo autorizado_keys, a política de senha, o requisito de MFA, as regras AllowUsers ou DenyUsers, as configurações de login root e os logs do servidor. Muitas falhas de SSH são problemas de autorização e não de porta.

Desative o login root, dê preferência a chaves ou certificados em vez de senhas, gire chaves, remova contas obsoletas e restrinja quem pode se conectar. Use MFA ou chaves baseadas em hardware para acesso privilegiado e certifique-se de que as chaves privadas estejam protegidas com senhas ou armazenamento seguro em hardware.

Reduza a superfície de ataque com listas de permissões de origem, hosts bastiões, VPN, limitação de taxa, detecção de invasões e patches OpenSSH oportunos. Mover o SSH para uma porta fora do padrão pode reduzir varreduras ruidosas, mas deve ser tratado apenas como redução de ruído, não como um controle de segurança.