Lors de l’utilisation de GIT, j’ai problèmes d’utilisation de GIT sur SSH , et comme cela fonctionne très bien à partir du travail et à la maison avec un modem différent, c’est évidemment mon modem domestique qui fonctionne. Je n'ai aucun problème à me connecter via HTTP.
Donc, je suppose que c'est un problème SSH, mais je ne suis pas un expert pour l'utiliser directement. Existe-t-il une commande que je peux exécuter qui établit une connexion "test" et me permet de savoir exactement quand et où le long de la ligne le problème survient?
Pratiquement toutes les commandes "plus grandes" (telles que fetch
name__, clone
ou Push
avec beaucoup de données) à partir de git
(même lorsqu'elles sont exécutées avec -v
), "suspendez" au milieu d'une connexion distante sans indication indiquant pourquoi elles se sont arrêtées, alors ils ne sont d'aucune utilité.
Est-il possible d'obtenir plus de détails sur ce qui se passe dans la connexion SSH?
À partir de la version 2.3.0 de Git, vous pouvez utiliser la variable d'environnement GIT_SSH_COMMAND
et transmettre l'argument -v
verbose comme suit:
GIT_SSH_COMMAND="ssh -v" git clone example
Pour être plus prolixe, faites-le -vvv
:
GIT_SSH_COMMAND="ssh -vvv" git clone example
À partir de la version 2.10.0 de Git, qui figurera dans le dépôt d'Ubuntu 17.04, vous pouvez enregistrer cette configuration globalement, ou par dépôt comme dans cet exemple:
git config core.sshCommand "ssh -vvv"
git pull
J'avais un problème similaire. Pour le débogage, j'ai ajouté une ligne dans mon ssh_config. Voici comment je l'ai fait:
git remote -v
Vous y trouverez une ligne comme celle-ci:
Origin [email protected]:me/test.git (fetch)
Origin [email protected]:me/test.git (Push)
Dans ce cas, l'hôte est github.com
. Vous pouvez maintenant ajouter une entrée d’hôte dans votre configuration ssh:
vim ~/.ssh/config
Et ajouter:
Host github.com
LogLevel DEBUG3
Lors de l’utilisation des opérations git, vous devriez maintenant recevoir beaucoup de messages de débogage. Pour obtenir des messages de débogage moins importants, essayez d'utiliser DEBUG1
Pour versions GIT> = 2.3.0 , consultez le réponse de @Flimm pour une solution plus intelligente.
En parcourant man git
, vous pouvez définir certaines variables d’environnement utiles, GIT_TRACE_PACKET
et GIT_TRACE
. Par exemple:
GIT_TRACE_PACKET=true git clone ssh://[...]
Un peu tard dans le match, mais j'espère que cela aidera quelqu'un!
Par 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.
Alors, essayez ssh -v
. Si cela ne vous dit pas ce que vous devez savoir, vous pouvez ajouter un ou deux v
s pour des informations de débogage encore plus détaillées. Pour Github en particulier, essayez ssh -vvvT [email protected]
.
D'après mon expérience, une session SSH est suspendue lors de l'installation lorsque le client ne peut pas exécuter la méthode d'authentification choisie. Vérifiez que votre clé privée est au bon endroit avec les autorisations appropriées et correspond à la clé publique que vous avez fournie à Github.
Je ne vois pas comment indiquer à git (1) la commande externe à utiliser pour ssh (1), mais comme solution de contournement, renommez simplement/path/to/ssh en /path/to/ssh.orig, créez un shell script wrapper/path/to/ssh, et ajoutez les drapeaux -v:
$ 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
Je reçois une sortie commentée en exécutant des commandes git opérant sur un transport ssh. Une fois le débogage terminé, supprimez le script et restaurez /path/to/ssh.orig dans/path/to/ssh.