Per far funzionare l'inoltro X11 su ssh, avrai bisogno di 3 cose sul posto.
- Il client deve essere configurato per l'inoltro di X11.
- Il server deve essere impostato per consentire l'inoltro X11.
- Il tuo server deve essere in grado di configurare l'autenticazione X11.
Se hai sia il n. 1 che il n. 2 in posizione ma manca il n. 3, finirai con una variabile di ambiente DISPLAY vuota.
Soup-to-nut, ecco come far funzionare l'inoltro X11.
Sul tuo server, assicurati che / etc / ssh / sshd_config contenga:
X11Forwarding yes
X11DisplayOffset 10
Potrebbe essere necessario SIGHUP sshd in modo che rilevi queste modifiche.
cat /var/run/sshd.pid | xargs kill -1
Sul tuo server, assicurati di aver installato xauth.
belden@skretting:~$ which xauth
/usr/bin/xauth
Se xauth non è installato, si verificherà il problema "variabile ambiente DISPLAY vuota".
Sul tuo client, connettiti al tuo server. Assicurati di dire a ssh di consentire l'inoltro X11. preferisco
belden@skretting:~$ ssh -X blyman@the-server
ma ti potrebbe piacere
belden@skretting:~$ ssh -o ForwardX11=yes blyman@the-server
oppure puoi impostarlo nel tuo ~ / .ssh / config.
Oggi mi imbattevo in questa variabile di ambiente DISPLAY vuota quando mi trovavo in un nuovo server che non gestisco. Rintracciare la parte xauth mancante è stato un po 'divertente. Ecco cosa ho fatto e cosa puoi fare anche tu.
Sulla mia workstation locale, di cui sono amministratore, ho verificato che / etc / ssh / sshd_config fosse impostato per inoltrare X11. Quando faccio di nuovo ssh -X su localhost, ottengo il mio DISPLAY impostato correttamente.
Costringere DISPLAY a disinserirsi non è stato troppo difficile. Avevo solo bisogno di vedere cosa stavano facendo sshd e ssh per impostarlo correttamente. Ecco l'output completo di tutto ciò che ho fatto lungo la strada.
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
Invece di usare sudo per forzare la copia dei miei file ssh_host_ {dsa, rsa} _key in posizione, ho usato ssh-keygen per creare quelli fittizi per me stesso.
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.
Risciacquare e ripetere 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
Modifica ~ / dummy-sshd / sshd_config per puntare ai nuovi file di chiavi ssh_host corretti.
# 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
Avvia sshd su una nuova porta in modalità non distaccata:
blyman@skretting:~$ sshd -p 50505 -f ~/dummy-sshd/sshd_config -d
sshd re-exec requires execution with an absolute path
Whoops, meglio correggere quel percorso:
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 un nuovo terminale e ssh in localhost sulla porta 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
Guarda le ultime tre righe lì. Per fortuna ho impostato DISPLAY e ho avuto quelle due belle linee da / usr / bin / xauth.
Da lì è stato un gioco da ragazzi spostare da parte mia / usr / bin / xauth a /usr/bin/xauth.old, disconnettersi da ssh e arrestare sshd, quindi riavviare sshd e ssh su localhost.
Quando / usr / bin / xauth non c'era più, non ho visto DISPLAY riflesso nel mio ambiente.
Non sta succedendo niente di geniale qui. Principalmente ho avuto la fortuna di scegliere un approccio sano per provare a riprodurlo sulla mia macchina locale.