APRENDER. PRATICAR. EVOLUIR.Distingue as identidades em cada salto
ProxyJump permite alcançar um destino através de uma ligação SSH a um salto intermédio. O cliente autentica no salto, pede um canal TCP para o destino e estabelece a sessão SSH final através desse caminho. O destino conserva a sua verificação de identidade e autenticação de conta. Não é necessário copiar a chave privada para o bastion. O laboratório usa duas identidades locais explicitamente selecionadas, IdentityAgent none e ForwardAgent no. As configurações dos aliases jump e target indicam portas e IdentityFile distintas. Opções dadas ao destino não se aplicam geralmente ao salto. Num job, compara ambos os contextos: conta local executora, ficheiros lidos, argumentos, identidades, contas remotas e referências de confiança.
Usa controlos negativos para localizar a fase
jumpAllowed autentica nos dois servidores locais e o destino imprime fixedTarget=true. jumpWrongKey oferece a chave errada ao primeiro salto: não há aceitação no salto nem execução final. targetWrongKey aceita o primeiro salto, mas o servidor final rejeita a identidade selecionada para target. jumpForwardDenied aceita a conta do salto e bloqueia o canal TCP, antes da autenticação no destino. Os quatro resultados têm consequências diferentes para o diagnóstico. Uma recusa de canal aponta para políticas como AllowTcpForwarding e PermitOpen; uma rejeição final de chave aponta para conta e autorização no destino. Não uses apenas o código 255 para atribuir causa. Correlaciona mensagens do cliente e logs separados dos dois servidores.
Converte o laboratório em critérios de mudança
Os dois servidores usam loopback na mesma máquina e partilham uma chave de host descartável para simplificar a fixture. Isso não representa isolamento de rede, gestão de identidades ou confiança de uma infraestrutura bancária real. O laboratório demonstra mecanismos e fases, sem aceitar uma migração produtiva. Para uma mudança autorizada, identifica cada host, porta, conta, referência de confiança, identidade cliente e destino permitido. Acrescenta testes positivos e negativos, janela, responsável, observação e reversão. A aceitação deve incluir o contexto do agendador e uma operação da aplicação com resultado esperado. Confirma também limites de tempo, tratamento de falhas e efeitos parciais antes de repetir operações financeiras. Os exemplos de bancos são fictícios e não representam políticas BNP Paribas.
Pratica a decisão e prepara a passagem para RUN
Usa o guião abaixo numa sessão de quarenta minutos: oito minutos para mapear extremos, doze para comparar falhas, doze para decidir correções e oito para preparar aceitação. O responsável de suporte localiza a fase; o gestor coordena proprietário, âmbito e janela; o revisor exige evidência de sucesso e recusa. Começa com Ria, onde o listener está saudável e o backend indisponível. Passa para Farol, onde só a autenticação final falha, e Lago, onde a escuta remota não foi autorizada. Entrega um mapa de acesso, uma decisão justificada e critérios de passagem para RUN. A execução com participantes ainda não foi realizada. Resume sempre o que foi observado, o que foi inferido e o que continua por validar no ambiente real. A passagem deve indicar quem recebe cada alerta e que evidência permite distinguir acesso indisponível de aplicação indisponível. Regista um prazo de revisão do acesso temporário.
GUIÃO DE 40 MINUTOS: ENCAMINHAMENTO E BASTIONS
Casos fictícios; não representam políticas de qualquer banco.
Código completo: aula Encaminhamento SSH e provas de serviço.
Pré-requisitos: Python 3, POSIX, conta local não-root utilizável,
cinco binários correspondentes OpenSSH 10.5p1. Build executado sem PAM.
Substituir /path/to pelos caminhos reais dos executáveis autorizados.
O runner abre apenas loopback e remove processos e chaves temporárias.
EXECUÇÃO
python3 run.py \
--ssh /path/to/openssh-10.5p1/ssh \
--sshd /path/to/openssh-10.5p1/sshd \
--sshd-session /path/to/openssh-10.5p1/sshd-session \
--sshd-auth /path/to/openssh-10.5p1/sshd-auth \
--keygen /path/to/openssh-10.5p1/ssh-keygen \
--output evidence.json
0–8 MINUTOS: MAPA
Por extremo: listener, destino, porta, conta, identidade, confiança.
Indicar quem inicia a ligação final em -L e -R.
8–20 MINUTOS: EVIDÊNCIA
Ria: listener ativo, Connection refused, backend sem escuta.
Farol: salto Accepted publickey, destino Failed publickey.
Lago: conta aceite, remote port forwarding failed, PermitListen none.
Para cada caso: fase observada, hipótese, confirmação ainda necessária.
20–32 MINUTOS: DECISÃO
Responsável, correção dentro do âmbito, controlo positivo e negativo.
Não ampliar para any sem uma nova decisão de acesso autorizada.
Não repetir operações financeiras sem verificar efeitos parciais.
32–40 MINUTOS: ACEITAÇÃO
Operação autorizada no contexto do job, resultado, prazo e reversão.
Distinguir marcador da fixture de aceitação TLS e aplicacional.
Entrega: mapa, decisão, evidência e lacunas para RUN.
Guia ainda não executado com participantes.
Farol aceita a conta do salto e rejeita a chave no destino. O diagnóstico mantém o salto funcional e compara a configuração do alias target no contexto do agendador.
Armadilhas comuns
Rodar a chave do salto quando a falha está no destino, ativar agent forwarding sem necessidade, confundir confiança no bastion com confiança no destino ou declarar aceitação real com loopback.
Tópicos relacionados: Gestão de mudanças · Suporte de produção L3
Uma ligação via bastion contém decisões distintas de confiança, autenticação e canal. A passagem para RUN precisa de evidência do percurso real e da operação consumidora.
Referência: OpenSSH forwarding and jump hosts · OpenSSH concepts and OpenBSD-current manuals consulted 2026-09-29; distribution defaults vary