142

I've been working on my project remotely through the command line on a machine to which I don't have admin rights and after running git push origin master I get the following error message:

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

My .git/config file has the following contents:

    [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

I was getting the 403 error earlier. Following the comment here, I put my username before the @ sign in the remote url and since then, I've been getting the Gtk error.

When I login to the machine using ssh -X and try to push, I get the following error:

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

If I change the url of the remote to git@github.com:username/repository.git, then the error is:

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

Do you know how to fix this?

Community
  • 1
  • 1
John Manak
  • 13,328
  • 29
  • 78
  • 119
  • 2
    I guess you are using ssh. Use ssh -X instead. This means a password dialog is trying to open up, but couldn't because there is no X. – positron Apr 18 '13 at 08:36
  • Thanks, but I'm not using ssh explicitly, just calling `git push origin master`, so I don't know how to apply what you're saying? – John Manak Apr 18 '13 at 08:40
  • May I know from where you are pushing to the server? I mean from which machine? How have you logged into that machine? – positron Apr 18 '13 at 08:42
  • 1
    Oops. Sorry. I didn't fully read your question. Your "url" should either be `git@github.com:username/repo.git` or `https://github.com/username/repo.git` But you are using a mix of both. – positron Apr 18 '13 at 08:48
  • Oh sorry, I get what you mean now. I tried logging into the machine using `ssh -X`, but that didn't help either. See the updated question above. – John Manak Apr 18 '13 at 08:58
  • Quite strange. Are you behind a firewall? Are you able to ping `github.com` – positron Apr 18 '13 at 09:06
  • Strange indeed. I'm behind a proxy, but both http_proxy and https_proxy are set in .bashrc. It seems I can't ping github.com, but I can clone repositories, that works OK (and it only started working after setting those environment variables a while ago). – John Manak Apr 18 '13 at 09:16
  • My take on this is that you're dealing with the GNOME keyring. I mean, when you attempt to connect to your server, SSH notices there's an active desktop session and tries to spawn a GNOME keyring credentials helper to ask you for a password for your key, and fails because it's unable to connect to your display. The exact cause it unknown. Could you elaborate on your setup? What machine runs a GNOME session -- your local one of the remote? – kostix Apr 18 '13 at 10:04
  • @JohnManak: If you are behind a proxy, mostly your ping requests won't get any responses. But you can clone. :) – positron Apr 18 '13 at 14:26

4 Answers4

347

I have finally discovered a solution to the problem. As it was described here, I ran the following command in the terminal:

  unset SSH_ASKPASS

and then running git push origin master works the way it should. You can also add the line to your .bashrc file.

John Manak
  • 13,328
  • 29
  • 78
  • 119
  • 2
    Just wanted to add that it was this script setting this variable on my CentOS 6.7 system: /etc/profile.d/gnome-ssh-askpass.sh – hshib Mar 25 '16 at 21:15
  • Now I'm getting a `error: RPC failed; result=22, HTTP code = 417` – pmiranda Jun 14 '17 at 14:30
  • I did this and when I try to connect to SSH now I'm just left with a blank shell where I can type and doesn't do anything instead of a prompt for my password. Any ideas? – Natanel Feb 25 '18 at 18:41
19

I recently dealt with this behavior on a RedHat 5 machine where our Git version was 1.7.4.1.

I didn't have a high degree of confidence that unset SSH_ASKPASS wouldn't have unintended consequences, so I wanted to see if there was another solution.

I couldn't tell for certain, but it seems that a patch for this problem was in the works around the same time that our version of Git had been published. So, it seemed to me that it was reasonable to hope that a more recent version would correct the behavior.

And indeed it did. Upgrading to the 1.8 branch of Git resolved the problem. The error message is still displayed for some odd reason, but you are correctly prompted for your password and allowed to continue.

eikonomega
  • 1,971
  • 17
  • 28
  • 2
    The problem in RHEL 5 (CentOS 5 etc.) is in file /etc/profile.d/gnome-ssh-askpass.sh (owned by openssh-askpass package) where SSH_ASKPASS environment variable is blindy set to /usr/libexec/openssh/gnome-ssh-askpass and this does not work if there is no X (ie. logged in via PuTTY over SSH). You may simply comment out the line in this file (do not delete file or it will be recovered after update of openssh-askpass package). Or remove package openssh-askpass completely (yum remove openssh-askpass). – Milan Kerslager Mar 08 '17 at 09:26
0

None of these answers worked for me (ssh'ing via Cygwin on Windows 10 into a RHEL 6.8 server and trying to clone a github.com repo from the RHEL box) so what I did was clone via an SSH key rather than HTTPS username/password. e.g. I used git@github.com:MyUsername/myproject.git rather than the https url. I also appropriately uploaded my public key into Github. This method worked fine.

Note: Of the above solutions, I actually didn't try upgrading to the 1.8 branch of git

johnsimer
  • 350
  • 3
  • 16
0

You can also try to login using ssh -Y to the remote server so the dialogue box can appear graphically.

Like the OP, logging in via ssh -X didn't work. When trying to push, the server simply repeated the same error message - (gnome-ssh-askpass:29241): Gtk-WARNING **: cannot open display: - as it did when logging via ssh with no X11 forwarding. This is slightly different behavior from what the OP reported when he tried ssh -X as his error message changed slightly from just using ssh.

However, for me, once logged in using ssh -Y: there was no error, the password dialogue box popped up, I typed the password in, and GitHub accepted the push.

As a forewarning, ssh -Y can open up security problems as you are treating the remote server as a trusted client (https://askubuntu.com/questions/35512/what-is-the-difference-between-ssh-y-trusted-x11-forwarding-and-ssh-x-u). So be careful when using it.

dada_dave
  • 493
  • 4
  • 13