02 - Chave Pública do Usuário
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 comofrom="",command="",no-port-forwardingkeytype:ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp256,sk-ssh-ed25519@openssh.com(FIDO2)base64-encoded-key: payload da chave pública codificado em Base64comment: rótulo legível, geralmenteusuario@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:
- Apresentação: O cliente SSH envia ao servidor o ID da chave pública que pretende usar (ex:
ssh-ed25519 AAAA...comment). - Busca: O servidor procura essa chave no arquivo
~/.ssh/authorized_keysdo usuário solicitado. Se não encontrar, retornaPK_USERAUTH_FAILUREimediatamente. - 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.
- Resposta Assinada: O cliente assina o desafio com sua chave privada (usando Ed25519, RSA-PSS, ou ECDSA) e devolve a assinatura.
- 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.