APRENDER. PRATICAR. EVOLUIR.Separar os elementos de autenticação
Um certificado OpenSSH de utilizador associa uma chave pública a identidade e opções assinadas por uma CA. Não é um certificado X.509 para instalar num website. O cliente continua a precisar de acesso ao material privado correspondente, por ficheiro, agente ou dispositivo apropriado. A chave privada da CA serve a emissão e não deve ser copiada para cada executor como credencial do job. No exercício, distingue cinco elementos: conta pretendida, principal certificado, CA confiável, intervalo de validade e restrições de sessão. Uma assinatura não substitui os restantes requisitos de autorização.
Inspecionar a emissão local
O laboratório cria uma CA e uma chave de utilizador descartáveis. A emissão define Key ID dr-batch-27, principal batch, serial 27, validade em 2 de outubro de 2026 das 09:00 às 10:00 UTC, -O clear e force-command=/usr/bin/true. Depois, ssh-keygen -L confirma esses campos e a ausência de extensões de permissão. O intervalo é deliberadamente fixo para tornar a leitura reproduzível; não é uma credencial destinada a acesso real. O comando forçado não foi executado. Todas as chaves privadas temporárias são eliminadas no fim do runner.
Relacionar principal e conta
Key ID identifica a emissão para registo; não é automaticamente a conta remota autorizada. No fluxo em que a CA está em TrustedUserCAKeys e não há ficheiro ou comando de principais, o nome da conta tem de aparecer na lista de principais do certificado. Se a conta é deploy e o único principal é batch, uma assinatura válida não resolve a diferença. Quando existe AuthorizedPrincipalsFile, revê o mapeamento aplicável à conta. Há outros mecanismos de confiar numa CA, como authorized_keys, com regras próprias; não transportes conclusões entre mecanismos sem identificar o caminho efetivo.
Interpretar validade e restrições
Uma tentativa às 10:30 UTC fica fora do intervalo observado. Planeia emissão e renovação para novas autenticações, sem confundir esse intervalo com uma garantia de que todas as sessões abertas terminam à mesma hora. As opções também têm semântica: uma critical option desconhecida causa recusa; uma extension desconhecida pode ser ignorada. Uma restrição obrigatória precisa do mecanismo apropriado e de validação na versão alvo. O clear do laboratório remove permissões por omissão e a inspeção mostra force-command, mas estes campos não demonstram aceitação pelo servidor nem execução do comando.
Preparar a decisão de passagem a operação
O caso final pede um job às 10:30 com o certificado de exercício e um comando diferente. A decisão é corrigir a emissão autorizada e validar conta, confiança, autenticação e comportamento no destino adequado. O sucesso de -L é apenas inspeção local. O registo evidence.json contém versão, comandos, seis grupos de observações e hash do runner; não contém chaves privadas. Resumo: certificado público não substitui posse da chave, confiança na CA não substitui autorização da conta e validade precisa de planeamento. Relaciona esta aula com automatização, menor privilégio, renovação e recuperação de acesso.
O certificado local mostrou principal batch e validade de uma hora; não houve autenticação num servidor.
Armadilhas comuns
Key ID como conta; -L como login; CA confiável como acesso universal; validade como duração de sessão.
Tópicos relacionados: Ligação SSH e identidade do servidor · Autenticação por chave e conta remota · Configuração efetiva e reprodução de falhas
Confirma cada condição de autenticação e autorização antes de depender da credencial num job.
Referência: ssh-keygen(1) · OpenSSH concepts and OpenBSD-current manuals consulted 2026-09-29; distribution defaults vary