Tx11ssh provides a way to (forward or reverse) tunnel X11 traffic over ssh connection.

Read the manual page below file list for more information.

(Decide yourself which direction you consider being "reverse" and which "forward" tunneling ;)

The source code and documentation of newer versions of tx11ssh is also available at


[ICO]NameLast modifiedSizeDescription

[DIR]Parent Directory  -  
[TXT]TECHNOTES09-Mar-2013 00:20 3.0K 
[   ]tx11ssh-1.0.tar.xz09-Mar-2013 00:20 17K 
[   ]tx11ssh-1.1.tar.xz02-Nov-2013 15:10 19K 
[   ]tx11ssh-1.2.tar.xz21-Feb-2014 22:49 21K 
[   ]tx11ssh-1.3.tar.xz20-Mar-2014 23:16 21K 

Manual page of tx11ssh version 1.2 follows:

TX11SSH(1)                       User Commands                      TX11SSH(1)

       tx11ssh - tunnel X11 traffic over ssh connection

       tx11ssh + [:[nums][:numd]] [--ssh-command command] [--ll num] args...

       tx11ssh - [:[nums][:numd]] [--ssh-command command] [--ll num] args...

       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

       -   after connection is made, open windows from remote clients to local

       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.

           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-

       --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.

           "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...).

       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).

       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

         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.)

       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(*):


         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.

       Written by Tomi Ollila.

       This software is licensed under 2-clause (Simplified) BSD License.

       ssh(1), Xserver(1), X(7)

tx11ssh 1.2                       2014-02-08                        TX11SSH(1)