SSH

SSH é uma família de protocolos com três camadas principais. O transport protocol negocia algoritmos, autentica o servidor por host key, executa troca de chaves e cria confidencialidade e integridade. O user authentication protocol autentica o cliente por chave pública, senha, keyboard-interactive, certificado ou outro método. O connection protocol multiplexa canais de shell, execução, subsistema, encaminhamento e túnel sobre uma única conexão. As RFCs 4251 a 4254, publicadas em 2006, definem a arquitetura SSH-2, transporte, autenticação e conexões. OpenSSH é a implementação dominante. Uma configuração atual prefere chaves Ed25519 ou ECDSA/RSA com tamanhos e algoritmos adequados, conforme política e suporte. A chave privada fica no cliente, cifrada e, idealmente, protegida por agente ou hardware FIDO2. O servidor guarda a chave pública em `authorized_keys`. A host key identifica o servidor. Na primeira conexão, o cliente exibe fingerprint. Aceitar cegamente elimina a proteção contra MITM. Em ambiente administrado, fingerprints são distribuídas por inventário, DNS SSHFP com DNSSEC ou certificados SSH. A opção `StrictHostKeyChecking` deve ser mantida. Alteração inesperada de host key precisa de investigação; pode ser reinstalação ou ataque. Algoritmos antigos como `ssh-rsa` baseado em SHA-1, DSA, CBC legado e MACs fracos devem ser desabilitados quando todos os clientes suportam alternativas. O nome `ssh-rsa` refere-se ao algoritmo de assinatura SHA-1; a mesma chave RSA pode usar rsa-sha2-256/512. Não excluir chave sem entender. O servidor e cliente precisam de versões atualizadas.

Para gateways, servidores de automação e NVRs, uma chave por administrador é superior a conta compartilhada. Cada pessoa possui identidade. A chave pode exigir presença física em YubiKey ou token FIDO2 por tipos `sk-ssh-ed25519@openssh.com`. Isso reduz exfiltração, embora perda do token exija recuperação. OpenSSH também suporta certificados SSH assinados por uma CA interna. Em vez de copiar chaves públicas para centenas de hosts, uma CA assina uma chave de usuário por horas e inclui principals. O servidor confia na CA. Certificados expiram. Isso facilita acesso just-in-time. Não confundir certificado SSH com X.509/TLS; o formato e confiança são diferentes. Para MFA, o servidor pode exigir `publickey,keyboard-interactive` em AuthenticationMethods e integrar TOTP ou PAM, mas a disponibilidade precisa. Um técnico em emergência precisa de break-glass protegido. Senha direta pode ser desabilitada após validar chaves. Root login remoto deve ser `no` ou restrito. Administradores entram com conta individual e usam sudo. `authorized_keys` aceita opções como `from=`, `command=`, `no-port-forwarding`, `no-agent-forwarding`, `no-pty` e `restrict`. Essas opções transformam uma chave de backup em acesso de função limitada. Um gateway de automação pode aceitar uma chave que executa somente script de exportação. Isso é menor privilégio. A rotação remove chaves de ex-funcionários. Inventário e logs identificam fingerprint. Não compartilhar arquivo privado por mensageiro. A chave pública pode ser compartilhada.

SSH pode encaminhar portas locais (`-L`), remotas (`-R`) e SOCKS dinâmico (`-D`). Isso permite acessar Home Assistant, MQTT ou interface de um switch sem expor portas diretamente. Um bastion host ou jump host é o único servidor SSH acessível por VPN ou Internet controlada; os demais são alcançados por `ProxyJump`. Esse desenho reduz superfície. Porém, forwarding também pode contornar firewalls. O servidor precisa restringir `AllowTcpForwarding`, `PermitOpen`, `PermitListen` e usuários. Um túnel remoto iniciado por um dispositivo para um servidor cloud pode criar acesso de suporte, mas deve ser temporário e autorizado. Não deixar `-R 0.0.0.0` aberto. `GatewayPorts` deve permanecer restrito. Um SOCKS proxy concede acesso amplo à rede; use apenas em conta autorizada. SSH também oferece tun/tap com `-w`, mas uma VPN como WireGuard é mais adequada a conectividade contínua, múltiplos clientes e políticas de rede. O critério de escolha é escopo: SSH para administração pontual e túneis específicos; VPN para acesso de rede. O SFTP é subsistema seguro para arquivos. SCP moderno usa SFTP por padrão em OpenSSH recente; implementações antigas do protocolo SCP têm riscos de nomes e caminhos. Preferir SFTP/rsync sobre SSH. A transferência precisa de permissões e quotas. Chroot e `internal-sftp` isolam contas. Um servidor de backup pode aceitar somente SFTP.

A porta 22 exposta recebe varreduras e tentativas. Mudar a porta reduz ruído, não aumenta a segurança fundamental. Melhor restringir por firewall/VPN, usar chaves, MFA, rate limiting e atualizações. O daemon deve escutar apenas interfaces necessárias. `AllowUsers`/`AllowGroups` restringem. Desabilitar login root, senhas e autenticação vazia. Limitar `MaxAuthTries`, `LoginGraceTime`, sessões e forwardings. Fail2ban pode bloquear padrões, mas não substitui autenticação. Logs registram usuário, origem, método e chave; não comandos por padrão. Para auditoria de comandos, usar sudo logs, tlog, bastion com gravação ou ferramentas, respeitando privacidade e segredos. O agente SSH permite usar chaves sem expor arquivo a cada host, mas agent forwarding é arriscado: um host comprometido pode usar o agente enquanto conectado. Preferir ProxyJump e não encaminhar agente. Se indispensável, usar chaves com confirmação. Arquivos `known_hosts` precisam ser protegidos e gerenciados. Hashed hostnames reduzem exposição de inventário, mas dificultam inspeção. Certificados SSH simplificam. A atualização do OpenSSH é crítica; vulnerabilidades surgem. O serviço deve ser reiniciado de forma segura. A consequência prática é que SSH pode ser uma porta administrativa extremamente segura ou um atalho perigoso, dependendo de chaves, host verification e configuração. Uma senha forte sem host key validada ainda permite MITM. Uma chave forte numa conta root global ainda dá privilégio excessivo.