Home Comunidade Eventos YouTube Networks Desafios // produtos Academy News CTI | CVE Contato

02 - Chave Pública do Usuário

video explicativo
Video explicativoEspaco reservado para o video desta anotação — adicione video: https://youtu.be/... no frontmatter da nota.

Chave Pública do Usuário (User Public Key)

A Chave Pública do Usuário (User Public Key) é o componente do par de chaves assimétricas que o administrador "instala" no servidor para permitir o acesso sem a necessidade de senhas tradicionais. No modelo de autenticação assimétrica do SSH, padronizado na RFC 4252 (SSH Authentication Protocol), ela atua como um critério de reconhecimento: o servidor guarda esta chave para saber exatamente quais assinaturas digitais deve aceitar como legítimas para um determinado usuário. Este mecanismo substituiu quase completamente a autenticação por senha em ambientes profissionais, sendo o padrão de fato em provedores de nuvem (AWS EC2, Google Compute Engine, Azure VM) e na plataforma GitHub/GitLab para operações Git over SSH.


1. O Repositório de Confiança (authorized_keys)

Diferente das chaves de host (que identificam a máquina), a chave pública do usuário é armazenada dentro do diretório pessoal do usuário no servidor, especificamente no caminho ~/.ssh/authorized_keys. Este arquivo funciona como um repositório de confiança (trust store) individual por conta de usuário.

Formato do Arquivo

  • Formato de Linha Única: Cada chave pública ocupa exatamente uma linha no arquivo, terminada por \n. Linhas com # são comentários e são ignoradas.
  • Estrutura do campo: options keytype base64-encoded-key comment
  • options (opcional): restrições como from="", command="", no-port-forwarding
  • keytype: ssh-ed25519, ssh-rsa, ecdsa-sha2-nistp256, sk-ssh-ed25519@openssh.com (FIDO2)
  • base64-encoded-key: payload da chave pública codificado em Base64
  • comment: rótulo legível, geralmente usuario@host (não usado na validação)
  • Múltiplas Chaves: Um único usuário pode ter várias chaves públicas cadastradas (ex: uma do seu notebook pessoal, outra do computador da empresa e uma de um servidor de automação CI/CD).
  • Independência: O servidor não precisa da chave privada do usuário; ele precisa apenas da versão pública para realizar a validação matemática (assinatura digital).

Exemplo de Linha

from="10.0.0.0/8",command="/usr/bin/rsync-only" ssh-ed25519 AAAAC3Nz...lX5J alice@notebook-corp

2. Mecanismo de Identificação

Quando o usuário tenta se conectar, o processo de identificação via chave pública segue uma lógica de "Fechadura e Chave" com cinco etapas rigorosas:

  1. Apresentação: O cliente SSH envia ao servidor o ID da chave pública que pretende usar (ex: ssh-ed25519 AAAA...comment).
  2. Busca: O servidor procura essa chave no arquivo ~/.ssh/authorized_keys do usuário solicitado. Se não encontrar, retorna PK_USERAUTH_FAILURE imediatamente.
  3. Desafio Criptográfico: Se encontrar a chave, o servidor gera um desafio (nonce aleatório de 256 bits) que só pode ser resolvido por quem possui a Chave Privada correspondente.
  4. Resposta Assinada: O cliente assina o desafio com sua chave privada (usando Ed25519, RSA-PSS, ou ECDSA) e devolve a assinatura.
  5. Verificação: O servidor usa a Chave Pública (que ele já tem guardada) para verificar se a assinatura é matematicamente válida. Se for, a autenticação é concluída com sucesso (PK_USERAUTH_SUCCESS).

Em nenhum momento a chave privada trafega pela rede. Apenas assinaturas de desafios efêmeros são transmitidas, garantindo que mesmo que toda a sessão seja gravada, ela não pode ser "replayada".


3. Vantagens da Identificação por Chave Pública

Imunidade a Interceptação

Como a chave pública é, por definição, pública, não há problema se um atacante a visualizar. O que importa é que ele não possui a chave privada correspondente para gerar a assinatura correta sobre o desafio efêmero. Isto torna a autenticação por chave pública imune a ataques de sniffing e man-in-the-middle.

Revogação Seletiva

Se um desenvolvedor deixa a empresa, o administrador remove apenas a linha correspondente à chave pública dele no servidor (sed -i '/^ssh-ed25519 AAAA...alice@notebook$/d' ~/.ssh/authorized_keys). Isso corta o acesso instantaneamente sem afetar os outros usuários ou exigir a troca de senhas globais.

Automação Segura

É o método padrão para transferências de arquivos via SCP ou SFTP em scripts, pipelines de CI/CD e ferramentas de automação como Ansible, pois permite o login automático sem expor credenciais em texto simples dentro do código ou em variáveis de ambiente.

Resiliência a Brute Force

Diferente de senhas, chaves Ed25519 têm 256 bits de entropia — absurdamente mais que uma senha humana de 12 caracteres (~78 bits). Não há como fazer brute force offline contra uma chave pública sem a privada.


4. Opções e Restrições de Chave (Options Field)

Uma característica avançada da chave pública no SSH é que ela pode ser prefixada com opções de restrição diretamente no arquivo authorized_keys. Isso permite limitar o que aquela chave específica pode fazer, implementando princípio do menor privilégio:

Tabela de Opções Comuns

Opção Função Caso de Uso
from="10.0.0.0/8" Restringe IPs de origem Apenas rede corporativa
command="/usr/bin/git-shell" Força comando específico Git server como GitHub
no-port-forwarding Bloqueia -L e -R Usuários limitados
no-X11-forwarding Bloqueia X11 Hardening gráfico
no-agent-forwarding Bloqueia -A Evita roubo de agente
no-pty Não aloca terminal SFTP/SCP apenas
permitopen="db.int:5432" Lista branca de port forward Acesso granular
restrict Aplica todas as restrições acima Base para hardening
command="...",no-pty,no-X11-forwarding Combinações Serviços dedicados

Exemplo Prático: Backup Automatizado

command="/usr/bin/rsync --server -logDtpre.iLsfxC --delete . /backup",from="192.168.1.50",no-pty,no-port-forwarding ssh-ed25519 AAAA...backup-key

Esta linha permite que apenas o host 192.168.1.50 use esta chave, e mesmo assim apenas para executar o comando rsync especificado — impossibilitando acesso a shell, túneis ou outras operações.


5. Segurança do Arquivo de Chaves

Para que a identificação seja considerada válida, o servidor SSH impõe regras rígidas de permissão no diretório onde a chave pública reside, conforme StrictModes yes (padrão):

Caminho Permissão Justificativa
~/ (home) 755 ou 750 Não pode ser gravável por grupo/outros
~/.ssh/ 700 Apenas o dono pode ler/escrever
~/.ssh/authorized_keys 600 ou 644 Sem escrita para grupo/outros
~/.ssh/authorized_keys2 600 Obsoleto (OpenSSH < 3.0)

Se o arquivo tiver permissão de escrita para "outros" ou para o "grupo", o servidor SSH ignorará a chave pública por segurança, assumindo que ela pode ter sido adulterada. Esta verificação é feita no momento da autenticação e gera log Authentication refused: bad ownership or modes for file.


6. Geração, Conversão e Auditoria

# Gerando par de chaves Ed25519 (recomendado moderno)
ssh-keygen -t ed25519 -a 100 -C "alice@notebook"

# Gerando par de chaves RSA 4096 bits (compatibilidade legada)
ssh-keygen -t rsa -b 4096 -C "alice@notebook"

# Gerando chave FIDO2 (hardware token YubiKey)
ssh-keygen -t ed25519-sk -C "alice@yubikey"

# Copiando chave pública para o servidor (método simples)
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@servidor

# Verificando fingerprint da chave (identificação rápida)
ssh-keygen -lf ~/.ssh/id_ed25519.pub

# Listando todas as chaves públicas instaladas no servidor
awk '{print $1, $2, $3}' ~/.ssh/authorized_keys

# Auditando chaves com opções inseguras (RSA < 2048 bits, DSA)
ssh-keygen -l -f ~/.ssh/authorized_keys | awk '$1 < 2048 {print "INSEGURA:", $0}'

7. Resumo Técnico

Atributo Valor
Arquivo ~/.ssh/authorized_keys
RFC RFC 4252 (SSH Authentication Protocol)
Format options keytype base64 comment
Tipos modernos Ed25519, RSA-SHA2 (4096 bits), ECDSA P-256, FIDO2
Tipos obsoletos DSA, RSA-SHA1 (CVE-2020-14145)
Permissões pasta 700
Permissões arquivo 600

8. Conclusão

A Chave Pública do Usuário representa o amadurecimento definitivo do SSH como ferramenta corporativa: transita da autenticação baseada em "o que o usuário sabe" (senha) para "o que o usuário possui" (chave privada), reduzindo drasticamente a superfície de ataque a brute force, phishing e credential stuffing. Compreender o formato do authorized_keys, dominar as opções de restrição (from, command, restrict), aplicar rigorosamente as permissões de arquivo e auditar regularmente as chaves instaladas (removendo órfãs, identificando algoritmos legados como RSA-SHA1, migrando para Ed25519 ou FIDO2) são competências essenciais para qualquer administrador que opere infraestrutura crítica, especial em ambientes DevOps, cloud-native e arquiteturas zero-trust modernas.