SSH X11 non funziona

Ho un computer di casa e di lavoro, il computer di casa ha un indirizzo IP statico.

Se ssh dal mio computer di lavoro al mio computer di casa, la connessione ssh funziona ma le applicazioni X11 non vengono visualizzate.

Nel mio /etc/ssh/sshd_configa casa:

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

Al lavoro ho provato i seguenti comandi:

xhost + home HOME_IP
ssh -X home
ssh -X HOME_IP
ssh -Y home
ssh -Y HOME_IP

Il mio /etc/ssh/ssh_configal lavoro:

Host *
ForwardX11 yes 
ForwardX11Trusted yes

Il mio ~/.ssh/configal lavoro:

Host home
HostName HOME_IP
User azat
PreferredAuthentications password
ForwardX11 yes

Il mio ~/.Xauthorityal lavoro:

-rw------- 1 azat azat 269 Jun  7 11:25 .Xauthority

Il mio ~/.Xauthoritya casa:

-rw------- 1 azat azat 246 Jun  7 19:03 .Xauthority

Ma non funziona

Dopo aver effettuato una connessione ssh a casa:

$ echo $DISPLAY
localhost:10.0

$ kate
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
kate: cannot connect to X server localhost:10.0

Uso iptablesa casa, ma ho consentito la porta 22. Secondo quello che ho letto, è tutto ciò di cui ho bisogno.

UPD. Con-vvv

...
debug2: callback start
debug2: x11_get_proto: / usr / bin / xauth list: 0 2> / dev / null
debug1: richiesta dell'inoltro X11 con spoofing di autenticazione.
debug2: canale 1: richiesta x11-req conferma 1
debug2: client_session2_setup: id 1
debug2: impostazione fd 3 TCP_NODELAY
debug2: canale 1: richiesta conferma pty-req 1
...

Quando si tenta di avviare kate:

debug1: client_input_channel_open: ctype x11 rchan 2 vittoria 65536 max 16384
debug1: client_request_x11: richiesta da 127.0.0.1 55486
debug2: impostazione fd 8 O_NONBLOCK
debug3: fd 8 è O_NONBLOCK
debug1: canale 2: nuovo [x11]
debug1: conferma x11
debug2: la connessione X11 utilizza un protocollo di autenticazione diverso.
Connessione X11 rifiutata a causa di un'autenticazione errata.
debug2: X11 rifiutato 2 i0 / o0
debug2: canale 2: lettura non riuscita
debug2: canale 2: close_read
debug2: canale 2: input aperto -> drain
debug2: canale 2: ibuf vuoto
debug2: canale 2: invia eof
debug2: canale 2: input drain -> chiuso
debug2: canale 2: scrittura fallita
debug2: canale 2: close_write
debug2: canale 2: uscita aperta -> chiusa
debug2: X11 chiuso 2 i3 / o3
debug2: canale 2: invio chiuso
debug2: canale 2: rcvd chiuso
debug2: canale 2: è morto
debug2: canale 2: raccolta dei rifiuti
debug1: canale 2: gratuito: x11, nchannels 3
debug3: canale 2: stato: sono aperte le seguenti connessioni:
  # 1 sessione client (t4 r0 i0 / 0 o0 / 0 fd 5/6 cc -1)
  # 2 x11 (t7 r2 i3 / 0 o3 / 0 fd 8/8 cc -1)

# Lo stesso di cui sopra si ripete circa 7 volte

kate: impossibile connettersi all'host locale X server: 10.0

UPD2 Fornire la distribuzione Linux e il numero di versione.
Stai usando un ambiente GNOME o KDE predefinito per X o qualcos'altro che ti sei personalizzato?

azat: ~ $ kded4 -version
Qt: 4.7.4
Piattaforma di sviluppo KDE: 4.6.5 (4.6.5)
Demone KDE: $ Id $

Stai invocando ssh direttamente su una riga di comando da una finestra del terminale?
Che terminale stai usando? xterm, gnome-terminal o?
Come hai avviato il terminale in esecuzione nell'ambiente X? Da un menu? Tasti di scelta rapida? o ?

Dall'emulatore di terminale `yakuake`
Premere manualmente `Ctrl + N` e scrivere i comandi

Puoi eseguire xeyes dalla stessa finestra del terminale in cui ssh -X fallisce?

`xeyes` - non è installato
Ma `kate` o un'altra app kde è in esecuzione

Stai invocando il comando ssh come lo stesso utente con cui hai effettuato l'accesso alla sessione X?
From the same user

UPD3

Scarico anche sshfonti, e usando debug2()write perché segnala che la versione è diversa
vede alcuni cookie e uno di questi è vuoto, un altro èMIT-MAGIC-COOKIE-1

Il motivo per cui l'inoltro di ssh X non funzionava era perché ho un /etc/ssh/sshrcfile di configurazione.

La fine della sshd(8)pagina man afferma:

Se ~/.ssh/rcesiste, lo esegue; altrimenti, se /etc/ssh/sshrcesiste, lo esegue; altrimenti esegue xauth

Quindi aggiungo i seguenti comandi /etc/ssh/sshrc(anche dalla pagina man di sshd) sul lato server:

if read proto cookie && [ -n "$DISPLAY" ]; then
        if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
                # X11UseLocalhost=yes
                echo add unix:`echo $DISPLAY |
                    cut -c11-` $proto $cookie
        else
                # X11UseLocalhost=no
                echo add $DISPLAY $proto $cookie
        fi | xauth -q -
fi

E funziona!

Ogni volta che si verificano problemi con ssh, la prima cosa da fare è eseguire il client con l' -vopzione di fornire quell'output affinché altri possano ispezionare:

ssh -v user@somewhere

Immagino che il problema sia nel tuo sistema locale. Come stai invocando il comando ssh? Lo stai eseguendo manualmente in una shell? O viene eseguito come parte di una sceneggiatura? In entrambi i casi, ti consigliamo di assicurarti che l'ambiente locale sia DISPLAYimpostato correttamente. Deve anche essere impostato correttamente sul lato remoto, ma quel valore sarà diverso sul lato remoto rispetto al lato locale.

Da quello che hai scritto sembra che sia impostato correttamente sull'host remoto (e per estensione l'inoltro X11 è impostato correttamente da ssh). Sul sistema remoto hai:

$ echo $DISPLAY
localhost:10.0

Che cosa mostra questo sul lato locale? Dovrebbe essere facile controllare se ci si trova in una shell sia facendo eco al valore, sia avviando un'app X da quella shell ... puoi sempre usare il venerabile xeyesper quel tipo di test, ovviamente! :)

D'altra parte, se si sta invocando il comando ssh da uno script o associato a un tasto di scelta rapida, potrebbe non ereditare l'ambiente previsto, quindi DISPLAYla variabile di ambiente sul lato locale potrebbe non essere impostata affatto.

Inoltre, poiché sembra che tu stia armeggiando con il tuo .Xauthorityfile, potresti volerlo eliminare completamente, quindi disconnettersi dalla sessione X e riconnettersi in modo da ricrearlo automaticamente. Raramente c'è bisogno di confondere con il tuo .Xauthority, quindi provarlo è probabilmente solo una misura disperata che non ti aiuterà.

Quello che dovresti vedere sul lato locale è:

$ echo $DISPLAY
:0.0

Su un sistema configurato correttamente se si apre una shell non è necessario impostarla manualmente, dovrebbe essere ereditata dall'ambiente che ha avviato la shell. Tuttavia, ho visto le configurazioni di Windows Manager / Hotkey che non gestiscono correttamente l'ereditarietà delle variabili d'ambiente. Se hai un sistema Linux in esecuzione gnome-sessiono kde-sessionda cui usi lanciare shell o script, le variabili di ambiente della sessione X dovrebbero essere impostate correttamente come descritto nella documentazione di Ubuntu sull'ereditarietà delle variabili di ambiente :

Quando un processo padre crea un processo figlio, ad esempio quando eseguiamo il comando "gedit" dal terminale e "bash" (il processo padre) crea "gedit" (il processo figlio), il processo figlio eredita tutte le variabili di ambiente e valori che aveva il processo genitore.

...

Nota: nell'ambiente desktop grafico di Gnome, gnome-session è il processo principale di tutti i processi in esecuzione sul desktop. Questo fatto (insieme al principio di ereditarietà) è la chiave della nostra capacità di influenzare fortemente il funzionamento del nostro desktop con variabili di ambiente. Il processo equivalente in KDE è kde-session.

AGGIORNATO

Grazie per aver pubblicato l'output di ssh -vvv. In questo caso la verbosità extra -vvvrispetto a solo -vè utile. L'output di debug mi dice che l'inoltro X11 è impostato correttamente:

debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 1: request x11-req confirm 1

Ma :0nella prima riga mi porta a credere che ci sia ancora un errore di configurazione sul lato locale nel modo in cui stai invocando ssh. Su molti sistemi il valore predefinito DISPLAYè :0.0no :0. Stai in qualche modo impostando DISPLAYmanualmente il valore di te stesso prima di invocare il comando ssh?

Maggiori informazioni sul tuo sistema locale e su come stai invocando il comando ssh sarebbero utili a questo punto.

• Fornisci la tua distribuzione Linux e il numero di versione.
• Stai usando un ambiente GNOME o KDE predefinito per X o qualcos'altro che ti sei personalizzato?
• Stai invocando ssh direttamente su una riga di comando da una finestra del terminale?
• Che terminale stai usando? xterm, gnome-terminal o?
• Come hai avviato il terminale in esecuzione nell'ambiente X? Da un menu? Tasti di scelta rapida? o ?
• Riesci a correre xeyesdalla stessa finestra terminale dove ssh -Xfallisce?
• Stai invocando il comando ssh come lo stesso utente con cui hai effettuato l'accesso alla sessione X?

Quest'ultimo elemento è importante. Se stai eseguendo ssh come un altro utente (ad esempio, se hai aperto una finestra del terminale di root invece di una finestra del terminale di utente), allora incontrerai questo problema anche se stai impostando esplicitamente DISPLAY=:0poiché non hai i permessi per connettersi al server X per impostazione predefinita come un altro utente (anche come root!)

Le tue configurazioni sembrano essere a posto, ma prova "ssh -X home" come ha suggerito Agemen.

Inoltre, se tutto il resto fallisce, prova questo:

Dopo aver ssh sul computer di casa dal lavoro, sul tipo "home":

xauth list

Quindi, su "lavoro", digitare

xauth

Che ti darà un prompt "xauth>". Da qui, digita "aggiungi", quindi copia incolla l'output dell '"elenco xauth", una riga alla volta (ogni riga preceduta da "aggiungi"). Per esempio:

someguy@work:~$ xauth
Using authority file /var/run/gdm/auth-for-someguy-4MYV85/database
xauth> add work/unix:0  MIT-MAGIC-COOKIE-1  781cc753194fd55ecdf6c4cf105c40e3
xauth> 

Facci sapere.

Non capisco chiaramente se si desidera visualizzare le app remote sul display locale ( work) o se si desidera visualizzarle sul sistema remoto (home ).

Nel primo caso, penso ssh -X host dovrebbe essere abbastanza, senza bisogno di usare xhost.

Nel secondo caso, il sistema in cui è necessario utilizzare xhost è home, e non è sufficiente, è necessario esportare anche la variabile di visualizzazione.

xhost +work
export DISPLAY=:0.0

Non sono del tutto sicuro di quello che vuoi fare ... e poiché non so quali differenze esistano tra il tuo sistema e il mio, da un lato, e l'esatta configurazione necessaria per il tuo caso dall'altro (come Non sono uno specialista ^ _ ^). Spero che ti possa aiutare in qualche modo, poiché anche queste configurazioni hanno funzionato per me.