git generuje Gtk-OSTRZEŻENIE: nie można otworzyć ekranu

138

Pracowałem nad swoim projektem zdalnie za pomocą wiersza poleceń na komputerze, do którego nie mam uprawnień administratora, a po uruchomieniu pojawia git push origin mastersię następujący komunikat o błędzie:

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

Mój .git/configplik ma następującą zawartość:

    [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

Wcześniej otrzymywałem błąd 403. Idąc za komentarzem tutaj , umieszczam swoją nazwę użytkownika przed znakiem @ w zdalnym adresie URL i od tego czasu otrzymuję błąd Gtk.

Kiedy loguję się do komputera za pomocą ssh -Xi próbuję push, pojawia się następujący błąd:

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

Jeśli zmienię adres pilota na git@github.com:username/repository.git, to błąd wygląda tak:

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

Czy wiesz, jak to naprawić?

— John Manak
źródło

2

Myślę, że używasz ssh. Zamiast tego użyj ssh -X. Oznacza to, że okno dialogowe hasła próbuje się otworzyć, ale nie może, ponieważ nie ma X.

— positron

Dzięki, ale nie używam ssh bezpośrednio, po prostu dzwonię git push origin master, więc nie wiem, jak zastosować to, co mówisz?

— John Manak

Czy mogę wiedzieć, skąd pchasz na serwer? Mam na myśli z jakiej maszyny? Jak zalogowałeś się do tego komputera?

— positron

1

Ups. Przepraszam. Nie w pełni przeczytałem Twoje pytanie. Twój „adres URL” powinien być git@github.com:username/repo.gitalbo https://github.com/username/repo.gitAle używasz połączenia obu.

— positron

Przepraszam, teraz rozumiem, co masz na myśli. Próbowałem zalogować się do komputera za pomocą ssh -X, ale to też nie pomogło. Zobacz zaktualizowane pytanie powyżej.

— John Manak

336

W końcu znalazłem rozwiązanie problemu. Jak zostało tutaj opisane , uruchomiłem w terminalu następującą komendę:

  unset SSH_ASKPASS

a wtedy bieganie git push origin masterdziała tak, jak powinno. Możesz także dodać linię do swojego .bashrcpliku.

— John Manak
źródło

5

Dzięki ... to zaoszczędziło dużo czasu. Bless you

— Poonam Bhatt,

Dziękuję za to! :-)

— ItayB

1

Dzięki ... to zadziałało dla mnie! Otrzymałem podobny błąd podczas próby sklonowania z Bitbucket na komputer z systemem Linux.

— Blesson Jose

2

Chciałem tylko dodać, że to ten skrypt ustawia tę zmienną w moim systemie CentOS 6.7: /etc/profile.d/gnome-ssh-askpass.sh

— hshib

Teraz dostajęerror: RPC failed; result=22, HTTP code = 417

— pmiranda

19

Niedawno miałem do czynienia z tym zachowaniem na maszynie RedHat 5, na której nasza wersja Gita to 1.7.4.1.

Nie miałem wysokiego stopnia pewności siebie, unset SSH_ASKPASSktóry nie miałby niezamierzonych konsekwencji, więc chciałem sprawdzić, czy istnieje inne rozwiązanie.

Nie mogłem tego stwierdzić na pewno, ale wygląda na to, że prace nad poprawką tego problemu były wykonywane mniej więcej w tym samym czasie, gdy opublikowano naszą wersję Gita. Wydawało mi się więc, że można mieć nadzieję, że nowsza wersja poprawi to zachowanie.

I rzeczywiście tak było. Aktualizacja do gałęzi Git 1.8 rozwiązała problem. Komunikat o błędzie jest nadal wyświetlany z jakiegoś dziwnego powodu, ale pojawia się poprawna prośba o podanie hasła i możesz kontynuować.

— eikonomega
źródło

2

Problem w RHEL 5 (CentOS 5 itp.) Znajduje się w pliku /etc/profile.d/gnome-ssh-askpass.sh (należącym do pakietu openssh-askpass), gdzie zmienna środowiskowa SSH_ASKPASS jest blindy ustawiona na / usr / libexec / openssh / gnome-ssh-askpass i to nie działa, jeśli nie ma X (tj. zalogowano się przez PuTTY przez SSH). Możesz po prostu zakomentować linię w tym pliku (nie usuwaj pliku, bo zostanie on odzyskany po aktualizacji pakietu openssh-askpass). Lub całkowicie usuń pakiet openssh-askpass (yum remove openssh-askpass).

— Milan Kerslager

0

Żadna z tych odpowiedzi nie zadziałała dla mnie (ssh'owanie przez Cygwin w Windows 10 na serwer RHEL 6.8 i próba sklonowania repozytorium github.com z pola RHEL), więc sklonowałem za pomocą klucza SSH, a nie nazwy użytkownika HTTPS / hasło. np. użyłem git@github.com: MyUsername / myproject.git zamiast adresu URL https. Odpowiednio przesłałem również mój klucz publiczny na Github. Ta metoda działała dobrze.

Uwaga: spośród powyższych rozwiązań faktycznie nie próbowałem uaktualnić do gałęzi git 1.8

— johnsimer
źródło

0

Możesz także spróbować zalogować się za pomocą ssh -Y do zdalnego serwera, aby okno dialogowe było wyświetlane graficznie.

Podobnie jak w przypadku OP, logowanie przez ssh -X nie działało. Podczas próby wypychania serwer po prostu powtórzył ten sam komunikat o błędzie - (gnome-ssh-askpass:29241): Gtk-WARNING **: cannot open display:- tak jak podczas logowania przez ssh bez przekazywania przez X11. Zachowanie to różni się nieco od tego, co zgłosił OP, gdy próbował ssh -X, ponieważ jego komunikat o błędzie zmienił się nieznacznie od zwykłego użycia ssh.

Jednak dla mnie, gdy zalogowałem się za pomocą ssh -Y: nie było błędu, pojawiło się okno dialogowe hasła, wpisałem hasło, a GitHub zaakceptował push.

Jako ostrzeżenie, ssh -Y może powodować problemy z bezpieczeństwem, ponieważ traktujesz serwer zdalny jako zaufanego klienta ( /ubuntu/35512/what-is-the-difference-between-ssh-y- trust-x11-forwarding-and-ssh-xu ). Dlatego uważaj, używając go.

— cr_dave
źródło