Encaminhamento do agente SSH versus copiar uma chave: o que realmente vaza
O início de sessão com chave pública envia uma assinatura, não a chave privada. O encaminhamento do agente ainda dá a outro host a capacidade de assinar, o que é uma exposição separada.
Dois eventos diferentes recebem o nome de chave SSH vazada, e exigem respostas diferentes. A autenticação com chave pública envia uma chave pública e uma assinatura feita com a chave privada, então a chave privada nunca é um campo do pedido. O encaminhamento do agente expõe outra coisa, porque um host remoto que alcança o seu agente encaminhado pode pedir-lhe que assine sem nunca deter a chave. Tratar os dois como um único evento leva ou a uma rotação inútil ou a uma delegação que continua ativa.
O início de sessão com chave pública transmite uma assinatura, não a chave
A troca de autenticação transporta a chave pública do utilizador e uma assinatura sobre os dados da sessão. O servidor verifica essa assinatura com a chave em que já confia, e é por isso que a metade privada pode permanecer no cliente através de uma rede não confiável. Um operador de VPN que observa o túnel vê uma sessão SSH cifrada de qualquer forma.
Isso descreve o protocolo, não a fiabilidade de cada extremidade do caminho. Mantenha intacta a verificação da identidade do host, porque um cliente que aceita qualquer chave de host abandonou um controle diferente do que discutimos. Uma sessão capturada e uma chave capturada são achados separados, e apenas um deles é perda de credenciais. Mantenha os dois em frases separadas do relatório.
ssh-keygen -lf ~/.ssh/id_ed25519.pub ssh -o StrictHostKeyChecking=yes [email protected]
O primeiro comando imprime a impressão digital pública para que a compare com a que o servidor lista. O segundo torna explícita a verificação da chave do host em vez de confiar num valor predefinido que ninguém leu. Execute ambos antes de mudar qualquer coisa nas chaves, para que a linha de base fique documentada.
Encaminhar um agente delega a capacidade de assinar
Com o encaminhamento ativo, aparece um socket no host remoto e o agente local responde aos pedidos que chegam por ele. Qualquer pessoa que possa usar esse socket durante a sessão pode autenticar-se como você perante hosts que aceitem as identidades carregadas. Nenhuma chave privada atravessa a rede para que isso funcione.
A exposição é a capacidade, não o ficheiro. Por isso o encaminhamento pertence a uma tarefa nomeada e a um host nomeado, e não a cada ligação que um portátil faz. Um host de salto que reencaminha a ligação sem agente encaminhado normalmente elimina a necessidade por completo.
ssh-add -l ssh -o ForwardAgent=no [email protected] ssh -J [email protected] [email protected]
O primeiro lista que identidades o agente tem neste momento, algo que vale a pena saber antes de entregar o seu socket a outra máquina. O segundo liga-se sem delegação. O terceiro mostra o padrão de host de salto que muitas vezes substitui o encaminhamento por completo.
Escolha a resposta com base nas provas que tiver
Uma identidade de assinatura que se acredita exposta exige o processo de substituição e revogação, e a remoção da sua aceitação dos serviços que nela confiavam. Apagar a cópia no portátil deixa todas as outras cópias intactas. Comece pelos serviços e depois limpe os clientes.
Um problema temporário de delegação é mais estreito. Termine o encaminhamento que não era necessário e reveja com o responsável pelo incidente que sessões e identidades cobria. A substituição da chave pode seguir, mas são as provas que decidem, não a preocupação.
A ausência de exportação observada prova apenas que o mecanismo que temia não apareceu. Não diz nada sobre o que mais um host do outro lado desse socket poderia ter feito.
Mantenha os controles separados no relatório
Proteja o material privado, limite quem lhe pode pedir uma assinatura, mantenha verificada a identidade da outra parte. São três controles que se reforçam mutuamente, e nenhum deles substitui o outro quando explica o que aconteceu.
Um portátil comprometido ou uma aplicação com privilégios nele é um terceiro caso, com um alcance muito maior. Mudar a rota VPN não o resolve e não restaura a confiança numa chave que pode ter sido lida do disco.
Anote qual componente era de confiança, se o encaminhamento estava ativo e o que foi realmente observado. É esse registo que torna a decisão seguinte defensável, em vez de uma conjectura sobre o que significa uma fuga.