Risposte:
È possibile creare una seconda connessione con l'inoltro X11 abilitato, quindi è anche possibile utilizzare la DISPLAY
variabile di ambiente dalla seconda connessione nella prima.
Nella prima finestra:
$ ssh user@host
user@host$ ...
Nella seconda finestra:
$ ssh -Y user@host 'echo $DISPLAY; while sleep 3600; do :; done'
localhost:10.0
Torna alla prima finestra:
user@host$ export DISPLAY=localhost:10.0
user@host$ xterm
Sfortunatamente, ssh
non fa nulla per contenere gli inoltri X11 (o altri) al processo / sessione avviato o all'utente che esegue come sul computer remoto (ad es. Utilizzando socket Unix con / out controllo credenziali o utilizzando spazi dei nomi), e tali inoltri sono semplici prese di ascolto tcp a cui chiunque sulla macchina remota può connettersi; tutta la sicurezza dell'inoltro X11 si basa sull'autenticazione X11.
La sshd_config(5)
manpage menziona che:
la disabilitazione dell'inoltro X11 non impedisce agli utenti di inoltrare il traffico X11, poiché gli utenti possono sempre installare i propri server di inoltro.
Ecco come puoi farlo a mano.
Prima di tutto, assicurati di disabilitare qualsiasi controllo di accesso basato su host o utente che ignori il meccanismo di autenticazione x11 [1]:
$ xhost $(xhost | sed -n /:/s/^/-/p)
access control enabled, only authorized clients can connect
Quindi mostra le informazioni di autenticazione per DISPLAY=:0
sul computer locale:
$ xauth list :0
ohzd/unix:0 MIT-MAGIC-COOKIE-1 a86982ddce0c1e1c1a8c5e8b2846e43b
Connettiti al computer remoto senza alcun inoltro X11:
$ ssh user@hzy64
user@hzy64's password:
[motd snipped]
Aprire la riga di comando tramite ~C
e aggiungere un inoltro remoto dalla porta 6000+43
al socket unix corrispondente al display :0
:
hzy64$~C
ssh> -R 6043:/tmp/.X11-unix/X0
Forwarding port.
Impostare $DISPLAY
envvar e aggiungere le informazioni di autenticazione dal locale al computer remoto:
hzy64$ export DISPLAY=localhost:43
hzy64$ xauth add $DISPLAY . a86982ddce0c1e1c1a8c5e8b2846e43b
xauth: file /home/user/.Xauthority does not exist
Ora sei pronto per partire:
hzy64$ xterm
[1] a causa di una correzione errata , il controllo degli accessi basato sull'utente è attivato di default in Debian tramite /etc/X11/Xsession.d/35x11-common_xhost-local
. Peggio ancora, è l'unico disponibile per impostazione predefinita in XWayland dove non può essere disattivato . Qualsiasi programma che xscope
esegue il proxy del protocollo X11 (ad es. ) Dovrà eseguire il proprio controllo dei cookie di autenticazione x11 (come fa ssh), a meno che non voglia aprire un buco nel server X11.
-X
sarebbe leggermente meglio di -Y
, no?
-X
, solo con -Y
. la gente non se ne accorge perché su molti sistemi (es. debian) ForwardX11Trusted
è impostato di yes
default e le opzioni -X
e -Y
sono equivalenti ;-)
change $DISPLAY to
. Il titolo della domanda corrente non può essere visualizzato per intero nei risultati di ricerca e la modifica di $ DISPLAY fa davvero parte della risposta, non fa parte della domanda.