Pour que la redirection X11 fonctionne sur ssh, vous devez disposer de 3 éléments.
- Votre client doit être configuré pour transférer X11.
- Votre serveur doit être configuré pour autoriser le transfert X11.
- Votre serveur doit pouvoir configurer l'authentification X11.
Si vous avez les n ° 1 et n ° 2 en place mais qu'il vous manque la n ° 3, vous obtiendrez une variable d'environnement DISPLAY vide.
De la soupe aux noix, voici comment faire fonctionner la transmission X11.
Sur votre serveur, assurez-vous que / etc / ssh / sshd_config contient:
X11Forwarding yes
X11DisplayOffset 10
Vous devrez peut-être SIGHUP pour qu'il prenne ces modifications en compte.
cat /var/run/sshd.pid | xargs kill -1
Sur votre serveur, assurez-vous que xauth est installé.
belden@skretting:~$ which xauth
/usr/bin/xauth
Si xauth n'est pas installé, vous rencontrerez le problème de "variable d'environnement DISPLAY vide".
Sur votre client, connectez-vous à votre serveur. Assurez-vous de dire à ssh d'autoriser le transfert X11. je préfère
belden@skretting:~$ ssh -X blyman@the-server
mais vous pouvez aimer
belden@skretting:~$ ssh -o ForwardX11=yes blyman@the-server
ou vous pouvez le configurer dans votre ~ / .ssh / config.
Je rencontrais cette variable d’environnement DISPLAY vide plus tôt aujourd’hui lorsque ssh s’est inséré dans un nouveau serveur que je n’administre pas. Repérer la partie manquante de xauth était un peu amusant. Voici ce que j'ai fait et ce que vous pouvez faire aussi.
Sur mon poste de travail local, où je suis administrateur, j'ai vérifié que / etc / ssh / sshd_config était configuré pour transférer X11. Quand je ssh -X retourne à localhost, mon DISPLAY est configuré correctement.
Forcer DISPLAY à se désinstaller n'était pas trop difficile. J'avais juste besoin de regarder ce que sshd et ssh faisaient pour le configurer correctement. Voici le résultat complet de tout ce que j'ai fait en cours de route.
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
Au lieu d'utiliser sudo pour forcer la copie de mes fichiers ssh_host_ {dsa, rsa} _key, j'ai utilisé ssh-keygen pour en créer des factices.
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.
Rincez et répétez avec -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
Éditez ~ / dummy-sshd / sshd_config pour qu'il pointe vers les nouveaux fichiers de clé ssh_host appropriés.
# 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
Lancez sshd sur un nouveau port en mode sans détachement:
blyman@skretting:~$ sshd -p 50505 -f ~/dummy-sshd/sshd_config -d
sshd re-exec requires execution with an absolute path
Oups, mieux vaut corriger ce chemin:
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.
Ouvrez un nouveau terminal et ssh dans localhost sur le port 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
Regardez les trois dernières lignes. J'avais fortuitement le jeu DISPLAY et ces deux jolies lignes de / usr / bin / xauth.
À partir de là, c’était un jeu d’enfant de déplacer mon / usr / bin / xauth vers /usr/bin/xauth.old, de se déconnecter de ssh et d’arrêter sshd, puis de relancer sshd et ssh dans localhost.
Lorsque / usr / bin / xauth était parti, je ne voyais pas DISPLAY reflété dans mon environnement.
Il n'y a rien de brillant ici. La plupart du temps, j'ai eu la chance de choisir une approche sensée pour essayer de reproduire cela sur ma machine locale.