Tx11ssh provides a way to (forward or reverse) tunnel X11 traffic over ssh connection.
Read the embedded manual page below for more information.
(Decide yourself which direction you consider being
"reverse" and which "forward" tunneling ;)
For technical info read TECHNOTES.
TX11SSH(1) User Commands TX11SSH(1)
NAME
tx11ssh - tunnel X11 traffic over ssh connection
SYNOPSIS
tx11ssh + [:[nums][:numd]] [--ssh-command command] [--ll num] args...
tx11ssh - [:[nums][:numd]] [--ssh-command command] [--ll num] args...
DESCRIPTION
tx11ssh provides a way to tunnel X11 traffic over ssh connection, in
either direction from initiator's point of view:
+ after connection is made, open windows from local clients to remote
display
- after connection is made, open windows from remote clients to local
display
The '+' option is convenient when ssh connection cannot be made in the
direction for standard X11 forwarding provided by ssh(1) and the '-' is
useful when sshd(8) is not configured to support X11 forwarding.
Both systems at the tunnel endpoints need to have tx11ssh installed and
available in PATH for normal usage.
OPTIONS
[:[nums][:numd]]
Use these numbers in unix sockets created. The first number nums is
the server socket to be created (i.e. /tmp/.X11-unix/Xnums) and the
second numd display server socket where co connect. Default values
are 11 and 0, respectively. Either can be omitted; e.g. :12 and ::1
are accepted.
Under Linux if nums or numd is prefixed with @ the filesystem inde-
pendent abstract namespace is used when creating these sockets.
(Note that abstract namespace is in network namespace securitywise.
For example LXC containers sharing network namespaces shares also
this filesystem-independent abstract namespace of unix domain sock-
ets.)
--ssh-command command
Execute command instead of 'ssh' for tunnel creation
--ll num
The "loglevel" of tx11ssh. With value 0 only severe warnings are
printed to stderr. With value 4 all messages are printed. Default
value is 2.
args...
"command line arguments" given to ssh when executed. Given verba-
tim. This is flexible; tx11ssh can be executed with alternate path
or wrappers can be used if needed, but this can also be used to
break things (e.g. wrong paths or -f/n flags given to ssh...).
SECURITY
The normal X security concerns apply here, e.g. xinput(1) can be used
to sneak X events of other windows. There is uid check for the X client
connecting to the X unix domain socket done; whether this is enough one
have to judge itself. Use of wrapx11usock.so shown below will at least
hide the X socket from other users (security by obscurity when thinking
about root users).
EXAMPLES
Case 1: One wants to open windows from Windows machine on a Unix desk-
top; but configuring sshd to work on windows (cygwin) environment is
nontrivial thing to do. From one Cygwin Terminal open x11ssh tunnel to
unix host and from another execute urxvt terminal using display 11
(which is tx11ssh default) to open the urxvt terminal window to remote
X display.
cygwin-term1$ tx11ssh + user@unixhost
cygwin-term2$ DISPLAY=:11 urxvt -fade 1 -tn rxvt-unicode &
Case 2: Remote sshd is not configured to support X11 forwarding, there-
fore it has to be done by "ourselves". The '-' option of tx11ssh makes
the X11 unix domain server socket available on a remote host; the com-
mand line on second terminal below uses the display 11 (tx11ssh
default) to open the window of remote command on local X display.
term1$ tx11ssh - user@host
term2$ ssh -f user@host env DISPLAY=:11 urxvt
Case 3: This is like case 2, but instead of using /tmp/.X11-unix/X11
for the X11 display unix domain socket, use $HOME/.ssh/X11 instead. The
wrapx11usock preload library does the path mangling to achieve this.
The reasons one might need this includes: security, multiuser support
and filesystem permissions. The wrapx11usock.sh script (and the source
for the preload library it uses) can be found in the source archive of
tx11ssh.
term1$ tx11ssh - user@host ./wrapx11usock.sh
term2$ ssh -f user@host ./wrapx11usock.sh urxvt
Case 4: Tunneling through a proxy. In some cases there the destination
machine is not directly reachable; there is a "proxy" machine in
between. Here are examples of ways how to handle the following two
cases: There is ssh server to be connected first (2 examples below) or
there is http CONNECT proxy to be used, respectively.
term$ tx11ssh - -oProxyCommand='ssh user@proxy -W %h:%p' user@host
term$ tx11ssh - -oProxyCommand='ssh user@proxy nc %h %p' user@host
term$ tx11ssh - -oProxyCommand='corkscrew https_proxy 8080 %h %p' user@host
The client execution (and all of the wrapping options) are the same.
(Instead of '-W' the 'nc' alternative provides option to add more for-
wardings to the proxy command (e.g. -D port); With '-W' all other for-
warding attempts are cleared out.)
DETACHING tx11ssh
Perfect "detaching" from shell is impossible to implement in tx11ssh
since one needs to detach from control terminal too. If detaching is
postponed after ssh tunnel is created, the ssh process cannot be
detached (anymore). If detach is done before executing ssh, interactive
authentication methods on terminal cannot be done anymore. Therefore
detaching, whenever anyone wants to do so, can be done at least with
the the help of following commands(*):
Non-interactive:
nohup setsid tx11ssh + remote > tx11ssh.log
nohup script -a -f -c 'tx11ssh + remote' tx11ssh.log >/dev/null
dtach -n tx11ssh-dtach-s sh -n 'exec tx11ssh + remote 2>tx11ssh.log'
Interactive, until detached:
dtach -c tx11ssh-dtach-s sh -c 'exec tx11ssh + remote 2>tx11ssh.log'
dtach -c tx11ssh-dtach-s script -c 'tx11ssh + remote' tx11ssh.log
screen tx11ssh + remote
tmux tx11ssh + remote
(*) Interestingly at least in linux, both setsid(1) & script(1) escapes
from terminal when execve'd from nohup(1) -- at least when executed
from interactive shell running on a tty.
AUTHOR
Written by Tomi Ollila.
LICENSE
This software is licensed under 2-clause (Simplified) BSD License.
SEE ALSO
ssh(1), Xserver(1), X(7)
tx11ssh 1.3 2014-03-19 TX11SSH(1)