Para que el reenvío X11 funcione sobre ssh, necesitará 3 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 ambos # 1 y # 2 en su lugar pero le falta el # 3, entonces terminará con una variable de entorno DISPLAY vacía.
Sopa de nueces, así es cómo hacer que el reenvío X11 funcione.
En su servidor, asegúrese de que / etc / ssh / sshd_config contenga:
X11Forwarding yes
X11DisplayOffset 10
Es posible que necesite SIGHUP sshd para que recoja estos cambios.
cat /var/run/sshd.pid | xargs kill -1
En su servidor, asegúrese de tener instalado xauth.
belden@skretting:~$ which xauth
/usr/bin/xauth
Si no tiene instalado xauth, se encontrará con el problema de "variable de entorno DISPLAY vacía".
En su cliente, conéctese a su servidor. Asegúrese de decirle a ssh que permita el reenvío de X11. yo prefiero
belden@skretting:~$ ssh -X blyman@the-server
pero te puede gustar
belden@skretting:~$ ssh -o ForwardX11=yes blyman@the-server
o puede configurar esto en su ~ / .ssh / config.
Me encontré con esta variable de entorno DISPLAY vacía el día de hoy cuando ingresé a un nuevo servidor que no administro. Rastrear la parte xauth que faltaba fue un poco divertido. Esto es lo que hice y lo que tú puedes hacer también.
En mi estación de trabajo local, donde soy administrador, verifiqué que / etc / ssh / sshd_config estaba configurado para reenviar X11. Cuando ssh -X vuelve a localhost, obtengo mi DISPLAY configurado correctamente.
Forzar que DISPLAY se desarmara no fue demasiado difícil. Solo necesitaba ver qué estaban haciendo sshd y ssh para configurarlo correctamente. Aquí está la salida completa de todo lo que hice en el camino.
blyman@skretting:~$ mkdir ~/dummy-sshd
blyman@skretting:~$ 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 mis archivos ssh_host_ {dsa, rsa} _key en su lugar, utilicé ssh-keygen para crear archivos ficticios para mí.
blyman@skretting:~$ 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:
blyman@skretting:~$ ssh-keygen -t dsa -f ~/dummy-sshd/ssh_host_dsa_key
# I bet you can visually copy-paste the above output down here
Edite ~ / dummy-sshd / sshd_config para apuntar a los nuevos archivos de clave ssh_host correctos.
# before
blyman@skretting:~$ grep ssh_host /home/blyman/dummy-sshd/sshd_config
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
# after
blyman@skretting:~$ 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
Inicie sshd en un nuevo puerto en modo sin desconexión:
blyman@skretting:~$ sshd -p 50505 -f ~/dummy-sshd/sshd_config -d
sshd re-exec requires execution with an absolute path
Vaya, mejor corrige ese camino:
blyman@skretting:~$ /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:
blyman@skretting:~$ 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í. Afortunadamente tenía el conjunto DISPLAY, y tenía esas dos líneas bonitas de / usr / bin / xauth.
A partir de ahí, fue un juego de niños mover mi / usr / bin / xauth a /usr/bin/xauth.old, desconectarme de ssh y detener el sshd, luego lanzar sshd y ssh nuevamente en localhost.
Cuando / usr / bin / xauth desapareció, no vi DISPLAY reflejado en mi entorno.
No hay nada brillante pasando aquí. Principalmente tuve la suerte de elegir un enfoque sensato para intentar reproducir esto en mi máquina local.