SSH: Configuração, Hardening e Diagnóstico de Anomalias para Sysadmins em 2026

Linux · Segurança · OpenSSH · Hardening · Troubleshooting | ✎ Duarte Spínola | 10 de Julho de 2026

O SSH (Secure Shell) é o protocolo fundamental para administração remota de servidores Linux, mas também é um dos vetores de ataque mais explorados em ataques de força bruta e credenciais roubadas. Este guia cobre a configuração completa do sshd_config, geração e gestão de chaves, hardening para PMEs, diagnóstico sistemático de falhas de ligação, e resolução dos problemas mais comuns que sysadmins encontram no dia-a-dia. Inclui comandos testados em Ubuntu 24.04, Debian 12, CentOS Stream 9 e Windows 11 (OpenSSH nativo), com referências à documentação oficial OpenBSD, Microsoft Learn e NIST SP 800-53.

Conteúdos

1. O que Está a Acontecer — SSH em 2026: Protocolo, Versões e Ameaças

O SSH (Secure Shell) é o protocolo criptográfico padrão para acesso remoto a sistemas Unix/Linux, substituindo protocolos inseguros como Telnet e rlogin. A versão actual é o SSH-2 (RFC 4251-4254), sendo o SSH-1 considerado obsoleto e inseguro desde 2017 (OpenSSH release notes). A implementação de referência é o OpenSSH, desenvolvido pelo projeto OpenBSD (openssh.com).

Em 2026, o SSH enfrenta três categorias de ameaças principais:

Ataques de força bruta — Bots automatizados tentam milhares de combinações user/password por minuto contra servidores SSH expostos. O MITRE ATT&CK cataloga este vector como T1110.004 (Brute Force: SSH) (MITRE ATT&CK). A mitigação é desativar autenticação por password e usar exclusivamente chaves SSH.

Credenciais roubadas — Atacantes que comprometem chaves privadas SSH (via malware, repositórios expostos, ou backups não encriptados) podem aceder qualquer servidor onde a chave correspondente esteja autorizada. A mitigação é usar passphrase nas chaves, rodar chaves periodicamente, e restringir por IP/source.

Vulnerabilidades do protocolo — Embora o SSH-2 seja robusto, implementações antigas do OpenSSH tiveram vulnerabilidades graves (CVE-2024-6387 “regreSSHion” permitia RCE como root em OpenSSH 8.5-9.7). A mitigação é manter o OpenSSH actualizado (OpenBSD sshd_config man page).

⚠ Atenção: Se o seu servidor SSH está exposto à Internet na porta 22 e aceita passwords, é quase certo que já está a receber tentativas de brute-force. Verifique com journalctl -u sshd --since "1 hour ago" | grep "Failed password" em Linux ou Get-EventLog -LogName Security -Source "OpenSSH" no Windows.

2. Cenários em que a Configuração SSH é Crítica

Estes são os cenários mais comuns onde uma configuração SSH correcta ou incorrecta determina se a operação corre bem ou resulta num incidente de segurança:

Cenário Risco Configuração crítica
Servidor cloud (Hetzner, DigitalOcean, AWS) Exposto à Internet 24/7 PasswordAuth no, chave SSH obrigatória, fail2ban
Servidor on-premise com acesso via VPN Acesso restrito à rede VPN ListenAddress interno, AllowUsers restrito
Administração de fleet Linux (Ansible) Chave partilhada em múltiplos servidores Chave dedicada Ansible, from=IP no authorized_keys
Jump host / bastion para acesso a rede interna Ponto único de falha de segurança MFA/2FA, ProxyJump, sem AgentForwarding
Windows Server 2025 com OpenSSH nativo Integração com AD/Entra ID Match Group, chaves em ficheiro, não em AD
Acesso remoto a Android via Termux Dispositivo móvel, IP dinâmico DynamicDNS, porta não-standard, chave com passphrase
DevOps / CI/CD (GitHub Actions, GitLab CI) Chave deploy sem passphrase em pipeline Chave restrita a repositório, from=IP do runner
Recuperação de desastre (sem rede) Consola série / IPMI única via SSH Chave de emergência separada, auditada

3. Configuração Base do sshd_config — Os 12 Parâmetros Essenciais

O ficheiro /etc/ssh/sshd_config (Linux) ou C:\ProgramData\ssh\sshd_config (Windows) controla todos os aspectos do servidor SSH. A documentação de referência é a página man do OpenBSD. Aqui estão os 12 parâmetros que todo sysadmin deve configurar:

# /etc/ssh/sshd_config — Configuração base para PME
# Testado em Ubuntu 24.04, Debian 12, CentOS Stream 9 (2026-07)

# 1. Apenas SSH protocolo 2 (SSH-1 é obsoleto desde 2017)
Protocol 2

# 2. Porta — mudar de 22 reduz log noise de bots (não é segurança real)
Port 22

# 3. Endereço de escuta — restringir a interface específica se possível
# ListenAddress 0.0.0.0
# ListenAddress ::

# 4. Root login — nunca permitir login directo como root
PermitRootLogin no

# 5. Autenticação por password — desactivar em produção
PasswordAuthentication no

# 6. Autenticação por chave pública — obrigatória
PubkeyAuthentication yes

# 7. Tentativas de autenticação antes de desconectar
MaxAuthTries 3

# 8. Tempo limite de login (segundos)
LoginGraceTime 30

# 9. Tentativas de chave por ligação
MaxSessions 10

# 10. Encaminhamento de X11 — desactivar em servidores
X11Forwarding no

# 11. Agent forwarding — desactivar (risco de chave roubada)
AllowAgentForwarding no

# 12. TCP forwarding — restringir se servidor não deve ser túnel
AllowTcpForwarding no

Após editar o sshd_config, valide a sintaxe antes de reiniciar:

# Validar configuração (não reinicia o serviço)
sudo sshd -t

# Se não houver erros, reiniciar
sudo systemctl restart sshd

# Verificar que o serviço está a correr
sudo systemctl status sshd

⚠ Nunca reinicie o sshd sem uma sessão SSH alternativa aberta. Se a configuração estiver errada, perde o acesso ao servidor. Mantenha uma sessão activa e teste a nova ligação numa segunda janela antes de fechar a primeira.

Parâmetros adicionais de segurança

# Restringir utilizadores autorizados (whitelist)
AllowUsers admin deploy ansible

# Restringir grupos
AllowGroups ssh-users admins

# Mensagem de aviso legal antes do login
Banner /etc/ssh/banner.txt

# Tempo de inactividade antes de desconectar (segundos)
ClientAliveInterval 300
ClientAliveCountMax 2

# Tipo de chaves aceites (ed25519 preferido, RSA ≥ 4096)
PubkeyAcceptedAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

# Cifras aceites (apenas as mais seguras em 2026)
Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]

4. Chaves SSH — Gerar, Distribuir, Rodar e Revogar

Gerar chaves SSH

O tipo de chave recomendado em 2026 é Ed25519 — mais rápido, mais pequeno (68 bytes vs 672 bytes do RSA-4096) e igualmente seguro. A geração usa o comando ssh-keygen (documentação OpenBSD):

# Gerar chave Ed25519 (recomendado)
ssh-keygen -t ed25519 -C "[email protected] - 2026-07"

# Output:
# Generating public/private ed25519 key pair.
# Enter file in which to save the key (~/.ssh/id_ed25519):
# Enter passphrase (empty for no passphrase): ********
# Your identification has been saved in ~/.ssh/id_ed25519
# Your public key has been saved in ~/.ssh/id_ed25519.pub
# The key fingerprint is:
# SHA256:AbCdEf... [email protected] - 2026-07

Alternativa com RSA 4096 bits (para sistemas antigos sem suporte Ed25519):

# Gerar chave RSA 4096 (compatibilidade legacy)
ssh-keygen -t rsa -b 4096 -C "[email protected] - 2026-07"

ℹ Passphrase é obrigatória em chaves de produção. Sem passphrase, quem roubar o ficheiro da chave privada tem acesso imediato a todos os servidores. A passphrase encripta a chave privada no disco — só é pedida quando se usa a chave, e o ssh-agent cache-a na sessão.

Distribuir chaves SSH

# Método 1: ssh-copy-id (mais simples)
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@servidor

# Output:
# /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "~/.ssh/id_ed25519.pub"
# user@servidor's password: ********
# Number of key(s) added: 1
# Now try logging into the machine, with: "ssh user@servidor"

# Método 2: Manual (quando ssh-copy-id não está disponível)
cat ~/.ssh/id_ed25519.pub | ssh user@servidor "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Restringir chave por IP de origem

No ficheiro authorized_keys no servidor, pode-se restringir de que IP a chave pode ser usada:

# ~/.ssh/authorized_keys no servidor
# Restringir a IP fixo da empresa
from="192.168.1.100" ssh-ed25519 AAAA... [email protected]

# Restringir a range de IPs
from="10.0.0.0/24,192.168.1.0/24" ssh-ed25519 AAAA... [email protected]

# Chave apenas para Ansible — sem shell interactiva
from="10.0.0.50",command="/usr/local/bin/ansible-runner.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAA... [email protected]

Verificar chaves existentes

# Listar chaves no servidor
cat ~/.ssh/authorized_keys

# Verificar fingerprint de uma chave
ssh-keygen -lf ~/.ssh/id_ed25519.pub
# 256 SHA256:AbCdEf... [email protected] - 2026-07 (ED25519)

# Verificar todas as chaves de um utilizador
for key in ~/.ssh/*.pub; do ssh-keygen -lf "$key"; done

Rodar e revogar chaves

A rotação periódica de chaves é uma boa prática. O processo é: gerar nova chave, distribuir, testar, remover chave antiga:

# 1. Gerar nova chave
ssh-keygen -t ed25519 -C "[email protected] - 2026-12"

# 2. Distribuir
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@servidor

# 3. Testar nova chave
ssh -i ~/.ssh/id_ed25519 user@servidor "echo OK"

# 4. Remover chave antiga do servidor
ssh user@servidor "sed -i '/[email protected] - 2026-07/d' ~/.ssh/authorized_keys"

# 5. Confirmar que a chave antiga já não funciona
ssh -i ~/.ssh/id_ed25519_old user@servidor
# Expected: Permission denied (publickey)

5. Hardening SSH para PME — Checklist NIST SP 800-53

O NIST SP 800-53 (Security and Privacy Controls for Information Systems) inclui controlos específicos para acesso remoto. A tabela abaixo mapeia os controlos NIST relevantes a configurações SSH concretas (NIST SP 800-53 Rev 5):

Controlo NIST Descrição Configuração SSH
AC-2(2) Gestão de contas privilegiadas PermitRootLogin no, sudo para escalamento
AC-17(1) Acesso remoto com proteção criptográfica Protocol 2, cifras modernas, Ed25519
AC-17(2) Controlo de rotas de acesso remoto AllowUsers, AllowGroups, from= no authorized_keys
AU-2 Auditoria de eventos LogLevel VERBOSE, journalctl, /var/log/auth.log
AU-12 Geração de registos de auditoria ForceCommand para log de sessões, session recording
IA-5(1) Autenticação baseada em chaves PasswordAuthentication no, PubkeyAuthentication yes
IA-5(6) Protecção contra replay attacks ClientAliveInterval, MaxAuthTries
SC-8 Confidencialidade em trânsito Cifras AEAD (chacha20-poly1305, aes-gcm)
SC-13 Uso de criptografia aprovada Ed25519, RSA-SHA2, cifras NIST-approved
MA-4 Manutenção remota Jump host dedicado, ProxyJump, logs de sessão

Script de hardening automático

#!/bin/bash
# hardening-ssh.sh — Hardening SSH para PME
# Testado em Ubuntu 24.04, Debian 12, CentOS Stream 9 (2026-07)
set -euo pipefail

SSHD_CONFIG="/etc/ssh/sshd_config"
BACKUP="${SSHD_CONFIG}.backup.$(date +%Y%m%d)"

# Backup
cp "$SSHD_CONFIG" "$BACKUP"
echo "Backup criado: $BACKUP"

# Aplicar configurações de hardening
sed -i 's/^#*Protocol .*/Protocol 2/' "$SSHD_CONFIG"
sed -i 's/^#*PermitRootLogin .*/PermitRootLogin no/' "$SSHD_CONFIG"
sed -i 's/^#*PasswordAuthentication .*/PasswordAuthentication no/' "$SSHD_CONFIG"
sed -i 's/^#*PubkeyAuthentication .*/PubkeyAuthentication yes/' "$SSHD_CONFIG"
sed -i 's/^#*MaxAuthTries .*/MaxAuthTries 3/' "$SSHD_CONFIG"
sed -i 's/^#*LoginGraceTime .*/LoginGraceTime 30/' "$SSHD_CONFIG"
sed -i 's/^#*X11Forwarding .*/X11Forwarding no/' "$SSHD_CONFIG"
sed -i 's/^#*AllowAgentForwarding .*/AllowAgentForwarding no/' "$SSHD_CONFIG"

# Adicionar configurações que não existem
grep -q "^ClientAliveInterval" "$SSHD_CONFIG" || echo "ClientAliveInterval 300" >> "$SSHD_CONFIG"
grep -q "^ClientAliveCountMax" "$SSHD_CONFIG" || echo "ClientAliveCountMax 2" >> "$SSHD_CONFIG"

# Validar
sshd -t && echo "Configuração válida" || { echo "ERRO: configuração inválida"; exit 1; }

echo "Hardening aplicado. Reinicie com: sudo systemctl restart sshd"
echo "MAS TESTE PRIMEIRO numa sessão alternativa!"

6. Diagnóstico de Falhas de Ligação SSH — Método Sistemático

Quando uma ligação SSH falha, o erro pode estar em qualquer ponto da cadeia: rede, DNS, firewall, configuração do servidor, chaves, permissões de ficheiros, ou cliente. O método correcto é diagnosticar camada a camada, da mais básica para a mais complexa.

Passo 1 — Verificar conectividade de rede

# 1. Conectividade IP (camada 3)
ping -c 3 192.168.1.100

# 2. Porta SSH aberta (camada 4)
nc -zv 192.168.1.100 22
# ou
telnet 192.168.1.100 22
# Output esperado: Connected to 192.168.1.100.
# Se timeout: firewall a bloquear ou sshd não está a correr

# 3. Resolver DNS (se usar hostname)
dig +short servidor.kbase.pt
nslookup servidor.kbase.pt

Passo 2 — Modo verbose do cliente SSH

# Modo verbose (3 níveis: -v, -vv, -vvv)
ssh -vvv user@servidor

# Output típico (resumido):
# debug1: Connecting to servidor [192.168.1.100] port 22.
# debug1: Connection established.
# debug1: Local version string: OpenSSH_9.6p1 Ubuntu-3ubuntu13
# debug1: Remote protocol version 2.0, remote software version OpenSSH_9.6p1
# debug1: SSH2_MSG_KEXINIT sent
# debug1: SSH2_MSG_KEXINIT received
# debug1: Offering public key: id_ed25519 ED25519 SHA256:...
# debug1: Server accepts key: id_ed25519 ED25519
# debug1: Authentication succeeded (publickey).

O modo verbose mostra exactamente em que fase a ligação falha. As fases são:

  1. Connection established — rede OK
  2. KEXINIT — negociação de cifra OK
  3. Offering public key — a tentar a chave
  4. Server accepts/rejects key — resultado da autenticação
  5. Authentication succeeded — ligação completa

Passo 3 — Verificar logs do servidor

# Ubuntu/Debian — auth.log
sudo tail -f /var/log/auth.log | grep sshd

# CentOS/RHEL/Stream — journalctl
sudo journalctl -u sshd -f

# Ver falhas de autenticação na última hora
sudo journalctl -u sshd --since "1 hour ago" | grep -i "fail\|denied\|invalid"

# Windows Server 2025
Get-WinEvent -LogName "Microsoft-Windows-OpenSSH/Operational" -MaxEvents 20

Passo 4 — Verificar permissões de ficheiros

SSH é extremamente rigoroso com permissões. Se as permissões não estiverem correctas, a autenticação por chave falha silenciosamente:

# Permissões correctas (OBRIGATÓRIAS):
# ~/.ssh/              → 700 (drwx------)
# ~/.ssh/authorized_keys → 600 (-rw-------)
# ~/.ssh/id_ed25519    → 600 (-rw-------)
# ~/.ssh/id_ed25519.pub → 644 (-rw-r--r--)

# Corrigir permissões
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

# Verificar ownership (deve ser o próprio utilizador)
ls -la ~/.ssh/
# chown user:user ~/.ssh/authorized_keys

ℹ Permissões incorrectas são a causa #1 de “Permission denied (publickey)”. O SSH ignora silenciosamente chaves em directórios com permissões demasiado permissivas. Se a home directory tiver permissões 777, o SSH recusa todas as chaves.

Passo 5 — Verificar configuração do servidor

# Validar sintaxe do sshd_config
sudo sshd -t

# Ver configuração efectiva (com valores por omissão)
sudo sshd -T | grep -E "permitroot|passwordauth|pubkey|maxauth"

# Verificar que o sshd está a correr
sudo systemctl status sshd
sudo systemctl is-active sshd

# Verificar porta de escuta
sudo ss -tlnp | grep ssh
# ou
sudo netstat -tlnp | grep ssh

7. Os 10 Problemas Mais Comuns — Causa e Solução

Problema Causa Solução
Permission denied (publickey) Permissões erradas em ~/.ssh ou authorized_keys chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys
Connection timed out Firewall a bloquear porta 22 ou sshd parado sudo ufw allow 22 ou sudo systemctl start sshd
Connection refused sshd não está a correr ou porta errada sudo systemctl start sshd && sudo ss -tlnp | grep ssh
Host key verification failed Chave do servidor mudou (reinstall, clone, IP reutilizado) ssh-keygen -R servidor para remover known_hosts
Too many authentication failures Cliente a tentar muitas chaves automáticas ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@host
No route to host Roteamento de rede incorrecto ou host down Verificar com ping, traceroute, rota de gateway
Remote port forwarding failed Porta local já em uso ou GatewayPorts no sudo lsof -i :porta e GatewayPorts yes no sshd_config
key_load_public: Permission denied Permissões erradas na chave privada chmod 600 ~/.ssh/id_ed25519
WARNING: UNPROTECTED PRIVATE KEY FILE Chave privada com permissões demasiado abertas (644) chmod 600 ~/.ssh/id_ed25519
fatal: no matching MAC found Cliente e servidor não partilham nenhum algoritmo MAC Actualizar OpenSSH em ambos os lados ou adicionar MACs compatíveis

8. SSH no Windows 11 e Windows Server 2025

O Windows inclui OpenSSH nativamente desde o Windows 10 1809. No Windows Server 2025 e Windows 11 24H2, o OpenSSH vem pré-instalado mas precisa de ser activado (Microsoft Learn — OpenSSH installation, Microsoft Learn — OpenSSH configuration).

Instalar e activar OpenSSH no Windows

# Instalar via PowerShell (admin)
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

# Iniciar serviço
Start-Service sshd

# Configurar arranque automático
Set-Service -Name sshd -StartupType Automatic

# Firewall — abrir porta 22
New-NetFirewallRule -Name sshd -DisplayName "OpenSSH Server (sshd)" `
  -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22

Configuração sshd_config no Windows

# C:\ProgramData\ssh\sshd_config
# Nota: ProgramData é pasta oculta

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no

# Para utilizadores do domínio (AD):
# As chaves vão em C:\ProgramData\ssh\administrators_authorized_keys
# (não em ~/.ssh/authorized_keys como no Linux)

# Para utilizadores comuns:
# As chaves vão em C:\Users\\.ssh\authorized_keys

# Match Group — restringir por grupo AD
Match Group Administradores
    AuthorizedKeysFile C:\ProgramData\ssh\administrators_authorized_keys

ℹ No Windows, administradores (incluindo Domain Admins) usam o ficheiro C:\ProgramData\ssh\administrators_authorized_keys — não ~/.ssh/authorized_keys. Isto confunde muitos sysadmins Linux. As permissões correctas são atribuídas com icacls "C:\ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "SYSTEM:(F)" /grant "BUILTIN\Administradores:(F)".

Gerar chaves SSH no Windows

# PowerShell
ssh-keygen -t ed25519 -C "[email protected] - 2026-07"

# As chaves ficam em:
# C:\Users\\.ssh\id_ed25519 (privada)
# C:\Users\\.ssh\id_ed25519.pub (pública)

PowerShell remoting via SSH

O PowerShell 7 suporta remoting via SSH nativamente, sem necessidade de WinRM (Microsoft Learn — SSH remoting in PowerShell):

# Entrar numa sessão remota via SSH
Enter-PSSession -HostName servidor -UserName admin

# Executar comando remoto
Invoke-Command -HostName servidor -UserName admin -ScriptBlock {
    Get-Service | Where-Object Status -eq "Running"
}

9. Jump Host / Bastion e Túneis SSH para PME

ProxyJump — A via jump host sem expor servidores internos

O ProxyJump (introduzido no OpenSSH 7.3, 2016) permite ligar a um servidor interno através de um bastion, sem necessidade de túneis manuais. É a forma recomendada de aceder a servidores numa rede privada (OpenBSD ssh_config man page):

# ~/.ssh/config no cliente
# Bastion (jump host)
Host bastion
    HostName bastion.kbase.pt
    User admin
    IdentityFile ~/.ssh/id_ed25519

# Servidor interno via bastion
Host servidor-interno
    HostName 192.168.1.50
    User admin
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

# Agora basta:
ssh servidor-interno
# O SSH liga primeiro ao bastion, depois salta para 192.168.1.50

Túnel SSH — Port forwarding

# Forward local — aceder serviço remoto localmente
# Aceder web interface remota em http://localhost:8080
ssh -L 8080:localhost:8080 user@servidor

# Forward remoto — expor serviço local ao servidor remoto
# Útil para acessos reversos através de CGNAT
ssh -R 9090:localhost:22 user@servidor-cloud

# Dynamic (SOCKS proxy) — túnel dinâmico
ssh -D 1080 user@servidor
# Configurar proxy SOCKS5 127.0.0.1:1080 no browser

Configuração ~/.ssh/config recomendada para PME

# ~/.ssh/config — Configuração base para PME
# Global
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
    TCPKeepAlive yes
    IdentitiesOnly yes
    HashKnownHosts yes
    AddKeysToAgent yes

# Servidores cloud
Host hetzner-prod
    HostName 188.245.x.x
    User admin
    IdentityFile ~/.ssh/kbase_ed25519
    Port 22

Host hetzner-staging
    HostName 188.245.x.y
    User admin
    IdentityFile ~/.ssh/kbase_ed25519

# Servidor interno via bastion
Host db-interno
    HostName 10.0.0.5
    User postgres
    ProxyJump hetzner-prod
    IdentityFile ~/.ssh/kbase_ed25519

# Windows Server via SSH
Host win-ad
    HostName 192.168.1.10
    User Administrator
    IdentityFile ~/.ssh/kbase_ed25519

10. Monitorização e Auditoria de Sessões SSH

LogLevel VERBOSE para auditoria

# sshd_config — registar fingerprints de chaves usadas
LogLevel VERBOSE

# Após reiniciar sshd, os logs mostram:
# Jul 10 14:23:01 servidor sshd[1234]: Connection from 192.168.1.100 port 54321
# Jul 10 14:23:01 servidor sshd[1234]: Accepted publickey for admin from 192.168.1.100
# Jul 10 14:23:01 servidor sshd[1234]: paml_unix(sshd:session): session opened for user admin
# Jul 10 14:23:01 servidor sshd[1234]: User child is on pid 1235

Fail2ban — Bloquear ataques de força bruta

# Instalar
sudo apt install fail2ban

# Configuração: /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 22
maxretry = 3
bantime = 3600
findtime = 600

# Reiniciar
sudo systemctl restart fail2ban

# Verificar status
sudo fail2ban-client status sshd
# Status for the jail: sshhd
# |- Filter
# |  |- Currently failed: 0
# |  |- Total failed:     47
# |- Actions
# |  |- Currently banned: 2
# |  |- Total banned:     15

Auditoria de sessões com session recording

# Para auditoria completa (NIST AU-12), gravar todas as sessões:
# /etc/ssh/sshd_config
ForceCommand /usr/local/bin/session-log.sh

# /usr/local/bin/session-log.sh
#!/bin/bash
LOGDIR="/var/log/ssh-sessions"
mkdir -p "$LOGDIR"
LOGFILE="$LOGDIR/${USER}_$(date +%Y%m%d_%H%M%S)_$$.log"
exec script -q -f "$LOGFILE" -c "$SHELL"

# chmod +x /usr/local/bin/session-log.sh
# Cada sessão SSH fica gravada em /var/log/ssh-sessions/

11. FAQ para Sysadmins

1. Devo mudar a porta SSH de 22 para outra?

Mudar a porta reduz o ruído nos logs (bots scaneiam a 22 por defeito), mas não é uma medida de segurança real — um atacante determinado encontra a porta. Use como camada adicional, não como substituto de hardening real (chaves, fail2ban, firewall).

2. Ed25519 ou RSA?

Ed25519 em 2026. É mais rápido, mais pequeno, e igualmente seguro. RSA 4096 só se precisar de compatibilidade com sistemas antigos (OpenSSH < 6.5, 2014). Nunca use RSA 2048 ou menor — é considerada insegura (OpenBSD ssh-keygen man page).

3. Quanto tempo deve durar uma chave SSH?

Não há um standard oficial, mas a prática recomendada é rodar chaves administrativas a cada 12-18 meses. Chaves de deploy/CI podem durar mais se forem restritas por IP e repositório. O mais importante é ter um processo de revogação rápido — se uma chave é comprometida, deve poder ser removida de todos os servidores em minutos.

4. Posso usar a mesma chave em todos os servidores?

Sim para ambientes pequenos (1-10 servidores). Para fleets maiores, use chaves diferentes por função (admin, deploy, ansible, backup) para que possa revogar uma sem afectar as outras. A chave Ansible, por exemplo, deve ter from= restrito ao IP do controlador e command= restrito ao runner.

5. SSH agent forwarding é seguro?

Não totalmente. O agent forwarding permite que o servidor remoto use as suas chaves locais para saltar para outros servidores. Se o servidor remoto estiver comprometido, o atacante pode usar as suas chaves. Use ProxyJump em vez de agent forwarding sempre que possível.

6. Como diagnosticar “Permission denied (publickey)” quando tudo parece correcto?

Verifique nesta ordem: (1) permissões ~/.ssh (700), authorized_keys (600); (2) ownership dos ficheiros (chown user:user); (3) sshd_config tem PubkeyAuthentication yes; (4) ssh -vvv mostra “Server accepts key”; (5) logs do servidor mostram motivo da rejeição; (6) SELinux/AppArmor não está a bloquear.

7. Como aceder a um servidor quando o SSH está completamente partido?

Em cloud: consola serie do provider (Hetzner Cloud Console, AWS Systems Manager, Azure Serial Console). On-premise: IPMI/iLO/DRAC com consola virtual. Se nenhuma disponível: boot com live USB e montar o disco para corrigir sshd_config.

8. Devo desactivar PasswordAuthentication completamente?

Sim em produção. Mantenha activo apenas em fase de instalação inicial (para distribuir a primeira chave). Depois da chave instalada e testada, desactive. Exceção: servidores de emergência onde possa perder acesso à chave — nestes casos, use password + MFA (via PAM).

12. Erros Comuns e Resoluções Rápidas

Erro Causa provável Comando de resolução
ssh: connect to host X port 22: Connection refused sshd parado sudo systemctl start sshd
ssh: connect to host X port 22: Connection timed out Firewall ou host down nc -zv host 22 + ping host
Permission denied (publickey) Permissões, chave errada, ou user errado chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys
Host key verification failed Chave do servidor mudou ssh-keygen -R host
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED Possível MITM ou reinstall Verificar com admin, depois ssh-keygen -R host
bad permissions ~/.ssh demasiado permissivo chmod 700 ~/.ssh
no matching key exchange found Cliente/servidor incompatíveis Actualizar OpenSSH ou adicionar KexAlgorithms compatíveis
systemctl status sshd: failed Erro de sintaxe no sshd_config sshd -t para ver o erro exacto
Authenticated with partial success MFA requerido (PAM + segundo factor) Configurar segundo factor (TOTP, FIDO2)
channel 2: open failed: administratively prohibited AllowTcpForwarding no no servidor Activar AllowTcpForwarding yes no sshd_config

Artigos Relacionados

← Voltar ao Índice

Este artigo foi útil?

Duarte Spínola

Artigos  

Comentários estão desativos.