GIT: „the remote end hung up unexpectedly“ WTF?

Es gibt Dinge zwischen Windows und Linux die muss man nicht verstehen, vor allem nicht, wenn es keine Logfiles mit Einträgen gibt. Aktueller Fall war unsere Versionverwaltung mit GIT. GIT-Server läuft hier im Netz auf Linux, alles wunderbar. Allerdings kam dann aus dem nichts beim clone, commit, push die Meldung „fatal: the remote end hung up unexpectedly“.

Das größte Problem bei der Sache war das Problem, das weder mein Windows Event Log, noch das Logfile des Servers irgendwas zu dem Thema zu sagen hatte. Auch eine „verbose“ Ausgabe mit -v brachte nur den Pfad des push, aber der war mir auch so schon klar.

Aber wie sah meine Konstellation eigentlich genau aus? Client ist ein PC mit Windows XP, GIT-Server ist eine VM mit Suse Linux Enterprise. Zur Authentifizierung habe ich auf meinem Client einen öffentlichen Schlüssel erstellt und wie üblich am Server in den „.ssh/authorized_keys“ eingetragen. Lief ja auch alles.

Nur eben jetzt nicht mehr. Nach vielen Suchanfragen in Google kam ich langsam aber sicher in die richtige Richtung: Dass die Authentifizierung nicht mehr klappt. (könnte man ja auch mal irgendwo ausgeben oder mitloggen…)

Alle Versuche es wieder hinzubringen brachten keine wirkliche Lösung. Bis ich auf folgende Seite gestoßen bin: How to set up SSH keys: Frustration with „Server refused our key“

Eigentlich steht da nicht viel mehr, als dass man doch bitte das Thema umdrehen soll und die Schlüsselpaare auf dem Windows Client erstellt, sondern einfach auf dem Linux Server. Und so geht man vor:

Zuerst prüfen wir auf dem Server, ob die Ordner des Users die richtigen Rechte haben. Unter /home/username/ gibts einen Ordner .ssh der sollte mit 700 ausgestattet sein, wenn nicht:

chmod 700 .ssh

Jetzt schauen wir uns noch die /home/username/.ssh/authorized_keys Datei an. Diese sollte mit 600 daherkommen. Wenn nicht:

chmod 600 authorized_keys

Jetzt gehts los, wir erzeugen uns ein Schlüsselpaar auf dem Server (wichtig mit dem betroffenen User müsst ihr eingeloggt sein!) am Besten im Ordner /home/username/.ssh/:

ssh-keygen -t dsa

Den Ordner, den das Programm vorschlägt kann man beibehalten. Es wird nach einem Passwort gefragt, idealerweise sollte man hier ein sehr starken Passwort hinterlegen, ABER ihr werdet bei jeder Verwendung des Schlüssels dann immer nach dem Passwort gefragt. Ist also eine Geschmacks- und Sicherheitsfrage.

So jetzt haben wir die beiden Schlüsseldateien. Nun fügen wir den öffentlichen Schlüssel den wir haben in die „authorized_keys“ Datei ein. Mit dem MC, oder WinSCP, wie man mag, oder eben auf der Console:

cat id_dsa.pub >> authorized_keys

Auf dem Server sind wir soweit fertig. Jetzt müßt ihr den privaten Schlüssel „id_dsa“ auf den Windows Rechner kopieren. Mit WinSCP z.B.

Und weiter gehts auf eurem Windows Rechner, wir brauchen folgende Dateien: putty.exe und puttygen.exe, beides gibt es hier: PuTTY Download Page

Also Puttygen.exe öffnen und auf „Load“ klicken, die soeben kopierte id_rsa Datei auswählen, Passwort eingeben und hoffentlich folgende Meldung bekommen:

Jetzt hat Putty den private Key zu etwas verarbeitet, was er auch versteht und ihr müsst den Schlüssel jetzt speichern mit „save private key“. Wenn man kein Passwort verwendet hat sollte man einen sicheren Ort zum Speichern wählen! Der sich am Besten nach eurem Entfernen in 5 Sekunden selbst zerstört 😉

So jetzt müssen wir Putty nur noch noch sagen, dass er bei Verbindungen mit dem GIT-Server diesen neuen Private Key nimmt. Also putty.exe öffnen und die Verbindungsdaten eintragen in der Form: username@host

Aber noch nicht „Open“ klicken, sondern unter „Connection/SSH/Auth“ müßt ihr jetzt noch die eben gespeicherte Private Key Datei angeben.

immer noch nicht auf „Open“ klicken! Sondern oben auf Session, damit wir das ganze auch speichern können!

Also Namen vergeben und „Save“ klicken. So und jetzt? Richtig! JETZT darf man auf Open klicken 🙂 Wenn alles richtig war sollte die SSH Verbindung wie gewohnt ohne Passwortabfrage (außer für euren Key) auskommen.

Alles geklappt? Perfekt! So jetzt versuchen wir nochmal unseren git push. Und siehe da!

Ich hoffe, ihr konntet mit der Anleitung etwas anfangen und sie hilft das ein oder andere Verbindungsproblem zu lösen.

Fragen? Kritik? Lob? Dann einfach einen Kommentar hinterlassen 🙂