git produit Gtk-WARNING: impossible d'ouvrir l'affichage

138

J'ai travaillé sur mon projet à distance via la ligne de commande sur une machine sur laquelle je n'ai pas de droits d'administrateur et après l'exécution, git push origin masterj'obtiens le message d'erreur suivant:

(gnome-ssh-askpass:29241): Gtk-WARNING **: cannot open display:

Mon .git/configfichier a le contenu suivant:

    [core]
       repositoryformatversion = 0
       filemode = true
       bare = false
       logallrefupdates = true 
    [remote "origin"]
       fetch = +refs/heads/*:refs/remotes/origin/*
       url = https://username@github.com/username/repository.git 
    [branch "master"]
       remote = origin
       merge = refs/heads/master

J'obtenais l'erreur 403 plus tôt. Suite au commentaire ici , j'ai mis mon nom d'utilisateur avant le signe @ dans l'url distante et depuis, j'obtiens l'erreur Gtk.

Lorsque je me connecte à la machine en utilisant ssh -Xet que j'essaye de pousser, j'obtiens l'erreur suivante:

X11 connection rejected because of wrong authentication.
(gnome-ssh-askpass:31922): Gtk-WARNING **: cannot open display:localhost:10.0

Si je change l'URL de la télécommande en git@github.com:username/repository.git, l'erreur est:

ssh: connect to host github.com port 22: Connection timed out
fatal: The remote end hung up unexpectedly

Savez-vous comment résoudre ce problème?

— John Manak
source

2

Je suppose que vous utilisez ssh. Utilisez plutôt ssh -X. Cela signifie qu'une boîte de dialogue de mot de passe essaie de s'ouvrir, mais n'a pas pu car il n'y a pas de X.

— positron

Merci, mais je n'utilise pas ssh explicitement, j'appelle simplement git push origin master, donc je ne sais pas comment appliquer ce que vous dites?

— John Manak

Puis-je savoir d'où vous poussez vers le serveur? Je veux dire de quelle machine? Comment vous êtes-vous connecté à cette machine?

— positron

1

Oups. Désolé. Je n'ai pas entièrement lu votre question. Votre "url" doit être git@github.com:username/repo.gitou https://github.com/username/repo.gitMais vous utilisez un mélange des deux.

— positron

Oh désolé, je comprends ce que tu veux dire maintenant. J'ai essayé de me connecter à la machine en utilisant ssh -X, mais cela n'a pas aidé non plus. Voir la question mise à jour ci-dessus.

— John Manak

336

J'ai enfin découvert une solution au problème. Comme cela a été décrit ici , j'ai exécuté la commande suivante dans le terminal:

  unset SSH_ASKPASS

puis courir git push origin masterfonctionne comme il se doit. Vous pouvez également ajouter la ligne à votre .bashrcfichier.

— John Manak
source

5

Merci ... qui a sauvé beaucoup de temps. Bless you

— Poonam Bhatt

Merci pour ça! :-)

— ItayB

1

Merci .. cela a fonctionné pour moi! J'obtenais une erreur similaire en essayant de cloner de bitbucket vers une machine Linux.

— Blesson Jose le

2

Je voulais juste ajouter que c'était ce script définissant cette variable sur mon système CentOS 6.7: /etc/profile.d/gnome-ssh-askpass.sh

— hshib

Maintenant, je reçois unerror: RPC failed; result=22, HTTP code = 417

— pmiranda

19

J'ai récemment traité de ce comportement sur une machine RedHat 5 où notre version Git était 1.7.4.1.

Je n'avais pas un degré élevé de confiance qui unset SSH_ASKPASSn'aurait pas de conséquences inattendues, alors je voulais voir s'il y avait une autre solution.

Je ne pouvais pas le dire avec certitude, mais il semble qu'un correctif pour ce problème était en cours de préparation à peu près au moment où notre version de Git avait été publiée. Il m'a donc semblé raisonnable d'espérer qu'une version plus récente corrigerait le comportement.

Et c'est effectivement le cas. La mise à niveau vers la branche 1.8 de Git a résolu le problème. Le message d'erreur est toujours affiché pour une raison étrange, mais vous êtes correctement invité à entrer votre mot de passe et autorisé à continuer.

— eikonomega
source

2

Le problème dans RHEL 5 (CentOS 5 etc.) se trouve dans le fichier /etc/profile.d/gnome-ssh-askpass.sh (appartenant au package openssh-askpass) où la variable d'environnement SSH_ASKPASS est définie aveuglément sur / usr / libexec / openssh / gnome-ssh-askpass et cela ne fonctionne pas s'il n'y a pas de X (c'est-à-dire connecté via PuTTY via SSH). Vous pouvez simplement commenter la ligne dans ce fichier (ne supprimez pas le fichier ou il sera récupéré après la mise à jour du package openssh-askpass). Ou supprimez complètement le paquet openssh-askpass (yum remove openssh-askpass).

— Milan Kerslager

0

Aucune de ces réponses n'a fonctionné pour moi (ssh'ing via Cygwin sur Windows 10 dans un serveur RHEL 6.8 et essayer de cloner un repo github.com à partir de la boîte RHEL) donc ce que j'ai fait a été cloné via une clé SSH plutôt que le nom d'utilisateur HTTPS / mot de passe. par exemple, j'ai utilisé git@github.com: MyUsername / myproject.git plutôt que l'url https. J'ai également correctement téléchargé ma clé publique dans Github. Cette méthode a bien fonctionné.

Remarque: parmi les solutions ci-dessus, je n'ai en fait pas essayé de mettre à niveau vers la branche 1.8 de git

— johnsimer
source

0

Vous pouvez également essayer de vous connecter en utilisant ssh -Y au serveur distant afin que la boîte de dialogue puisse apparaître graphiquement.

Comme l'OP, la connexion via ssh -X ne fonctionnait pas. En essayant de pousser, le serveur a simplement répété le même message d'erreur - (gnome-ssh-askpass:29241): Gtk-WARNING **: cannot open display:- comme il l'a fait lors de la journalisation via ssh sans transfert X11. C'est un comportement légèrement différent de ce que l'OP a signalé lorsqu'il a essayé ssh -X car son message d'erreur a légèrement changé par rapport à l'utilisation de ssh.

Cependant, pour moi, une fois connecté en utilisant ssh -Y: il n'y a pas eu d'erreur, la boîte de dialogue du mot de passe est apparue, j'ai tapé le mot de passe et GitHub a accepté le push.

En guise d'avertissement, ssh -Y peut ouvrir des problèmes de sécurité car vous traitez le serveur distant comme un client de confiance ( /ubuntu/35512/what-is-the-difference-b between-ssh-y- trust-x11-forwarding-et-ssh-xu ). Soyez donc prudent lorsque vous l'utilisez.

— cr_dave
source