ssh L'inoltro X11 non funzionerà

Question

Ho cercato di far funzionare il port forwarding di X11 dal mio laptop. Non riesco a capire perché non funzionerà.

ottengo questo messaggio quando si tenta di eseguire xterm:

X11 connection rejected because of wrong authentication. 
xterm Xt error: Can't open display: localhost:10.0 

Non so se questo è legato o no, ma quando faccio il login, ottengo questo messaggio:

/usr/bin/xauth: timeout in locking authority file /home/sphillips/.Xauthority 

Mi sono chiesto se il problema è che il mio utente locale sul mio portatile è skp e il nome utente su questo server è sphillips. Sono stato in grado di ottenere l'inoltro X11 per lavorare con gli altri miei computer che usano lo stesso login skp.

Inoltre, l'inoltro porta X11 funziona da una macchina Windows utilizzando Xming e Putty sullo stesso server. Devo configurare manualmente la variabile DISPLAY sull'indirizzo IP e visualizzare 0.0, ma funziona.

Ho eseguito un xhost + sulla mia macchina con il tentativo di tentare di aggirare eventuali problemi di sicurezza. Non funzionava ancora.

Sul server, ho verificare la configurazione:

$ sudo grep X11Forwarding /etc/ssh/sshd_config 
#X11Forwarding no 
X11Forwarding yes 
# X11Forwarding no 

E sulla mia macchina così:

$ sudo grep X11Forwarding /etc/ssh/sshd_config 
[sudo] password for skp: 
#X11Forwarding no 
X11Forwarding yes 
# X11Forwarding no 

Il mio server è RedHat Enterprise Linux 6 e il mio computer portatile è Fedora 15.

Qualcuno può darmi qualche idea su cosa cercare di far funzionare l'inoltro SSH X11 dal mio portatile?

Answer 1

Ho ottenuto lo stesso problema su un contenitore Debian OpenVZ e il problema sembrava provenire dal mio file/etc/hosts in cui "localhost" era interessato dall'IP LAN, non da 127.0.0.1.

Prima:

192.168.0.15 dagi dagi.domain.net localhost localhost.localdomain 

Dopo:

192.168.0.15 dagi dagi.domain.net 
127.0.0.1  localhost localhost.localdomain 

Dopo di che, sia ssh -X e ssh -Y lavorato come un fascino senza nemmeno riavviare sshd.

Answer 2

Ho finalmente trovato la risposta (almeno per la mia situazione)! Il problema era SELinux. Ho spento SELinux e ha funzionato senza problemi.

Se siete interessati a tutti i dettagli cruenti, potete leggere su di esso al numero my blog, ma lasciatemi dettagliare i fatti pertinenti qui ...

Sulla macchina remota, ho usato dmesg per visualizzare i messaggi di registrazione:

dmesg | tail 

ho trovato un certo numero di messaggi come questo:

type=1400 audit(1332520527.110:51337): avc: denied { read } for pid=25240 comm="sshd" name="authorized_keys" dev=dm-5 ino=167 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file 

È possibile controllare lo stato di SELinux con questo comando:

$ sestatus 
SELinux status: enabled 
SELinuxfs mount: /selinux 
Current mode: permissive 
Mode from config file: permissive 
Policy version: 24 
Policy from config file: targeted 

È possibile trasformarlo in modalità permissiva con questo comando:

setenforce 0 

Per ulteriori informazioni su SELinux, ho trovato Red Hat's guide helpful. Inoltre, per altri problemi SSH, ho trovato utile il David's blog per ottenere la registrazione per aiutare.

Per quanto mi riguarda, il mio inoltro X11 ha iniziato a funzionare senza problemi.

SELinux stava impedendo diverse altre cose. Non è stato possibile creare i file necessari per far funzionare la chiave di autenticazione. Ho anche trovato che bloccava ssh-keygen dalla creazione di chiavi nella home directory.

Answer 3

sudo grep X11Forwarding /etc/ssh/sshd_config 

X11Forwarding yes 
#sestatus 
SELinux status: enabled 
SELinuxfs mount: /selinux 
Current mode: permissive 
Mode from config file: permissive 
Policy version: 24 
Policy from config file: targeted 
#You can turn it to permissive mode with this command: 
#setenforce 0 

Answer 4

Oltre alla risposta di @Chl s, ho anche avuto un file ~/.Xauthority corrotto.

Per qualche motivo era di proprietà di root anche sotto la mia home directory. Così ho dovuto sudo -s e poi cancellato.

Poi ricreato con touch ~/.Xauthority

Dopo che X inoltro ha funzionato per me, sotto Ubuntu 14.04.

Answer 5

Mi sono imbattuto anche in questo. Ma nel mio caso è stato perché ho rimosso il supporto IPv6 alcuni giorni fa. Sono quindi passato a this thread spiegando come assicurarsi che sshd utilizzasse solo IPv4.

Questo è come ho fatto, aggiungere questo:

AddressFamily inet 

al ssh_config file (su Ubuntu/etc/ssh/sshd_config) e fare sshd ricaricare la sua configurazione (uccidere -SIGHUP pid-di- sshd).