Chaves SSH (Chaves criptográficas SSH)

1. Visão geral do conceito e problema sistêmico

A autenticação tradicional baseada em login e senha em servidores remotos apresenta falhas arquitetônicas críticas: vulnerabilidade a ataques de força bruta (brute-force), interceptação em caso de comprometimento do canal (man-in-the-middle) e o fator humano (uso de senhas fracas ou reutilizadas). Assim que a porta 22 é exposta à internet pública, botnets geram milhares de tentativas de adivinhação de senhas por minuto.

SSH Keys (Chaves Criptográficas SSH) resolvem esse problema através da criptografia assimétrica. O usuário gera um par de matematicamente relacionados:

• Private Key (Chave Privada): Armazenada exclusivamente na máquina local do desenvolvedor em formato criptografado com passphrase e nunca transmitida pela rede.
• Public Key (Chave Pública): Instalada no servidor de destino no arquivo ~/.ssh/authorized_keys.

Durante o handshake, o servidor gera um desafio aleatório, criptografa-o ou solicita uma assinatura do cliente usando a chave privada. A autenticação ocorre via confirmação matemática da posse da chave privada sem revelar o segredo em si.

+------------------+                    +--------------------+
|  Cliente Local   |                    |  Servidor Remoto   |
|  (~/.ssh/id_ed)  |                    |  (~/.ssh/auth_keys)|
+--------+---------+                    +---------+----------+
         |                                        |
         |  1. Solicitação de conexão (User, PubKey)|
         |--------------------------------------->|
         |                                        | 2. Verificação da existência
         |                                        |    da chave pública
         |  3. Desafio criptográfico (Nonce)      |
         |<---------------------------------------|
         |                                        |
         | 4. Assinatura do nonce com a chave privada|
         |--------------------------------------->|
         |                                        | 5. Validação da assinatura
         |                                        |    com a chave pública
         |  6. Sessão aberta (Autenticada)        |
         |<---------------------------------------|

2. Taxonomia arquitetônica e modelo mental

Os algoritmos criptográficos para SSH evoluíram junto com o aumento do poder computacional e dos avanços em criptoanálise:

1. Ed25519 (Edwards-curve Digital Signature Algorithm):
   • O padrão ouro atual da indústria.
   • Baseado na curva elíptica Curve25519.
   • Comprimento da chave: 256 bits.
   • Alta resistência a ataques side-channel e timing, com velocidade extremamente rápida de execução das operações.
2. ECDSA (Elliptic Curve Digital Signature Algorithm):
   • Usa curvas padronizadas NIST (por exemplo, nistp256 ou nistp521).
   • Apresenta riscos potenciais de backdoors na seleção de parâmetros do gerador NIST e sensibilidade crítica à qualidade do gerador de números aleatórios (RNG): a reutilização do valor aleatório k revela completamente a chave privada.
3. RSA (Rivest-Shamir-Adleman):
   • Algoritmo clássico baseado na fatoração de grandes números primos.
   • Chaves com menos de 2048 bits são consideradas comprometidas. O mínimo seguro é de 4096 bits.
   • Chaves públicas e privadas volumosas, com geração e assinatura mais lentas.
4. FIDO2 / Hardware Security Keys (ed25519-sk / ecdsa-sk):
   • Autenticação de hardware via tokens físicos (YubiKey).
   • A chave privada é gerada e nunca sai do chip protegido do token; cada sessão SSH exige toque físico.

3. Pipeline técnico e mecânica interna

Geração e deploy de chaves seguras

Geração de uma chave Ed25519 de produção com número elevado de rounds de derivação de chave (KDF) para proteção contra brute-force de GPU na passphrase:

# Генерація Ed25519 з коментарем та 100 раундами KDF
ssh-keygen -t ed25519 -a 100 -C "admin@production-cluster" -f ~/.ssh/id_ed25519_prod

Copiando a chave pública para o servidor remoto:

ssh-copy-id -i ~/.ssh/id_ed25519_prod.pub deploy@vps.internal.net

Estrutura de permissões do sistema de arquivos Linux

Permissões de acesso incorretas são a causa de 90% das falhas de autenticação SSH (Permission denied (publickey)):

# Локальна машина клієнта:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519_prod
chmod 644 ~/.ssh/id_ed25519_prod.pub
chmod 600 ~/.ssh/config

# Віддалений сервер:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Configuração do cliente (~/.ssh/config)

Para evitar passar longas flags na linha de comando, usa-se uma configuração declarativa do cliente:

Host prod-node-01
    HostName 198.51.100.24
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes
    ServerAliveInterval 60
    ServerAliveCountMax 3

Host bastion-jumphost
    HostName 203.0.113.10
    User gatekeeper
    IdentityFile ~/.ssh/id_ed25519_bastion

Host internal-db
    HostName 10.0.4.15
    User postgres
    ProxyJump bastion-jumphost
    IdentityFile ~/.ssh/id_ed25519_db

4. Cenários práticos de engenharia em produção

01. Acesso sem senha para pipelines automatizados de CI/CD

Em ambientes GitHub Actions ou GitLab CI/CD, o deploy é realizado automaticamente via uma chave SSH técnica dedicada. A chave privada é armazenada nos Secrets criptografados do repositório, enquanto a chave pública no servidor está vinculada a um shell restrito ou a um comando específico usando a diretiva command="..." no authorized_keys:

command="/usr/local/bin/deploy-webhook.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5... ci-deploy-key

Mesmo que o secret do CI/CD seja comprometido, o atacante só poderá executar o script de deploy determinístico, não comandos arbitrários no terminal.

02. Acesso a nós de infraestrutura isolados via Bastion (ProxyJump)

Em VPCs, bancos de dados privados ou servidores de agentes de IA não possuem IPs públicos. O engenheiro conecta-se através de um host Bastion intermediário sem necessidade de exportar a chave privada para o Bastion:

ssh -J gatekeeper@bastion.example.com deploy@10.0.1.50

O SSH tunela o tráfego TCP ao nível do socket através do nó proxy, criptografando a sessão com a chave final do servidor de destino (ProxyJump não revela o conteúdo do tráfego ao bastião).

03. Chaves de hardware FIDO2 para infraestrutura Zero Trust

Em sistemas fintech de alta carga ou regulados, os desenvolvedores são obrigados a usar tokens de hardware YubiKey. É criado um chave do tipo ed25519-sk. Cada ação git push ou sessão SSH exige pressão física do dedo no sensor do token. Isso elimina totalmente a ameaça de roubo de chaves privadas por infostealers ou malware no laptop do desenvolvedor.

5. Armadilhas, erros comuns e segurança

1. Geração de chaves sem Passphrase: Armazenar a chave privada sem uma senha robusta cria uma ameaça crítica: qualquer processo malicioso, script ou acesso físico a um laptop desbloqueado permite copiar instantaneamente a chave privada e obter acesso a toda a infraestrutura. Sempre proteja as chaves com senha e utilize ssh-agent.
2. Sprawl descontrolado no authorized_keys: Com o tempo, dezenas de chaves de ex-desenvolvedores ou contratantes temporários acumulam-se no arquivo. A falta de auditoria regular abre backdoors. Utilize gestão centralizada de chaves via Ansible, Teleport, HashiCorp Vault ou SSH Certificate Authority (CA).
3. Uso de SSH Agent Forwarding (-A): Habilitar ForwardAgent yes na configuração global permite que máquinas remotas acessem seu socket local ssh-agent. Nunca habilite Agent Forwarding globalmente; use ProxyJump ou ssh-agent -c para confirmar cada uso da chave.