After ssh without -X to a machine, is it possible to change some settings (for example $DISPLAY) to make it work like ssh -X? If not, what is the reason? Thanks.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
You can create a second connection with X11 forwarding enabled, and then you can also use the DISPLAY environment variable from the second connection in the first.
In the 1st window:
$ ssh <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="a2d7d1c7d0e2cacdd1d6">[email protected]</a> <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="fa8f899f88ba9295898e">[email protected]</a>$ ...
In the 2nd window:
$ ssh -Y <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="fc898f998ebc94938f88">[email protected]</a> 'echo $DISPLAY; while sleep 3600; do :; done' localhost:10.0
Back to the 1st window:
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="b0c5c3d5c2f0d8dfc3c4">[email protected]</a>$ export DISPLAY=localhost:10.0 <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="6411170116240c0b1710">[email protected]</a>$ xterm
Unfortunately, ssh does nothing to contain the X11 (or other) forwardings to the process/session it started or to the user it runs as on the remote machine (eg. by using Unix sockets with/out checking credentials, or by using namespaces), and those forwardings are simple tcp listening sockets to which anybody on the remote machine can connect; all the security of the X11 forwarding relies on the X11 authentication.
X11 Forwarding By Hand
The sshd_config(5) manpage mentions that:
disabling X11 forwarding does not prevent users from forwarding X11 traffic, as users can always install their own forwarders.
Here is how you can do that by hand.
First of all, be sure to disable any host- or user- based access control that bypasses the x11 auth mechanism [1]:
$ xhost $(xhost | sed -n /:/s/^/-/p) access control enabled, only authorized clients can connect
Then show the auth info for DISPLAY=:0 on the local machine:
$ xauth list :0 ohzd/unix:0 MIT-MAGIC-COOKIE-1 a86982ddce0c1e1c1a8c5e8b2846e43b
Connect to the remote machine without any X11 forwarding:
$ ssh <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="d0a5a3b5a290b8aaa9e6e4">[email protected]</a> <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="ec999f899eac849695dad8">[email protected]</a>'s password: [motd snipped]
Open the command line via ~C and add a remote forwarding from the port 6000+43 to the unix socket corresponding to display :0:
hzy64$~C ssh> -R 6043:/tmp/.X11-unix/X0 Forwarding port.
Set the $DISPLAY envvar and add the auth info from the local to the remote machine:
hzy64$ export DISPLAY=localhost:43 hzy64$ xauth add $DISPLAY . a86982ddce0c1e1c1a8c5e8b2846e43b xauth: file /home/user/.Xauthority does not exist
Now you’re ready to go:
hzy64$ xterm
[1] because of a misguided bugfix, the user-based access control is turned on by default in Debian via /etc/X11/Xsession.d/35x11-common_xhost-local. Worse, it’s the only one available by default in XWayland where it also cannot be turned off. Any program that proxies of the X11 protocol (eg. xscope) will have to do its own x11 auth cookie checking (the way ssh does), unless it wants to open a gaping hole to the X11 server.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0