Ohai, weil mich das gerade auch noch im Detail interessiert hat, nochmal kurz zwei Links: In [0] wird beschrieben, dass der Client zur Authentifizierung gegenüber dem Server u.a. einen session identifier signiert. Nach [RFC4252] ist der session indentifier der "exchange hash H" des ersten key exchange, in den nach [RFC4253] für DH und [RFC5656] für ECC der öffentliche Key des Servers einfließt. Solange der MITM also nicht den privaten Key des Zielservers hat, kann er den Client nur einen session identifier signieren lassen, für den er die restlichen sessionkeys nicht kennt (bei passivem MITM, also nur Mitschneiden) oder bei dem dann der public key des echten Servers nicht enthalten ist (aktives MITM). Gruß Markus [0] <https://www.gremwell.com/ssh-mitm-public-key-authentication> [RFC4252] <https://tools.ietf.org/html/rfc4252> [RFC4253] <https://tools.ietf.org/html/rfc4253#page-23> [RFC5656] <https://tools.ietf.org/html/rfc5656#page-7> On 17.04.20 13:22, Florian Kerber wrote:
Das waere kein Problem.
Zum einen hast du ja den Fingerprint des Servers, und beim Mismatch geht die Verbindung nicht weiter.
Selbst wenn du den ignorierst, waere das mit Pubkey-Auth kein Problem. Das Ding macht Challenge-Response und der gesignedte Blob hat u.a. auch teile deiner und der Server-Nonce drinne. Da funktioniert kein MITM. Schon versucht :D
Viele Gruesse
Florian
On Fri, 17 Apr 2020 13:16:19 +0200 Frank Knoben <admin@igpm.rwth-aachen.de> wrote:
Und kann mir mal einer sagen, ob der key nicht auch abgefangen werden kann?
Wenn ich mich beim ssh vertippe, z.b server.rwth-aache.de und die Adresse ist gerade registriert und hört auf port 22 zu.
Viele Grüße
Frank Knoben _______________________________________________ rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de
rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de