APRENDER. PRATICAR. EVOLUIR.Confirmar a política do certificado numa sessão real
As observações anteriores com ssh-keygen -L mostravam campos locais. Agora certificateAccepted demonstra uma autenticação real com CA confiada, principal adequado e validade temporal. O ficheiro authorized_keys fica vazio nesses ensaios, evitando que a chave simples seja aceite como alternativa quando se pretende avaliar o certificado. O cliente também ignora o agent pessoal e seleciona explicitamente identidade e certificado. Compara o controlo com wrongPrincipal e expiredCertificate. A assinatura pode ser confiável e, ainda assim, a conta ou o momento não satisfazerem a política. No caso fictício Ria, mudar o Key ID não corrigiria o principal emitido para outro consumidor. A ação deve respeitar a autorização pretendida, corrigir a emissão ou um mapeamento aprovado e testar novamente no contexto do job. Não generalizes esta configuração a todas as formas possíveis de mapear principals.
Distinguir uma restrição desconhecida de uma autorização válida
O ensaio unknownCriticalOption emite um certificado com a opção crítica original dr-unknown. O servidor identifica que não a suporta e recusa a autenticação. A assinatura da CA não faz uma implementação aplicar uma condição que desconhece. Esta distinção interessa quando equipas de emissão e operação evoluem em ritmos diferentes. No caso Lago, converter a opção em algo que possa ser ignorado só seria aceitável se a política necessária continuasse efetivamente aplicada por um mecanismo aprovado; não basta obter código zero. Define um teste positivo para a operação permitida e um negativo para a condição que deve ser recusada. O runner usa um campo inventado exclusivamente para observar a rejeição. Não pretende avaliar um produto de emissão, um dispositivo físico, certificados de host ou todas as opções críticas suportadas pela versão.
Tratar a revogação como uma dependência operacional
O certificado válido do controlo é incluído numa KRL temporária. ssh-keygen -Q confirma essa entrada e a instância com RevokedKeys recusa a mesma credencial, apesar de continuar dentro do prazo. O resultado não significa que a KRL reescreveu o certificado; o servidor aplicou uma condição adicional. Numa distribuição real, prepara conteúdo completo e publica-o de forma consistente. O caso Farol acrescenta uma falha de acesso ao ficheiro, analisada documentalmente e não executada pelo runner: uma lista configurada ilegível pode impedir autenticação publickey de todos os utilizadores. A aceitação da reparação deve verificar tanto uma credencial permitida como uma revogada. Remover o controlo para fazer o teste positivo passar não preserva o objetivo. A rotação de uma CA, distribuição em vários servidores e procedimentos de recuperação continuam a exigir ensaios próprios.
Preparar a renovação e a passagem para operação
O guião seguinte propõe quarenta minutos. Primeiro, classifica os resultados do runner por fase e identifica o controlo positivo correspondente a cada recusa. Depois, resolve Cais e Ria: distingue código remoto de autenticação e define como renovar a credencial antes da próxima sessão do job. No terceiro bloco, prepara publicação e rollback da lista de Farol sem perder revogações obrigatórias. No último, decide a aceitação do perfil de Lago e entrega uma matriz de requisito, evidência, responsável e ação pendente. O guião ainda não foi realizado com participantes. Uma ligação de laboratório aceite não prova o comando de negócio, a conta empresarial, o bastion ou o ambiente do agendador. Resumo: a passagem para RUN deve demonstrar acesso autorizado e operação útil, conservando a capacidade de recusar identidades que não cumprem a política.
GUIÃO DE 40 MINUTOS
0–10: classifica os nove resultados por confiança, autenticação e comando.
10–20: resolve Cais e Ria; define diagnóstico e renovação antes da próxima sessão.
20–30: planeia publicação e recuperação da KRL de Farol; inclui testes positivo e negativo.
30–40: decide sobre o perfil de Lago e atribui ações pendentes.
ENTREGÁVEL
Requisito | evidência | teste permitido | teste de recusa | responsável | próximo passo.
EXECUTAR O CÓDIGO DA AULA ANTERIOR
python3 ssh-sessions.py --ssh /caminho/ssh --sshd /caminho/sshd --sshd-session /caminho/sshd-session --sshd-auth /caminho/sshd-auth --keygen /caminho/ssh-keygen --output ssh-sessions-evidence.json
Usa executáveis correspondentes de OpenSSH 10.5p1 e Python 3.
Execução registada: Python 3.13.1, OpenSSH 10.5p1, OpenSSL 3.6.1, compilado sem PAM.
Conta POSIX de laboratório; apenas loopback, chaves temporárias e comando fixo.
Não altera contas, chaves pessoais ou o serviço SSH do sistema.Farol precisa de confirmar que uma credencial permitida entra e uma revogada continua recusada depois de reparar a publicação da lista.
Armadilhas comuns
Testar só a emissão, deixar uma chave alternativa ocultar a recusa, confundir prazo com revogação ou converter uma restrição crítica em algo ignorável sem preservar a política.
Tópicos relacionados: Operação de certificados · Gestão de mudanças e recuperação
A aceitação de acesso precisa de identidade, confiança, autorização e resultado operacional. Os controlos negativos demonstram que as restrições continuam aplicadas.
Referência: OpenSSH server configuration · OpenSSH concepts and OpenBSD-current manuals consulted 2026-09-29; distribution defaults vary