Verbindung mit Git-Repository über SSH: Couldn’t agree a key exchange algorithm

2014 hatte ich mal meinen Workflow beschrieben, wie ich eine Webseite mittels Git aktualisiere. Gefühlt mache ich das mittlerweile öfter als tatsächlich auch mal was zu schreiben, aber das grundsätzliche Konstrukt nutze ich seitdem unverändert und finde es nach wie vor praktisch. Vor ein paar Tagen hat es leider mit dieser Fehlermeldung den Dienst verweigert:

Screenshot

FATAL ERROR: Couldn't agree a key exchange algorithm (available: curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256)
fatal: Could not read from remote repository.

Da musste ich erst mal etwas grübeln, ehe ich auf die Ursache des Problems kam: SourceTree verbindet sich mit dem Git-Repository auf dem Server nicht mittels eines Passwortes, sondern über einen Key. Diesen habe ich vor mehreren Jahren generiert und seitdem nie geändert. Was sich kürzlich geändert hat ist die Akzeptanz veralteter SHA-Algorithmen. Ich nehme stark an, dass das Problem dadurch ausgelöst wurde, dass Domainfactory seit einer Server-Aktualisierung im Herbst veraltete Schlüssel einfach nicht mehr akzeptiert.

Zur Lösung habe ich zwei Sachen probiert und kann nun leider nicht mehr sagen, ob beides nötig gewesen wäre. Fangt am besten mit Schritt 2 an, das geht schneller: Ich habe nämlich mein Schlüsselpaar neu generiert. Erst als das auch keine Verbesserung brachte, kam ich darauf, dass Putty einfach zu alt ist und habe dieses auch aktualisiert.

Hierbei gibt es nun ein spezielles Problem mit SourceTree, dem Windows-Git-Client, den ich verwende. In einem Bug-Report kann man nachlesen, dass SourceTree eine uralte Version der Putty-Tools mitbringt, welche erst demnächst aktualisiert werden sollen. Und tatsächlich, der SSH-Agent, den SourceTree automatisch startet, ist gar nicht die aktuelle Version der Datei aus meiner normalen Putty-Installation, sondern eine mehrere Jahre alte Version des Putty-Tools. Das normale Putty hatte ich nämlich schon als allererstes aktualisiert, was aber nichts gebracht hatte.

SourceTree hat sich bei mir unverständlicherweise hier installiert (Windows 7): C:\Users\[Benutzername]\AppData\Local\SourceTree\app-2.3.5. Das Putty-Tool liegt im Unterordner „tools\putty“. Man kann die exe-Datei einfach gegen die Datei aus dem offiziellen Putty-Download austauschen. Vorher natürlich beides beenden. Wenn man Pech hat, tritt das Problem nach dem nächsten Update von SourceTree natürlich wieder auf, dann muss die Lösung ggf. wiederholt werden.

Der Vollständigkeit halber: Ich habe auch mein Schlüsselpaar aktualisiert und dabei einen größere Schlüssellänge gewählt. Domainfactory lehnt nämlich auch seit kurzem Schlüssel ab, welche kleiner 1024 Bit sind. Ich bin nicht sicher, ob mich das betroffen hätte, mag es jetzt aber auch nicht ausprobieren. Dazu habe ich über das Putty-Tool puttygen.exe einen neuen Schlüssel generiert, den alten in einem anderen Ordner gesichert und den neuen mit dem gleichen Namen an die gleiche Stelle gelegt. In SourceTree war deswegen nichts umzukonfigurieren. Der öffentliche Schlüssel kam dann auf dem Server noch in die Datei ./ssh/authorized_keys.

Mit diesen Änderungen funktioniert die Verbindung nun wieder einwandfrei.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Bitte beachte die Kommentarregeln: 1) Kein Spam, und bitte höflich bleiben. 2) Ins Namensfeld gehört ein Name. Gerne ein Pseudonym, aber bitte keine Keywords. 3) Keine kommerziellen Links, außer es hat Bezug zum Beitrag. mehr Details...

So, noch mal kurz drüber schauen und dann nichts wie ab damit. Vielen Dank fürs Kommentieren! :-)