¿Cómo puedo evitar la advertencia No xauth data; utilizando datos de autenticación falsos para el reenvío X11?

66

Cada vez que inicio una conexión ssh desde mi Mac a un Linux (Debian) recibo esta advertencia:

No xauth data; using fake authentication data for X11 forwarding.

Esto también sucede para las herramientas que usan ssh, como git o mercurial.

Solo quiero hacer un cambio local en mi sistema para evitar que esto aparezca.

Nota: Tengo un servidor X11 (XQuartz 2.7.3 (xorg-server 1.12.4)) en mi Mac OS X (10.8.1) y funciona correctamente, puedo iniciar el reloj con éxito local o remotamente.

sorin
fuente
1
¿Qué comando estás usando para ssh?
DerfK
@DerfK solo ssh hostnamepero en mi ~/.ssh/configagregué hace ForwardX11 yesalgún tiempo. Aún así, esto es algo que quiero tener allí.
sorin
Usando Ubuntu 16.04 LTS (agosto de 2017) me doy por vencido. La conclusión es que, aunque da el error, funciona. Yo uso ssh -Y hostnamede Linux, y ssh -x hostnamecuando uso OpenSSH en Windows.
SDsolar

Respuestas:

66

Ninguna de las soluciones publicadas funcionó para mí. Mi sistema cliente (escritorio) ejecuta macOS 10.12.5 (Sierra). Agregué -vlas opciones para el sshcomando y me dijo:

debug1: No xauth program.

lo que significa que no tiene una ruta correcta al xauthprograma. (En esta versión de macOS, la ruta xauthno es estándar). La solución fue agregar esta línea a /etc/ssh/ssh_config(puede estar /etc/ssh/configen algunas configuraciones) o en ~/.ssh/config(si no tiene derechos de administrador):

XAuthLocation /opt/X11/bin/xauth

Ahora el mensaje de advertencia se ha ido.

nmgeek
fuente
10
DIOS MIO. Años he estado tratando de encontrar una solución, y esto funcionó. ¡Años que digo! Tenga en cuenta que hice esto agregando esa línea debajo de la Host *entrada en mi ~/.ssh/configarchivo en lugar de editar /etc/ssh/ssh_config. La única documentación que encontré para esto estaba en man sshd_config.
Demitri
Esto funcionó para mí también. Entiendo que en este momento XQuartz no se mantiene bien debido a la falta de fondos. Así que creo que los problemas de portación como este son en realidad menos de lo que esperaría.
AlanObject
En la sierra alta; Este es el que también funcionó para mí.
mklein9
1
¡Tenga en cuenta que puede experimentar este problema incluso cuando su shell pueda encontrar xauth en su RUTA! ¿Supongo que el cliente ssh está desinfectando su RUTA por razones de seguridad?
MarcH
1
Esta solución no me funcionó. Estoy usando Cygwin en Win7. Agregar "XAuthLocation / usr / bin / xauth", ya sea debajo de la entrada "Host *" o antes de esa línea, en ~ / .ssh / config, no hizo ninguna diferencia.
David M. Karr
22

Encontré la causa, mi ~/.ssh/configestaba incompleto, necesitas ambos:

Host *
    ForwardAgent yes
    ForwardX11 yes

Mi error fue que incluí solo la opción ForwardX11.

sorin
fuente
12
No estoy seguro de por qué esto es necesario / relevante. ForwardAgentse usa para permitir que las claves almacenadas en caché ssh-agentpasen a través de múltiples conexiones SSH anidadas. No debería tener ninguna relevancia para X11. Y fwiw, según algunos, no es una buena idea en cuanto a seguridad: heipei.github.io/2015/02/26/…
underscore_d
2
Eso no suena bien, lo que ayuda es desactivar el reenvío X11 o arreglar la configuración de xauth para configurarlo. No está relacionado con los agentes ssh.
Eckes
Esta solución no me funcionó.
David M. Karr
¿Está esto ~/.ssh/configen el cliente macOS o en el servidor Linux? Tengo estos archivos en ninguno. Tengo un similar/etc/ssh/sshd_config
Max Coplan
13

Permitir que Ubuntu bash en Windows 10 se ejecute ssh -X para obtener un entorno GUI en un servidor remoto

  • primero

Instale todo lo siguiente. En la ventana, instale Xming. En Ubuntu bash, use sudo apt installpara instalar ssh xauth xorg.

sudo apt install ssh xauth xorg
  • Segundo

Ir a la carpeta contiene el ssh_configarchivo, el mío es /etc/ssh.

  • Tercero

Editar ssh_configcomo administrador (USE sudo). En el interior ssh_config, retire el hash #en las líneas ForwardAgent, ForwardX11, ForwardX11Trusted, y establecer los argumentos correspondientes a yes.

# /etc/ssh/ssh_config

Host *
    ForwardAgent yes
    ForwardX11 yes
    ForwardX11Trusted yes
  • Adelante

En el ssh_configarchivo, elimine el hash frontal #antes Port 22y Protocol 2, y también agregue una nueva línea al final del archivo para indicar la ubicación del archivo xauth XauthLocation /usr/bin/xauth, recuerde escribir su propia ruta del archivo xauth.

# /etc/ssh/ssh_config

#   IdentifyFile ...
    Port 22
    Protocol 2
#   Cipher 3des
#   ...
#   ...
    ...
    ...
    GSSAPIDelegateCredentials no
    XauthLocation /usr/bin/xauth
  • Quinto

Ahora que hemos terminado de editar el ssh_configarchivo, guárdelo cuando salgamos del editor. Ahora vaya a la carpeta ~o $HOME, agregue export DISPLAY=localhost:0a su .bashrcarchivo y guárdelo.

# ~/.bashrc
...
...
export DISPLAY=localhost:0
  • Último

Casi terminamos. Reinicia tu shell bash, abre tu Xmingprograma y úsalo ssh -X yourusername@yourhost. Entonces disfrute del entorno GUI.

ssh -X yourusername@yourhost

El problema también está en el subsistema Ubuntu en Windows, y el enlace está en

https://gist.github.com/DestinyOne/f236f71b9cdecd349507dfe90ebae776

Nota: el texto vinculado incluye 2 errores tipográficos (en XauthLocaionlugar de XauthLocation)

DestinyOne
fuente
La pregunta no es sobre Windows.
kasperd
En MacOS es casi lo mismo, las diferencias son en lugar de Xming, deberíamos obtener XQuartz, y el ssh_configarchivo está en una ubicación diferente, la mía es /private/etc/ssh.
DestinyOne
Y también, la última línea para ssh_configserá:XAuthLocation /opt/X11/bin/xauth
DestinyOne
2
Edición necesaria: XauthLocaion-> XauthLocation(esa edición es demasiado pequeña para que yo pueda hacerla).
echristopherson
1
Además de instalar xming, ssh, xauth, y xorg(paso 1), el único que se necesita para mí eraexport DISPLAY=localhost:0
Eponymous
11

Como se señaló, parece que xauthen OS X Yosemite ha retrocedido a una versión anterior que no funciona con la $DISPLAYconfiguración de XQuartz :

% xauth -V
1.0.9
% xauth generate $DISPLAY .
xauth: (argv):1:  bad display name "/private/tmp/com.apple.launchd(...)/org.macosforge.xquartz:0" in "add" command
huésped
fuente
1
Probé las mismas líneas en OS X 10.11, y no recibo ningún error. Sigue siendo la misma versión de XQuartz.
sorin
1
@guest Su xauth generate $DISPLAY .comando funcionó en mi Mac OS X High Sierra (10.13) y resolvió mi No xauth data; using fake authentication data for X11 forwarding.pb.
SebMa
2

Hay un error en MacOS en este momento. Me encontré con esto también. La solución para mí implicó agregar lo siguiente a mi .bash_profile

dispdir=`dirname $DISPLAY`
dispfile=`basename $DISPLAY`
dispnew="$dispdir/:0"
if [ -e $DISPLAY -a "$dispfile" = "org.x:0" ]; then
  mv $DISPLAY $dispnew
fi
export DISPLAY=$dispnew

Esencialmente, el nombre de la tubería de archivo asociada con su raíz X no se puede manejar correctamente y, por lo tanto, necesita corrección. :-)

Tux rojo
fuente
Dudo que esto resuelva el error en aplicaciones GUI OS X, como SourceTree.
sorin
Confirmar que funciona en Sierra para ejecutar emacs con X, ya que la Mac es el servidor. esto debería funcionar ampliamente en los casos en que el cliente está en una máquina remota
Mark Mullin
2

Incluso

XAuthLocation / opt / local / bin / xauth en ~ / .ssh / config

en mi macOS Sierra 10.12.6 funcionó para mí. Un pequeño cambio de la respuesta 7).

Kepler Oliveira Filho
fuente
1

acabo de eliminar ~ / .Xauthority (máquina de destino) de mi carpeta raíz y ssh -X 192.168.123.1 nuevamente y funcioné.

Marcel Kraan
fuente
Puedo confirmar que esta es una respuesta en Mac OS Sierra 10.12.4. Eliminar ~ / .Xauthority en el servidor SSH hace el truco: ~$ mv ~/.Xauthority ~/.Xauthority.bak una nueva cookie mágica se volvió a colocar automáticamente en ~ / .Xauthority una vez que inicié sesión nuevamente. No se requiere ninguna secuencia de comandos Bash.
Kenneth Pegasus
1

En mi caso fue el problema de .Xauthority que contiene la cookie Magic no reenviada, Fabby en http://askubuntu.com/questions/571116/ recomienda el 2014-11-14 para agregar esta línea al final de .bashrc o . perfil para permitir el reenvío de claves xauth entre usuarios al llamar a su:

export $(dbus-launch)

También agregué anteriormente:

export XAUTHORITY=~/.Xauthority 

para asegurar la llamada remota con ssh -X ̍ @ lo encontrará.

En mi caso .Xauthority es un enlace simbólico al usuario original /home//.Xauthority que subo de ...

  cd /home/<child_user>;ln -sf /home/<parent_user>/.Xauthority .xAuthority

con los derechos correctos:

  sudo chown <parent_user> /home/<parent_user>/.profile
  chmod a+rw /home/<parent_user>/.profile 

entonces es accesible ay para. ¡podrá activar aplicaciones y mostrar el resultado de X-windowed en su pantalla local a través de la cuenta proxy!

CONSEJO: Verifique la lista xauth ... si refleja la cookie mágica.

todo informatico
fuente
0

Agregaría esto como un comentario, pero no tengo suficiente representante. Agregar una línea más a la solución de sorin funcionó para mí.

Abra su archivo de configuración ssh con vim ~/.ssh/config Luego agregue estas líneas:

Host *
    ForwardAgent yes
    ForwardX11 yes
    XAuthLocation /opt/X11/bin/xauth

Puede verificar su xauthubicación con:

which xauth
ssanch
fuente
No estoy seguro de si esto realmente funcionaría porque la ubicación de xauth sería diferente en cada máquina remota. El tuyo parece uno de MacOS, pero Linux lo tiene en una ubicación diferente. Principalmente comencé a deshabilitar ForwardX11 completamente porque casi nunca lo uso.
Sorin