Bei der Verwendung von GIT habe ich Probleme mit der Verwendung von GIT über SSH , und da es sowohl von der Arbeit als auch von zu Hause mit einem anderen Modem aus einwandfrei funktioniert, funktioniert offensichtlich mein Heimmodem. Ich habe keine Probleme mit der Verbindung über HTTP.

Ich gehe also davon aus, dass es sich um ein SSH-Problem handelt, bin aber kein Experte darin, es direkt zu verwenden. Gibt es einen Befehl, den ich ausführen kann, um eine "Test" -Verbindung einzurichten, und der mich genau darüber informiert, wann und wo das Problem auftritt?

So ziemlich all „größere“ Befehle (wie fetch, cloneoder pushmit vielen Daten) von git(auch bei der Ausführung mit -v) nur „hängen“ in der Mitte des Remote - Verbindung ohne Hinweis darauf, warum sie aufgehört haben, so dass sie nicht von Nutzen .

Kann ich auf irgendeine Weise mehr Details darüber erfahren, was in der SSH-Verbindung geschieht?

Umgebungsvariable

Ab Git Version 2.3.0 können Sie die Umgebungsvariable verwenden GIT_SSH_COMMANDund das -vausführliche Argument wie folgt übergeben:

GIT_SSH_COMMAND="ssh -v" git clone example

Um besonders ausführlich zu sein, machen Sie Folgendes -vvv:

GIT_SSH_COMMAND="ssh -vvv" git clone example

Git config

Ab Git Version 2.10.0, die in den Repos von Ubuntu 17.04 verfügbar ist, können Sie diese Konfiguration global oder pro Repo wie im folgenden Beispiel speichern:

git config core.sshCommand "ssh -vvv"
git pull

Ich hatte ein ähnliches Problem. Zum Debuggen habe ich eine Zeile in meine ssh_config eingefügt. So habe ich es gemacht:

git remote -v

Dort finden Sie eine Zeile wie diese:

origin  git@github.com:me/test.git (fetch)
origin  git@github.com:me/test.git (push)

In diesem Fall ist der Host github.com. Nun können Sie einen Host-Eintrag in Ihre SSH-Konfiguration einfügen:

vim ~/.ssh/config

Und füge hinzu:

Host github.com
    LogLevel DEBUG3

Wenn Sie Git-Operationen verwenden, sollten Sie jetzt viele Debug-Meldungen erhalten. Verwenden Sie, um weniger Debug-Meldungen zu erhaltenDEBUG1

Für GIT-Versionen> = 2.3.0 finden Sie in der Antwort von @Flimm eine intelligentere Lösung.

Lesen durch man git, gibt es einige nützliche Umgebungsvariablen Sie festlegen können, GIT_TRACE_PACKETund GIT_TRACE. Zum Beispiel:

GIT_TRACE_PACKET=true git clone ssh://[...]

Ein bisschen zu spät zum Spiel, aber hoffentlich hilft das jemandem!

Per man ssh:

 -v      Verbose mode.  Causes ssh to print debugging messages about its progress.  This
         is helpful in debugging connection, authentication, and configuration problems.
         Multiple -v options increase the verbosity.  The maximum is 3.

Also versuchen Sie es ssh -v. Wenn Sie dadurch nicht wissen, was Sie wissen müssen, können Sie ein oder zwei vSekunden hinzufügen, um noch detailliertere Debugging-Informationen zu erhalten. Versuchen Sie es insbesondere für Github ssh -vvvT git@github.com.

Nach meiner Erfahrung kommt es normalerweise zu einer SSH-Sitzung, die während des Setups hängt, wenn der Client die ausgewählte Authentifizierungsmethode nicht ausführen kann. Stellen Sie sicher, dass sich Ihr privater Schlüssel am richtigen Ort mit den richtigen Berechtigungen befindet und mit dem öffentlichen Schlüssel übereinstimmt, den Sie Github gegeben haben.

Ich sehe keine Möglichkeit, git (1) den externen Befehl mitzuteilen, der für ssh (1) verwendet werden soll, aber als Problemumgehung benenne einfach / path / to / ssh in /path/to/ssh.orig um und erstelle eine Shell Skript-Wrapper / path / to / ssh und füge die -v Flags hinzu:

$ sudo mv /usr/bin/ssh /usr/bin/ssh.orig
$ sudo vim /usr/bin/ssh
$ cat /usr/bin/ssh
#!/bin/sh

if [ -x /usr/bin/ssh.orig ]; then
    exec /usr/bin/ssh.orig -v -v -v "${@}"
fi

$ sudo chmod a+x /usr/bin/ssh

Ich erhalte eine ausführliche Ausgabe, wenn ich Git-Befehle ausführe, die über einen ssh-Transport ausgeführt werden. Löschen Sie nach dem Debuggen das Skript und stellen Sie /path/to/ssh.orig in / path / to / ssh wieder her.