git erzeugt Gtk-WARNUNG: Anzeige kann nicht geöffnet werden

138

Ich habe über die Befehlszeile auf einem Computer, für den ich keine Administratorrechte habe, remote an meinem Projekt gearbeitet. Nach dem Ausführen wird git push origin masterdie folgende Fehlermeldung angezeigt:

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

Meine .git/configDatei hat folgenden Inhalt:

    [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

Ich habe den 403-Fehler früher erhalten. Nach dem Kommentar hier habe ich meinen Benutzernamen vor das @ -Zeichen in der Remote-URL gesetzt und seitdem erhalte ich den Gtk-Fehler.

Wenn ich mich mit dem Computer anmelde ssh -Xund versuche zu pushen, wird folgende Fehlermeldung angezeigt:

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

Wenn ich die URL der Fernbedienung in ändere git@github.com:username/repository.git, lautet der Fehler:

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

Wissen Sie, wie Sie das beheben können?

— John Manak
quelle

2

Ich denke du benutzt ssh. Verwenden Sie stattdessen ssh -X. Dies bedeutet, dass ein Passwortdialog versucht, sich zu öffnen, dies jedoch nicht konnte, da kein X vorhanden ist.

— Positron

Danke, aber ich benutze ssh nicht explizit, sondern rufe nur an git push origin master, damit ich nicht weiß, wie ich das anwenden soll, was du sagst?

— John Manak

Darf ich wissen, von wo aus Sie auf den Server pushen? Ich meine von welcher Maschine? Wie haben Sie sich bei diesem Computer angemeldet?

— Positron

1

Hoppla. Es tut uns leid. Ich habe Ihre Frage nicht vollständig gelesen. Ihre "URL" sollte entweder sein git@github.com:username/repo.gitoder https://github.com/username/repo.gitSie verwenden jedoch eine Mischung aus beiden.

— Positron

Oh, tut mir leid, ich verstehe, was du jetzt meinst. Ich habe versucht, mich mit dem Computer anzumelden ssh -X, aber das hat auch nicht geholfen. Siehe die aktualisierte Frage oben.

— John Manak

336

Ich habe endlich eine Lösung für das Problem gefunden. Wie hier beschrieben , habe ich im Terminal den folgenden Befehl ausgeführt:

  unset SSH_ASKPASS

und dann läuft git push origin masterdas Laufen so, wie es sollte. Sie können die Zeile auch zu Ihrer .bashrcDatei hinzufügen .

— John Manak
quelle

5

Danke ... das hat viel Zeit gespart. Segne dich

— Poonam Bhatt

Dank dafür! :-)

— ItayB

1

Danke .. das hat bei mir funktioniert! Beim Versuch, vom Bitbucket auf den Linux-Computer zu klonen, wurde ein ähnlicher Fehler angezeigt.

— Blesson Jose

2

Ich wollte nur hinzufügen, dass es dieses Skript war, das diese Variable auf meinem CentOS 6.7-System festlegte: /etc/profile.d/gnome-ssh-askpass.sh

— hshib

Jetzt bekomme ich eineerror: RPC failed; result=22, HTTP code = 417

— Pmiranda

19

Ich habe mich kürzlich mit diesem Verhalten auf einem RedHat 5-Computer befasst, auf dem unsere Git-Version 1.7.4.1 war.

Ich hatte kein hohes Maß an Vertrauen, unset SSH_ASKPASSdas keine unbeabsichtigten Konsequenzen hätte, also wollte ich sehen, ob es eine andere Lösung gibt.

Ich konnte es nicht mit Sicherheit sagen, aber es scheint, dass ein Patch für dieses Problem ungefähr zur gleichen Zeit in Arbeit war, als unsere Version von Git veröffentlicht wurde. Es schien mir also vernünftig zu hoffen, dass eine neuere Version das Verhalten korrigieren würde.

Und tatsächlich tat es das. Ein Upgrade auf den 1.8-Zweig von Git hat das Problem behoben. Die Fehlermeldung wird aus irgendeinem Grund immer noch angezeigt, aber Sie werden korrekt zur Eingabe Ihres Kennworts aufgefordert und dürfen fortfahren.

— eikonomega
quelle

2

Das Problem in RHEL 5 (CentOS 5 usw.) liegt in der Datei /etc/profile.d/gnome-ssh-askpass.sh (im Besitz des Pakets openssh-askpass), in der die Umgebungsvariable SSH_ASKPASS blind auf / usr / libexec / openssh gesetzt ist / gnome-ssh-askpass und dies funktioniert nicht, wenn kein X vorhanden ist (dh über PuTTY über SSH angemeldet). Sie können die Zeile in dieser Datei einfach auskommentieren (löschen Sie die Datei nicht, da sie sonst nach der Aktualisierung des openssh-askpass-Pakets wiederhergestellt wird). Oder entfernen Sie das Paket openssh-askpass vollständig (yum entfernen openssh-askpass).

— Milan Kerslager

0

Keine dieser Antworten funktionierte für mich (ssh'ing über Cygwin unter Windows 10 in einen RHEL 6.8-Server und der Versuch, ein github.com-Repo aus der RHEL-Box zu klonen). Ich habe also über einen SSH-Schlüssel und nicht über einen HTTPS-Benutzernamen geklont. Passwort. Beispiel: Ich habe git@github.com: MyUsername / myproject.git anstelle der https-URL verwendet. Ich habe auch meinen öffentlichen Schlüssel entsprechend in Github hochgeladen. Diese Methode hat gut funktioniert.

Hinweis: Von den oben genannten Lösungen habe ich eigentlich nicht versucht, ein Upgrade auf den 1.8-Zweig von git durchzuführen

— johnsimer
quelle

0

Sie können auch versuchen, sich mit ssh -Y beim Remote-Server anzumelden, damit das Dialogfeld grafisch angezeigt wird.

Wie beim OP funktionierte die Anmeldung über ssh -X nicht. Beim Push-Versuch wiederholte der Server einfach die gleiche Fehlermeldung - (gnome-ssh-askpass:29241): Gtk-WARNING **: cannot open display:- wie bei der Protokollierung über ssh ohne X11-Weiterleitung. Dies ist ein etwas anderes Verhalten als das, was der OP gemeldet hat, als er ssh -X ausprobiert hat, da sich seine Fehlermeldung geringfügig geändert hat, als er nur ssh verwendet hat.

Nachdem ich mich jedoch mit ssh -Y angemeldet hatte: Es gab keinen Fehler, das Dialogfeld für das Kennwort wurde angezeigt, ich gab das Kennwort ein und GitHub akzeptierte den Push.

Als Warnung kann ssh -Y Sicherheitsprobleme verursachen, wenn Sie den Remote-Server als vertrauenswürdigen Client behandeln ( /ubuntu/35512/what-is-the-difference-between-ssh-y- Trusted-x11-Forwarding-and-SSH-XU ). Seien Sie also vorsichtig, wenn Sie es verwenden.

— cr_dave
quelle