SSH-agent doorsturen of een sleutel kopiëren: wat er werkelijk lekt

Twee verschillende gebeurtenissen worden een gelekt SSH-sleutel genoemd, en ze vragen om verschillende reacties. Authenticatie met een publieke sleutel verstuurt een publieke sleutel en een handtekening die met de privésleutel is gemaakt, dus de privésleutel is nooit een veld in het verzoek. Agent-doorsturen legt iets anders bloot, want een externe host die bij je doorgestuurde agent kan komen, kan hem om een handtekening vragen zonder de sleutel ooit te hebben. Behandel je beide als één gebeurtenis, dan eindig je ofwel met een nutteloze sleutelwissel ofwel met een delegatie die blijft doorlopen.

Inloggen met een publieke sleutel verstuurt een handtekening, niet de sleutel

De authenticatie-uitwisseling draagt de publieke sleutel van de gebruiker en een handtekening over sessiedata. De server controleert die handtekening met de sleutel die hij al vertrouwt, daarom kan de private helft op de client blijven over een niet-vertrouwd netwerk. Een VPN-beheerder die de tunnel bekijkt, ziet hoe dan ook een versleutelde SSH-sessie.

Dat beschrijft het protocol, niet de betrouwbaarheid van elk eindpunt op de route. Houd de host-identiteitscontrole intact, want een client die elke host-sleutel accepteert, heeft een andere controle opgegeven dan degene die hier wordt besproken. Een onderschepte sessie en een onderschepte sleutel zijn aparte bevindingen, en slechts één ervan is verlies van inloggegevens. Houd ze ook in de rapportage in aparte zinnen.

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh -o StrictHostKeyChecking=yes [email protected]

De eerste opdracht drukt de publieke vingerafdruk af, zodat je die kunt vergelijken met wat de server vermeldt. De tweede maakt de host-sleutelcontrole expliciet in plaats van te vertrouwen op een standaardwaarde die niemand heeft gelezen. Voer beide uit voordat je iets aan sleutels verandert, zodat de uitgangssituatie is gedocumenteerd.

Een agent doorsturen delegeert de mogelijkheid om te ondertekenen

Als doorsturen aan staat, verschijnt er een socket op de externe host en beantwoordt de lokale agent verzoeken die daar binnenkomen. Iedereen die die socket tijdens de sessie kan gebruiken, kan zich als jou authenticeren bij hosts die de geladen identiteiten accepteren. Geen enkele privésleutel steekt het netwerk over om dat te laten werken.

De mogelijkheid is de blootstelling, niet het bestand. Daarom hoort doorsturen bij een benoemde taak en een benoemde host, niet bij elke verbinding die een laptop maakt. Een spronghost die de verbinding doorgeeft zonder doorgestuurde agent, haalt de behoefte meestal helemaal weg.

ssh-add -l
ssh -o ForwardAgent=no [email protected]
ssh -J [email protected] [email protected]

De eerste somt op welke identiteiten de agent op dit moment heeft, wat goed is om te weten voordat je zijn socket aan een andere machine geeft. De tweede verbindt zonder delegatie. De derde toont het patroon van de spronghost dat doorsturen vaak volledig vervangt.

Kies de reactie op basis van het bewijs dat je hebt

Een ondertekeningsidentiteit die als blootgesteld wordt beschouwd, vraagt om het vervangings- en intrekkingsproces, en om het verwijderen van de acceptatie bij de diensten die erop vertrouwden. Het verwijderen van de kopie op je laptop laat elke andere kopie ongemoeid. Begin bij de diensten en ruim daarna de clients op.

Een tijdelijk delegatieprobleem is smaller. Beëindig het doorsturen dat niet nodig was, en neem met de eigenaar van het incident door welke sessies en identiteiten het dekte. Sleutelvervanging kan volgen, maar daarover beslissen bewijzen, niet de zorg.

Geen waargenomen export bewijst alleen dat het mechanisme dat je vreesde niet is opgetreden. Het zegt niets over wat een host aan de andere kant van die socket nog meer had kunnen doen.

Houd de controles apart in het verslag

Bescherm het private materiaal, beperk wie erom kan vragen te ondertekenen, houd de geverifieerde identiteit van de andere partij vast. Dat zijn drie controles die elkaar versterken, en geen ervan vervangt een andere wanneer je uitlegt wat er is gebeurd.

Een gecompromitteerde laptop of een geprivilegieerde toepassing erop is een derde geval met een veel grotere impact. De VPN-route wijzigen lost dat niet op en herstelt het vertrouwen in een sleutel niet dat mogelijk van schijf is gelezen.

Schrijf op welk onderdeel vertrouwd werd, of doorsturen aan stond en wat er werkelijk is waargenomen. Dat verslag is wat de volgende beslissing verdedigbaar maakt in plaats van een gok over wat een lek betekent.