▷¿Cómo reenviar X a través de SSH para ejecutar aplicaciones gráficas de forma remota? ✔️ Foro Ayuda 【 2024 】

Solución:

El reenvío X11 debe estar habilitado tanto en el lado del cliente como en el lado del servidor.

Sobre el lado del cliente, los -X (X mayúscula) opción a ssh habilita el reenvío X11, y puede hacer que este sea el predeterminado (para todas las conexiones o para una conexión específica) con ForwardX11 yes en ~/.ssh/config.

Sobre el lado del servidor, X11Forwarding yes debe especificarse en /etc/ssh/sshd_config. Tenga en cuenta que el valor predeterminado es sin reenvío (algunas distribuciones lo activan en su /etc/ssh/sshd_config) y que el usuario no puede anular esta configuración.

los xauth El programa debe instalarse en el lado del servidor. Si hay algún programa X11 allí, es muy probable que xauth estaré ahí. En el improbable caso xauth se instaló en una ubicación no estándar, se puede llamar a través de ~/.ssh/rc (¡en el servidor!).

Tenga en cuenta que no necesita establecer ninguna variable de entorno en el servidor. DISPLAY y XAUTHORITY se establecerán automáticamente en sus valores adecuados. Si ejecuta ssh y DISPLAY no está configurado, significa que ssh no está reenviando la conexión X11.

Para confirmar que ssh está reenviando X11, busque una línea que contenga Requesting X11 forwarding en el ssh -v -X producción. Tenga en cuenta que el servidor no responde de cualquier manera, una precaución de seguridad de ocultar detalles de posibles atacantes.

Para que el reenvío de X11 funcione a través de SSH, necesitará tres cosas en su lugar:

Su cliente debe estar configurado para reenviar X11.
Su servidor debe estar configurado para permitir el reenvío X11.
Su servidor debe poder configurar la autenticación X11.

Si tiene el n. ° 1 y el n. ° 2 en su lugar, pero le falta el n. ° 3, terminará con un DISPLAY Variable ambiental.

De sopa a nueces, aquí se explica cómo hacer que el reenvío X11 funcione:

En su servidor, asegúrese /etc/ssh/sshd_config contiene:
```
X11Forwarding yes
X11DisplayOffset 10
```
Puede que necesite SIGHUP sshd por lo que recoge estos cambios.
```
cat /var/run/sshd.pid | xargs kill -1
```
En su servidor, asegúrese de tener xauth instalado.
```
[email protected]:~$ which xauth
/usr/bin/xauth
```
Si tu no tienes xauth instalado, se encontrará con el empty DISPLAY environment variable problema.
En su cliente, conéctese a su servidor. Asegúrese de decirle a ssh que permita el reenvío de X11. yo prefiero
```
[email protected]:~$ ssh -X [email protected]
```

pero te puede gustar

    [email protected]:~$ ssh -o ForwardX11=yes [email protected]

o puede configurar esto en su ~/.ssh/config.

Estaba corriendo hacia este vacío DISPLAY variable de entorno el día de hoy cuando ssh’ing en un nuevo servidor que no administro. Rastreando a los desaparecidos xauth parte fue un poco divertida. Esto es lo que hice y lo que tú también puedes hacer.

En mi estación de trabajo local, donde soy administrador, verifiqué que /etc/ssh/sshd_config se configuró para reenviar X11. Cuando yo ssh -X de vuelta a localhost, obtengo mi DISPLAY configurado correctamente.

Forzar DISPLAY Desarmarse no fue demasiado difícil. Solo necesitaba ver lo que sshd y ssh estaba haciendo para configurarlo correctamente. Aquí está el resultado completo de todo lo que hice en el camino.

    [email protected]:~$ mkdir ~/dummy-sshd
    [email protected]:~$ cp -r /etc/ssh/* ~/dummy-sshd/
    cp: cannot open `/etc/ssh/ssh_host_dsa_key' for reading: Permission denied
    cp: cannot open `/etc/ssh/ssh_host_rsa_key' for reading: Permission denied

En lugar de usar sudo para forzar la copia de mi ssh_host_{dsa,rsa}_key archivos en su lugar, utilicé ssh-keygen para crear archivos ficticios para mí.

    [email protected]:~$ ssh-keygen -t rsa -f ~/dummy-sshd/ssh_host_rsa_key
    Generating public/private rsa key pair.
    Enter passphrase (empty for no passphrase): 
    Enter same passphrase again: 
    Your identification has been saved in /home/blyman/dummy-sshd/ssh_host_rsa_key.
    Your public key has been saved in /home/blyman/dummy-sshd/ssh_host_rsa_key.pub.

Enjuague y repita con -t dsa:

    [email protected]:~$ ssh-keygen -t dsa -f ~/dummy-sshd/ssh_host_dsa_key
    # I bet you can visually copy-paste the above output down here

Editar ~/dummy-sshd/sshd_config para apuntar a la nueva correcta ssh_host archivos clave.

    # before
    [email protected]:~$ grep ssh_host /home/blyman/dummy-sshd/sshd_config 
    HostKey /etc/ssh/ssh_host_rsa_key
    HostKey /etc/ssh/ssh_host_dsa_key

    # after
    [email protected]:~$ grep ssh_host /home/blyman/dummy-sshd/sshd_config 
    HostKey /home/blyman/dummy-sshd/ssh_host_rsa_key
    HostKey /home/blyman/dummy-sshd/ssh_host_dsa_key

Quémalo sshd en un nuevo puerto en modo no desconectado:

    [email protected]:~$ sshd -p 50505 -f ~/dummy-sshd/sshd_config -d
    sshd re-exec requires execution with an absolute path

Vaya, mejor corrige ese camino:

    [email protected]:~$ /usr/sbin/sshd -p 50505 -f ~/dummy-sshd/sshd_config -d
    debug1: sshd version OpenSSH_5.5p1 Debian-4ubuntu6
    debug1: read PEM private key done: type RSA
    debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
    debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
    debug1: private host key: #0 type 1 RSA
    debug1: read PEM private key done: type DSA
    debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
    debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
    debug1: private host key: #1 type 2 DSA
    debug1: setgroups() failed: Operation not permitted
    debug1: rexec_argv[0]='/usr/sbin/sshd'
    debug1: rexec_argv[1]='-p'
    debug1: rexec_argv[2]='50505'
    debug1: rexec_argv[3]='-f'
    debug1: rexec_argv[4]='/home/blyman/dummy-sshd/sshd_config'
    debug1: rexec_argv[5]='-d'
    Set /proc/self/oom_adj from 0 to -17
    debug1: Bind to port 50505 on 0.0.0.0.
    Server listening on 0.0.0.0 port 50505.
    debug1: Bind to port 50505 on ::.
    Server listening on :: port 50505.

Pop una nueva terminal y ssh en localhost en el puerto 50505:

    [email protected]:~$ ssh -p 50505 localhost
    The authenticity of host '[localhost]:50505 ([::1]:50505)' can't be established.
    RSA key fingerprint is 81:36:a5:ff:a3:5a:45:a6:90:d3:cc:54:6b:52:d0:61.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added '[localhost]:50505' (RSA) to the list of known hosts.
    Linux skretting 2.6.35-32-generic #67-Ubuntu SMP Mon Mar 5 19:39:49 UTC 2012 x86_64 GNU/Linux
    Ubuntu 10.10
    
    Welcome to Ubuntu!
     * Documentation:  https://help.ubuntu.com/
    
    1 package can be updated.
    0 updates are security updates.
    
    Last login: Thu Aug 16 15:41:58 2012 from 10.0.65.153
    Environment:
      LANG=en_US.UTF-8
      USER=blyman
      LOGNAME=blyman
      HOME=/home/blyman
      PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
      MAIL=/var/mail/blyman
      SHELL=/bin/bash
      SSH_CLIENT=::1 43599 50505
      SSH_CONNECTION=::1 43599 ::1 50505
      SSH_TTY=/dev/pts/16
      TERM=xterm
      DISPLAY=localhost:10.0
    Running /usr/bin/xauth remove unix:10.0
    /usr/bin/xauth add unix:10.0 MIT-MAGIC-COOKIE-1 79aa9275ced418dd445d9798b115d393

Mira las últimas tres líneas allí. Fortuitamente tuve DISPLAY establecido, y tenía esas dos lindas líneas de /usr/bin/xauth.

A partir de ahí fue un juego de niños apartar mi /usr/bin/xauth para /usr/bin/xauth.old, desconectarse de ssh y detener el sshd, luego lanza sshd y ssh de nuevo en localhost.

Cuando /usr/bin/xauth se fue, no vi DISPLAY reflejado en mi entorno.

No sucede nada brillante aquí. La mayoría de las veces tuve suerte al elegir un enfoque sensato para intentar reproducir esto en mi máquina local.

Asegúrate de eso:

Tienes xauth instalado en el servidor (ver: xauth info/xauth list).
En el servidor tu /etc/ssh/sshd_config archivo tiene estas líneas:
```
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost no
```
En el lado del cliente tu ~/.ssh/config archivo tiene estas líneas:
```
Host *
  ForwardAgent yes
  ForwardX11 yes
```
En el lado del cliente, tiene instalado el servidor X (por ejemplo, macOS: XQuartz; Windows: Xming).

Luego, para hacer el reenvío X11 usando SSH, necesita agregar -X para usted ssh comando, por ejemplo

ssh -v -X [email protected]

luego verifique que su DISPLAY es no vacío por:

echo $DISPLAY

Si es así, entonces tener un parámetro detallado para ssh (-v), compruebe si hay advertencias, p. ej.

debug1: No xauth program.
Warning: untrusted X11 forwarding setup failed: xauth key data not generated

En caso de que tengas no confiable X11 como se muestra arriba, entonces tratar -Y bandera en su lugar (si confía en el anfitrión):

ssh -v -Y [email protected]

^{Consulte: ¿Qué significa “Advertencia: la configuración de reenvío X11 no confiable falló: no se generaron los datos de la clave xauth” al usar ssh’ing con -X?}

En caso de que hayas advertencia: No hay datos de xauth, puede intentar generar un nuevo .Xauthority archivo, por ejemplo

xauth generate :0 . trusted
xauth list

Ver: Crear / reconstruir un nuevo archivo .Xauthority

Si tiene advertencias diferentes a las anteriores, siga las pistas adicionales.

¡Haz clic para puntuar esta entrada!

(Votos: 0 Promedio: 0)

¿Cómo reenviar X a través de SSH para ejecutar aplicaciones gráficas de forma remota?

Solución:

Utiliza Nuestro Buscador

Preguntas Relacionadas: