02 - PRIVATE KEY

No sistema de criptografia assimétrica do SSH, a Private Key (Chave Privada) é o componente mais sensível e importante do par de chaves. Enquanto a chave pública é a "fechadura" instalada nos servidores, a chave privada é a "chave mestra" física que permanece exclusivamente com o utilizador. Ela é utilizada para criar assinaturas digitais que provam a identidade do utilizador perante o servidor, sem nunca revelar o seu conteúdo durante a transmissão.

1. Natureza e Sigilo Absoluto

A característica técnica fundamental da Private Key é que ela nunca deve sair do computador de origem. Ao contrário de uma palavra-passe, que é enviada (mesmo que cifrada) para o servidor validar, a chave privada nunca viaja pela rede.

• Armazenamento Local: Geralmente guardada na pasta oculta ~/.ssh/ com nomes como id_rsa, id_ecdsa ou id_ed25519.
• Identidade Digital: Perder a chave privada é o equivalente a perder a sua identidade digital no ecossistema de servidores da empresa; qualquer pessoa com acesso a este ficheiro pode fingir ser você.
• RFC de Referência: RFC 4253 (SSH Transport Layer Protocol) e RFC 4254 (Authentication Protocols).

2. Algoritmos Suportados e Tamanhos

A geração de uma chave privada envolve a escolha de um algoritmo criptográfico. Cada algoritmo oferece um equilíbrio distinto entre segurança, performance e tamanho da assinatura.

A escolha do Ed25519 tornou-se o padrão moderno porque oferece segurança equivalente ao RSA-3072 com chaves drasticamente menores, assinaturas mais rápidas de verificar e resistência nativa a ataques de canal lateral.

3. O Papel na Autenticação (A "Assinatura")

A chave privada não "abre" a ligação de forma direta; ela resolve um desafio matemático baseado no protocolo de desafio-resposta definido na RFC 4252.

1. O servidor envia um pacote de dados aleatórios (challenge) cifrados.
2. A Private Key utiliza algoritmos complexos para "assinar" ou decifrar esse pacote localmente.
3. O resultado é enviado de volta. O servidor usa a chave pública para confirmar que apenas a chave privada correspondente poderia ter gerado aquela assinatura específica.
4. A assinatura é validada matematicamente; nenhum segredo é transmitido pela rede.

4. Proteção por Passphrase (Criptografia em Repouso)

Como a chave privada é um ficheiro no disco, ela é vulnerável se o computador for roubado ou invadido. Para mitigar isto, utiliza-se uma Passphrase:

• Cifragem do Ficheiro: A chave privada é guardada no disco cifrada por uma frase secreta definida pelo utilizador. Os formatos de cifragem em repouso incluem AES-256-CBC (formato PEM tradicional) ou o formato novo bcrypt KDF (RFC 8332 / OpenSSH nativo).
• Desbloqueio em Memória: Quando o utilizador executa o SSH, ele introduz a passphrase para "desbloquear" a chave na memória RAM. O ficheiro no disco continua protegido.
• Diferença de Password: A passphrase protege a chave localmente, enquanto a password do servidor protege a conta remotamente.
• KDF Rounds: O OpenSSH moderno permite configurar o número de rounds do bcrypt (-a 100) para dificultar ataques de brute force offline caso o ficheiro seja roubado.

5. Gestão de Permissões (O Erro de Segurança)

O software cliente SSH possui uma proteção interna rigorosa para a Private Key. Devido à sua importância, o SSH recusa-se a utilizar chaves que tenham permissões de leitura para outros utilizadores do sistema.

• Permissão Correta: Deve ser 600 (leitura e escrita apenas para o dono).
• Diretório ~/.ssh/: Deve ter permissão 700 para impedir travessia por outros usuários.
• Erro Comum: Se tentar usar uma chave com permissão 644 (leitura pública), o SSH emitirá o aviso: "Permissions for 'id_rsa' are too open. It is required that your private key files are NOT accessible by others."
• Verificação Recomendada: ls -la ~/.ssh/ deve listar os ficheiros com permissões 600 exclusivas do dono.

6. O SSH Agent (Facilitador de Uso)

Para evitar que o utilizador tenha de digitar a passphrase da Private Key em cada comando ssh ou scp, utiliza-se o ssh-agent:

• O agente é um processo que guarda a chave privada já desencriptada na memória RAM.
• O utilizador "adiciona" a chave uma vez (ssh-add) e, a partir daí, o agente negoceia as assinaturas com os servidores de forma automática e segura.
• Encaminhamento de Agente (Agent Forwarding): Permite que um servidor intermedie salte para outro sem exigir a chave privada no servidor intermediário. Porém, isto abre vetores de risco: um administrador malicioso do servidor intermediário pode usar o socket do agente para assinar desafios em nome do usuário.
• Variáveis de Ambiente: O agente expõe SSH_AUTH_SOCK (socket UNIX) e SSH_AGENT_PID para que clientes encontrem o agente em execução.

7. Formatos de Arquivo

A conversão entre formatos é feita com ssh-keygen -p -m PEM ou puttygen no Windows.

8. Boas Práticas Operacionais

1. Rodízio Periódico: Renovar chaves a cada 12-24 meses em ambientes críticos.
2. Separação por Contexto: Usar chaves distintas para produção, homologação e desenvolvimento, evitando cross-contamination.
3. Hardware Tokens (FIDO2): Migrar para chaves Ed25519-SK (ssh-keygen -t ed25519-sk) armazenadas em tokens físicos como YubiKey, onde a chave privada nunca pode ser exportada.
4. Auditoria de Uso: Habilitar logs de uso no servidor (LogLevel VERBOSE no sshd_config) para registrar qual chave pública foi usada em cada login.

9. Revogação em Caso de Compromisso

Se houver a suspeita de que uma Private Key foi copiada ou exposta (ex: portátil perdido ou servidor de backups comprometido), o procedimento de segurança é imediato:

1. Gerar um novo par de chaves.
2. Remover a Chave Pública correspondente à chave privada perdida de todos os ficheiros authorized_keys nos servidores. Uma vez removida a chave pública, a chave privada roubada torna-se inútil, pois não haverá mais uma "fechadura" compatível para validar as suas assinaturas.
3. Revogar Certificados SSH assinados por uma CA (Certificate Authority) que tenham sido emitidos com base na chave comprometida, atualizando a lista KRL (Key Revocation List).

10. Resumo Técnico

11. Conclusão

A Private Key é o âmago da identidade digital no universo SSH. Sua proteção envolve camadas técnicas (permissões, cifragem em repouso, KDF forte) e camadas operacionais (rodízio, auditoria, hardware tokens). Compreender que a chave privada nunca viaja pela rede é o ponto de partida para projetar arquiteturas de acesso remoto verdadeiramente seguras, onde a autenticação baseia-se em prova matemática e não em segredo compartilhado.