it-swarm.com.de

Warum stimmen die Fingerabdrücke der gitlab SSH Host-Schlüssel nicht überein?

Ich habe versucht, mich über SSH in das Gitlab meiner Universität einzuloggen. Wie erwartet wurde ich gewarnt, dass der Host nicht bekannt ist. Daher habe ich versucht, den SSH-Host-Schlüssel auf der Seite "Aktuelle Konfiguration" im Handbuch zu finden. Ich habe jedoch festgestellt, dass der Schlüssel nicht mit dem Schlüssel übereinstimmt, den SSH mir bei der ersten Verbindung anzeigt.

Um dies zu demonstrieren, finden Sie hier die entsprechende Seite "instance_configuration" für gitlab.com. Der RSA-SHA256-Fingerabdruck soll sein

2fdd0c7dfa7d9381f847266c800eafc96f5866fe859c4f1cf87da885c82e333a

Mit dem Skript, das ich auf diesem Superuser-Beitrag gefunden habe (oder wenn ich zum ersten Mal eine Verbindung über SSH herstelle), wird mir gesagt, dass der RSA-SHA256 für den SSH-Host ist

ROQFvPThGrW4RuWLoL9tq9I9zJ42fK4XywyRtbOz/EQ

welches ist

44e405bcf4e11ab5b846e58ba0bf6dabd23dcc9e367cae17cb0c91b5b3b3fc44

in hexadezimal (und stimmt hoffentlich mit dem überein, was Sie sehen ... oder nicht).

Meine Fragen: Sollten diese nicht gleich sein? Habe ich etwas verpasst? Wie kann ich überprüfen, ob die SSH-Verbindung sicher ist?

13
HerpDerpington

Dafür gibt es eine Vielzahl von Gründen:

  1. Hosting-Speicherort. Gitlab kann heruntergeladen und an anderer Stelle gehostet werden. Die auf der Seite von gitlab veröffentlichten Host-Schlüssel haben keine Bedeutung, wenn Ihre Universität eine eigene Version von gitlab hostet. In diesem Fall würden Sie niemals den Host-Schlüssel von gitlab sehen - Sie würden den Host-Schlüssel für Ihren Universitätsserver sehen, und der Unterschied wäre bedeutungslos. Sie müssten die Universität nach ihrem Host-Schlüssel fragen, und es ist sehr unwahrscheinlich, dass Sie eine Antwort von ihnen erhalten.
  2. Veraltete Informationen Der Host-Schlüssel für Gitlab hat sich möglicherweise geändert und sie haben einfach vergessen, diese Hilfeseite entsprechend zu aktualisieren.
  3. MitM Jemand könnte einen MitM-Angriff auf Ihren Computer ausführen und den Datenverkehr von gitlab auf seinen eigenen bösartigen Server umleiten.

Ich denke, Option 1 ist erwähnenswert, da nicht ganz klar ist, ob die Gitlab-Seite Ihrer Universität mit Gitlab oder Ihrer Universität gehostet wird. Es hört sich so an, als ob es von Gitlab gehostet wird, aber es ist nicht unbedingt so (offensichtlich sollte die Repo-URL dies klarstellen).

Die Möglichkeit von MitM

Von allen drei Optionen ist # 3 bei weitem am unwahrscheinlichsten. Ein erfolgreicher MitM-Angriff kann in diesem Fall sowohl schwierig sein als auch wenig wirklichen Nutzen haben (für einen Angreifer), so dass es mir nicht einmal in den Sinn kommen würde, ihn unter normalen Umständen in Betracht zu ziehen. Wenn Sie also nicht versuchen, eine Verbindung zu einem Remote-Gitlab-Repository herzustellen, damit Sie Statusgeheimnisse übertragen können, haben Sie es wahrscheinlich nur mit den Optionen 1 oder 2 zu tun.

Sie können auch versuchen, die Wahrscheinlichkeit von MitM zu überprüfen, indem Sie die IP-Adresse des Servers überprüfen, zu dem Sie eine Verbindung herstellen, und herausfinden, ob er zu gitlab gehört. Gitlab hat eine (wahrscheinlich auch alte) Liste ihrer IP-Adressen:

https://gitlab.com/gitlab-com/infrastructure/issues/434

Keine Garantie für eine Übereinstimmung, auch nicht für eine gültige Gitlab-Verbindung, da möglicherweise veraltete Dokumente vorhanden sind. Auch keine Garantie, da jemand, der ein erfolgreiches MitM ausführt, möglicherweise (abhängig von den Details) auch eine IP-Adresse fälschen könnte.

Höchstwahrscheinliches Szenario

Unabhängig davon ist MitM (IMO) sehr unwahrscheinlich, und als Ergebnis würde ich einfach Ihr Ding machen. Sie sollten in der Lage sein, früh genug herauszufinden, ob es ein Problem gibt. Vermutlich stellen Sie eine Verbindung zum gitlab-Server her, suchen die Dateien, die Sie voraussichtlich finden, kopieren eigene Inhalte und können dann mit jedem, mit dem Sie zusammenarbeiten, überprüfen, ob er eine Kopie Ihrer Arbeit erhalten hat. Wenn ja, gibt es definitiv nichts zu befürchten.

Im Allgemeinen deuten meine Erfahrungen darauf hin, dass sich nur wenige Unternehmen die Mühe machen, Hostschlüssel zur Überprüfung zu veröffentlichen. Host-Schlüssel können sicherlich verwendet werden, um einen Server zu überprüfen, mit dem Sie noch nie eine Verbindung hergestellt haben, aber in der Praxis finde ich das nicht besonders häufig. Ich vermute, dass dies hauptsächlich auf die Gründe zurückzuführen ist, die ich oben kurz erwähnt habe: Ich glaube nicht, dass dies ein häufiger Angriffsvektor ist, und Sie können normalerweise ziemlich leicht herausfinden, ob Sie mit dem richtigen Server verbunden sind, einfach weil fast immer mehr Parteien beteiligt sind um Ihre Ergebnisse zu überprüfen. Infolgedessen habe ich am häufigsten die Hostschlüsselüberprüfung verwendet, um festzustellen, wann sich der Server geändert hat, und ich verwende sie selten (wenn überhaupt), um einen Server bei der ersten Verbindung zu überprüfen.

3
Conor Mancone

TL; DR - Ich glaube, das ist überhaupt kein Grund zur Sorge. Wenn Sie immer noch besorgt sind, wenden Sie sich an GitLab. Ich bezweifle, dass Ihnen hier jemand eine Antwort geben kann, da wir dies nicht tun. Ich arbeite dort nicht.


Persönlich glaube ich nicht, dass Ihnen hier jemand helfen wird. Ich glaube, Ihre beste Chance, hier eine Antwort zu erhalten, besteht darin, sich an den Support von GitLab zu wenden. Auf diese Weise erhalten Sie die richtige Antwort.

Ich glaube nicht, dass Sie Grund zur Sorge haben, ob die Verbindung sicher ist. Laut Semsos Kommentar ist es wahrscheinlich kein Sie Problem, wenn das Sinn macht.

Ich würde mir darüber keine Sorgen machen, wenn Sie immer noch besorgt sind, wenden Sie sich an GitLab. Ich bin sicher, dass sie Ihnen gerne weiterhelfen werden.

1
J.J