Come abilitare l'inoltro SSH X11 attraverso un server aggiuntivo?

33

Ho host A, B e C. Dall'host AI posso accedere solo tramite ssh B. Da BI posso accedere a C. Voglio essere in grado di eseguire programmi X11 su C e inoltrare la visualizzazione ad A.

Ho provato questo:

A $ ssh -XB
B $ ssh -XC
C $ xclock
Errore: impossibile aprire il display:

Ma non funziona

linux ssh x11

— lexsys
fonte

25

Esistono diversi modi per farlo, quello che preferisco è inoltrare la porta ssh:

Innanzitutto, connettiti alla macchina B e inoltra [localPort] a C: 22 a B

A$ ssh -L [localPort]:C:22 B

Quindi, connettiti a C da A attraverso questo tunnel appena creato usando [localPort], inoltrando X11

A$ ssh -X -p [localPort] localhost

Ora possiamo eseguire i programmi X11 su C e visualizzarli su A

C$ xclock

[localPort] può essere qualsiasi porta che non stai già ascoltando su A, spesso uso 2222 per semplicità.

— dave
fonte

3

non esattamente ... se X11Forwarding non è abilitato sul server C, non funzionerà. inoltre non funzionerà se non si imposta AllowTcpForwarding yes e GatewayPorts yes sul server B. questa risposta non è affatto accettabile

— asdmin

Hai un buon punto, non l'ho notato da quando uso debian, su cui X11Forwarding e AllowTcpForwarding sono abilitati per impostazione predefinita. GatewayPorts non è necessario da quando è disabilitato, SSH è ancora in ascolto su localhost e questo è ciò a cui ci stiamo connettendo. Ne avresti bisogno solo se volessi effettuare la seconda connessione tramite un IP esterno per la macchina A.

— Dave,

Al passaggio 1, non mi chiedeva la password per l'host B e finivo per collegarmi all'host C. In un'altra finestra ho provato il passaggio 2 e ho ricevuto "ssh_exchange_identification: connessione chiusa dall'host remoto".

— ms

ssh: connettersi all'host ... porta 22: connessione rifiutata durante l'esecuzione del primo comando

— Rodrigo

7

Questo può essere facilmente realizzato usando il port forwarding:

A$ ssh -NL 2022:C:22 B &
A$ ssh -X -p 2022 localhost
C$ xclock

Porta localhost: 2022 viene inoltrato a C: 22 tramite B SSH a C tramite localhost: 2022 Usa X come di consueto

— AgentK
fonte

2

Questo non funzionerà per gli stessi motivi indicati altrove nel caso B (il gateway) non abbia le opzioni di inoltro sshd corrette abilitate.

— g33kz0r,

non ho chiesto la mia password per ospitare B, il che è strano; e non ha funzionato, ho ricevuto il messaggio di errore "canale 2: apertura non riuscita: amministrativamente vietata: apertura non riuscita ssh_exchange_identification: connessione chiusa dall'host remoto"

— msb

4

Supponendo che il problema sia che la macchina di mezzo non ha X, ma altrimenti configurata per consentire l'inoltro di X11, basta installare xauth.

su un sistema basato su yum (fedora, redhat, centos):

B$ sudo yum install xauth

su un sistema basato su apt (debian, ubuntu):

B$ sudo apt-get install xauth

— Jayen
fonte

Yay, perfetto per il lampone senza testa pi.

— cmc

@cmc o usando ssh come un vpn.

— Jayen,

@cmc hai yumsu un pi?

— Jayen,

no-sudo apt-get install xauth

— cmc

3

Per le versioni più recenti di opensshd, è necessario disabilitarlo X11UseLocalhostaffinché funzioni.

È necessario eseguire questa operazione su Host C /etc/ssh/sshd_confige riavviare sshd affinché funzioni:

X11Forwarding yes
X11UseLocalhost no

— Brad Allison
fonte

2

Non è possibile inoltrare il display X11 se X11 Forwarding è disabilitato in qualsiasi SSH che si sta utilizzando.

man sshd_config:

X11Forwarding
  Specifies whether X11 forwarding is permitted. The argument must be “yes”
  or “no”.  The default is “no”.

Devi assicurarti che X11Forwarding sia abilitato sulla destinazione e su tutti gli sshds intermedi che stai utilizzando.

Solo un piccolo suggerimento: dovresti provare a usare VNC, l'inoltro del display X11 richiede abbastanza larghezza di banda.

— asdmin
fonte

I suggerimenti di @ AgentK e @ dave richiedono solo che X11Forwarding sia abilitato sull'host finale, poiché utilizzano un tunnel SSH per bypassare l'host intermedio. Il tuo suggerimento è quasi sicuramente il motivo per cui all'inizio il metodo del PO è fallito, ma ciò non significa che le risposte degli altri "non siano accettabili"

— Daniel Lawson,

le loro risposte erano difettose e risolvevano il problema, non risolvendolo. una risposta giusta e utile considererebbe la domanda originale risolvendola e fornendo altri modi solo nel caso in cui la domanda originale non fosse risolvibile. a proposito, nessuno dei due ha menzionato X11 Forwarding, che è essenziale

— asdmin

Su alcuni sistemi il valore predefinito è " yes".

— Brad Gilbert,

Ho verificato che X11Forwarding sia abilitato su B e C e AllowTcpForwarding sia impostato su yes su B. Ma il risultato dei miei comandi è lo stesso. E la risposta di David funziona bene per me.

— lexsys,

allora fallo, ma è solo un rimedio. puoi anche avviare ssh con il parametro '-v', oppure provare echo $ DISPLAY tutti i comandi ssh nidificati per scoprire dove $ DISPLAY si perde

— asdmin

2

Se passi spesso da A a C, puoi configurare B come proxy:

A:~/.ssh/config:

Host C
  ForwardX11   yes
  ProxyCommand ssh -W %h:%p B

allora è solo:

A$ ssh C xclock

— Jayen
fonte

1

Ci hai provato

A$ ssh -Y B
B$ ssh -Y C
C$ xlclock

Il flag -Y "Abilita l'inoltro X11 affidabile."

— Pyhimys
fonte

Lo stesso risultato.

— lexsys,

Questo ha funzionato per me, ma solo per scoprire quanto è lento X11

— Rodrigo,