wake-up-neo.net

Wirklich ausführliche Möglichkeit zum Testen der Git-Verbindung über SSH?

Bei der Verwendung von GIT habe ich Probleme bei der Verwendung von GIT über SSH , und da es sowohl von der Arbeit als auch zu Hause mit einem anderen Modem einwandfrei funktioniert, reagiert 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 alle "größeren" Befehle (wie fetch, clone oder Push mit vielen Daten) von git (auch wenn sie mit -v ausgeführt werden) nur "hängt" sich mitten in der Fernverbindung auf, ohne dass angegeben wird, warum die Verbindung unterbrochen wurde, sodass sie keinen Nutzen haben.

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

command-linesshgit
104
IQAndreas

Umgebungsvariable

Ab Git Version 2.3.0 können Sie die Umgebungsvariable GIT_SSH_COMMAND verwenden und das ausführliche Argument -v wie folgt übergeben:

GIT_SSH_COMMAND="ssh -v" git clone example

Um besonders ausführlich zu sein, machen Sie es -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
110
Flimm

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  [email protected]:me/test.git (fetch)
Origin  [email protected]: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 DEBUG1, um weniger Debug-Meldungen zu erhalten.

Für GIT-Versionen> = 2.3.0 siehe Antwort von @Flimm für eine intelligentere Lösung.

81
Trendfischer

Wenn Sie man git durchlesen, können Sie einige nützliche Umgebungsvariablen einstellen, GIT_TRACE_PACKET und GIT_TRACE. Zum Beispiel:

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

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

14
bcherny

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.

Versuchen Sie es mit ssh -v. Wenn Sie dadurch nicht wissen, was Sie wissen müssen, können Sie ein oder zwei vs hinzufügen, um noch detailliertere Debugging-Informationen zu erhalten. Versuchen Sie insbesondere für Github ssh -vvvT [email protected].

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.

5
tgies

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.

3
ScoobiFreeBSD