He estado trabajando en mi proyecto de forma remota a través de la línea de comandos en una máquina para la que no tengo derechos de administrador y después de ejecutar git push origin master
recibo el siguiente mensaje de error:
(gnome-ssh-askpass:29241): Gtk-WARNING **: cannot open display:
Mi .git/config
archivo tiene los siguientes contenidos:
[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
Estaba recibiendo el error 403 antes. Siguiendo el comentario aquí , puse mi nombre de usuario antes del signo @ en la url remota y desde entonces recibí el error Gtk.
Cuando inicio sesión en la máquina usando ssh -X
e intento presionar, aparece el siguiente error:
X11 connection rejected because of wrong authentication.
(gnome-ssh-askpass:31922): Gtk-WARNING **: cannot open display:localhost:10.0
Si cambio la url del control remoto a [email protected]:username/repository.git
, entonces el error es:
ssh: connect to host github.com port 22: Connection timed out
fatal: The remote end hung up unexpectedly
¿Sabes cómo arreglar ésto?
git
version-control
github
ssh
John Manak
fuente
fuente
git push origin master
, así que no sé cómo aplicar lo que estás diciendo.[email protected]:username/repo.git
ohttps://github.com/username/repo.git
Pero está utilizando una combinación de ambos.ssh -X
, pero eso tampoco ayudó. Vea la pregunta actualizada arriba.Respuestas:
Finalmente he descubierto una solución al problema. Como se describió aquí , ejecuté el siguiente comando en la terminal:
y luego correr
git push origin master
funciona como debería. También puede agregar la línea a su.bashrc
archivo.fuente
error: RPC failed; result=22, HTTP code = 417
Recientemente me ocupé de este comportamiento en una máquina RedHat 5 donde nuestra versión de Git era 1.7.4.1.
No tenía un alto grado de confianza que
unset SSH_ASKPASS
no tuviera consecuencias no deseadas, así que quería ver si había otra solución.No podía decirlo con certeza, pero parece que se estaba preparando un parche para este problema en al mismo tiempo que se había publicado nuestra versión de Git. Entonces, me pareció que era razonable esperar que una versión más reciente corrigiera el comportamiento.
Y de hecho lo hizo. La actualización a la rama 1.8 de Git resolvió el problema. El mensaje de error todavía se muestra por algún motivo extraño, pero se le solicita correctamente su contraseña y se le permite continuar.
fuente
Ninguna de estas respuestas funcionó para mí (enviando a través de Cygwin en Windows 10 a un servidor RHEL 6.8 e intentando clonar un repositorio de github.com desde el cuadro RHEL), así que lo que hice fue clonar a través de una clave SSH en lugar de un nombre de usuario HTTPS / contraseña. por ejemplo, utilicé [email protected]: MyUsername / myproject.git en lugar de la URL https. También cargué apropiadamente mi clave pública en Github. Este método funcionó bien.
Nota: De las soluciones anteriores, en realidad no intenté actualizar a la rama 1.8 de git
fuente
También puede intentar iniciar sesión usando ssh -Y en el servidor remoto para que el cuadro de diálogo pueda aparecer gráficamente.
Al igual que el OP, iniciar sesión a través de ssh -X no funcionó. Al intentar presionar, el servidor simplemente repitió el mismo mensaje de error:
(gnome-ssh-askpass:29241): Gtk-WARNING **: cannot open display:
, como lo hizo al iniciar sesión a través de ssh sin reenvío X11. Este es un comportamiento ligeramente diferente de lo que informó el OP cuando intentó ssh -X ya que su mensaje de error cambió ligeramente con solo usar ssh.Sin embargo, para mí, una vez que inicié sesión con ssh -Y: no hubo ningún error, apareció el cuadro de diálogo de contraseña, escribí la contraseña y GitHub aceptó el envío.
Como advertencia previa, ssh -Y puede abrir problemas de seguridad ya que trata al servidor remoto como un cliente confiable ( /ubuntu/35512/what-is-the-difference-between-ssh-y- confiable-x11-reenvío-y-ssh-xu ). Así que ten cuidado al usarlo.
fuente