web-dev-qa-db-fra.com

git produit Gtk-WARNING: impossible d'ouvrir l'écran

J'ai travaillé sur mon projet à distance via la ligne de commande sur une machine sur laquelle je ne dispose pas de droits d'administrateur. Après avoir exécuté git Push Origin master, Le message d'erreur suivant s'affiche:

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

Mon fichier .git/config A le contenu suivant:

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

Je devais 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 lors, le message d'erreur Gtk s'affiche.

Quand je me connecte à la machine en utilisant ssh -X Et que j'essaie 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 modifie l'URL de la télécommande en [email protected]:username/repository.git, L'erreur est la suivante:

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?

gitversion-controlgithubssh
129
John Manak

J'ai finalement 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 en cours d'exécution git Push Origin master fonctionne comme il se doit. Vous pouvez également ajouter la ligne à votre .bashrc fichier.

323
John Manak

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

Je n'avais pas beaucoup de confiance en moi que unset SSH_ASKPASS n'aurait pas de conséquences inattendues, alors je voulais voir s'il y avait une autre solution.

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

Et en effet il l'a fait. 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 quelconque, mais vous êtes correctement invité à entrer votre mot de passe et vous y êtes autorisé. continuer.

19
eikonomega

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 pour l'OP, la connexion via ssh -X ne fonctionnait pas. En essayant de Push, le serveur a simplement répété le même message d'erreur - (gnome-ssh-askpass:29241): Gtk-WARNING **: cannot open display: - comme lors de la connexion via ssh sans aucun transfert X11. Ce comportement est légèrement différent de ce que l'OP a signalé lorsqu'il a essayé ssh -X car son message d'erreur était légèrement différent de l'utilisation de ssh.

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

En guise d'avertissement, ssh -Y peut poser des problèmes de sécurité si vous traitez le serveur distant comme un client approuvé ( https://askubuntu.com/questions/35512/what-is-the-difference-between-) ssh-y-Trusted-x11-forwarding-and-ssh-x ). Alors soyez prudent lorsque vous l'utilisez.

0
cr_dave

Aucune de ces réponses ne fonctionnait pour moi (ssh'ing via Cygwin sous Windows 10 sur un serveur RHEL 6.8 et une tentative de clonage d'un référentiel github.com à partir de la boîte RHEL). Ce que j'ai fait était donc de cloner via une clé SSH plutôt que le nom d'utilisateur HTTPS/mot de passe. par exemple. J'ai utilisé [email protected]: MyUsername/myproject.git plutôt que l'URL https. J'ai également correctement chargé ma clé publique dans Github. Cette méthode a bien fonctionné.

Note: Parmi les solutions ci-dessus, je n’ai en fait pas essayé de passer à la branche 1.8 de git.

0
johnsimer