SSVNC:   SSL/SSH VNC viewer: Proxy support.

Proxies allow one to reach servers that are otherwise unreachable. In SSVNC, the proxy acts as a relay of the encrypted VNC packets.

SSVNC supports Web proxies, SOCKS proxies, and the UltraVNC repeater proxy. In SSH mode, a similar thing can be achieved by going through a Gateway machine.

SSVNC can chain together up to 3 Proxies to get to very difficult to reach VNC servers. A typical example of 2 Proxies would be to use a company's Web proxy to get out of the company's firewall, and then use the UltraVNC repeater or Apache SSL portal to go inside another firewall (another company or your home) to reach VNC server(s) running on machines there. In SSVNC one specifies chained proxies by separating them by commas:

      Proxy/Gateway:    http://webproxy.west:8080,repeater://

Here is the text about Proxies from the SSVNC Help panel:

                             SSVNC version: 1.0.29

 Here are a number of long sections on all sorts of proxies, Web, SOCKS,
 SSH tunnels/gateways, UltraVNC, Single Click, etc., etc.


    If an intermediate proxy is needed to make the SSL connection
    (e.g. a web gateway out of a firewall) enter it in the "Proxy/Gateway"
    entry box:

           VNC Host-Display:   host:number
           Proxy/Gateway:      proxy-host:port
           VNC Host-Display:   far-away.east:0
           Proxy/Gateway:      myproxy.west:8080

    If the "double proxy" case is required (e.g. coming out of a web
    proxied firewall environment and then INTO a 2nd proxy to ultimately
    reach the VNC server), separate them via a comma, e.g.:

           VNC Host-Display:   far-away:0
           Proxy/Gateway:      myproxy.west:8080,

    So it goes: viewer -> myproxy.west -> -> far-away (VNC)

    The proxies are assumed to be Web proxies.  To use SOCKS proxies:

           VNC Host-Display:   far-away.east:0
           Proxy/Gateway:      socks://mysocks.west:1080

    Use socks5:// to force the SOCKS5 proxy protocol (e.g. for ssh -D).

    You can prefix web proxies with http:// in SSL mode but it doesn't matter
    since that is the default for a proxy.  (NOTE that in SSH or SSH+SSL
    mode you MUST supply the http:// prefix for web proxies because in those
    modes an SSH tunnel is the default proxy type: see the next section.)

    Note that Web proxies are often configured to ONLY allow outgoing
    connections to ports 443 (HTTPS) and 563 (SNEWS), so you might
    have run the VNC server (or router port redirector) on those ports.
    SOCKS proxies usually have no restrictions on port number.

    You can chain up to 3 proxies (any combination of web (http://) and
    socks://) by separating them with commas (i.e. first,second,third).

    Proxies also work for un-encrypted connections ("None" or vnc://, Tip 5)

    See the ss_vncviewer description and x11vnc FAQ for info on proxies:

 SSH Proxies/Gateways:

    Proxy/Gateway also applies to SSH mode, it is a usually a gateway SSH
    machine to log into via ssh that is not the workstation running the
    VNC server.  However, Web and SOCKS proxies can also be used (see below).

    For example if a company had a central login server: ""
    (accessible from the internet) and the internal workstation with VNC was
    named "joes-pc", then to create an SSH tunnel one could put this in:

           VNC Host:Display:   joes-pc:0

    It is OK if the hostname "joes-pc" only resolves inside the firewall.

    The 2nd leg, from -> joes-pc is done by a ssh -L
    redir and is not encrypted (but the viewer -> 1st leg is
    an encrypted tunnel). 

    To SSH encrypt BOTH legs, try the "double SSH gateway" method using
    the "comma" notation:

           VNC Host:Display:   localhost:0

    this requires an SSH server also running on joes-pc.  So an initial SSH
    login is done to, then a 2nd SSH is performed (through
    port a redirection of the first) to login straight to joes-pc where
    the VNC server is running.

    Use username@host (e.g. joe@joes-pc if the
    user names differ between the various machines.  

    NOTE: On Windows you MUST always supply the username@ because putty's
    plink requires it.

    NON-STANDARD SSH PORT: To use a non-standard ssh port (i.e. a port other
    than 22) you need to use the Proxy/Gateways as well.  E.g. something
    like this for port 2222:

           VNC Host:Display:   localhost:0
           Proxy/Gateway:      joe@far-away.east:2222

    On Unix/MacOSX the username@ is not needed if it is the same as on
    the client.  This will also work going to a different internal machine,
    e.g. "joes-pc:0" instead of "localhost:0", as in the first example.

    A Web or SOCKS proxy can also be used with SSH.  Use this if you are
    inside a firewall that prohibits direct connections to remote SSH servers.

           VNC Host:Display:   joe@far-away.east:0
           Proxy/Gateway:      http://myproxy.west:8080

    or for SOCKS:

           VNC Host:Display:   joe@far-away.east:0
           Proxy/Gateway:      socks://mysocks.west:1080

    Use socks5://... to force the SOCKS5 version.  Note that the http://
    prefix is REQUIRED for web proxies in SSH or SSH+SSL modes (but it is
    the default proxy type in SSL mode.)

    You can chain up to 3 proxies (any combination of http://, socks://
    and ssh) by separating them with commas (i.e. first,second,third).

    Note: the Web and/or SOCKS proxies must come before any SSH gateways.

    For a non-standard SSH port and a Web or SOCKS proxy try:

           VNC Host:Display:   localhost:0
           Proxy/Gateway:      http://myproxy.west:8080,joe@far-away.east:2222

    Even the "double SSH gateway" method (2 SSH encrypted legs) described
    above works with an initial Web or SOCKS proxy, e.g.:

           VNC Host:Display:   localhost:0
           Proxy/Gateway:      socks://mysocks.west:1080,,joes-pc

    Some Notes on SSH localhost tunnelling with SSH options
      NoHostAuthenticationForLocalhost=yes and UserKnownHostsFile=file:

    Warning:  Note that for proxy use with ssh(1), tunnels going through
    'localhost' are used.  This means ssh(1) thinks the remote hostname is
    'localhost', which may cause collisions and confusion when storing
    and checking SSH keys.

    By default on Unix when a 'localhost' ssh host is involved the
    ssh option -o NoHostAuthenticationForLocalhost=yes is applied (see
    ssh_config(1) for details.)  This avoids the warnings and ssh refusing
    to connect, but it reduces security.  A man in the middle attack may
    be possible.  SSVNC prints out a warning in the terminal every time
    the NoHostAuthenticationForLocalhost option is used.

    On Unix to disable the use of NoHostAuthenticationForLocalhost set the env.
    variable SSVNC_SSH_LOCALHOST_AUTH=1. This may induce extra ssh(1) dialogs.

    On Unix a MUCH SAFER and more convenient way to proceed is to set the
    known hosts option in Options -> Advanced -> 'Private SSH KnownHosts file'
    Then, only for the host in the current profile, a private known_hosts
    file will be used and so there will be no 'localhost' collisions.
    This method is secure (assuming you verify the SSH key fingerprint)
    and avoids the man in the middle attack.

    On Windows, Putty/Plink is used and does not have the UserKnownHosts
    or NoHostAuthenticationForLocalhost features.  Keys are stored in
    the registry as localhost:port pairs and so it is possible to use the
    'Port Slot' option to keep the keys separate to avoid the dialogs and
    also maintain good security.

    Note that for the "double SSH gateway" method the risk from using
    NoHostAuthenticationForLocalhost is significantly less because the first
    ssh connection does not use the option (it connects directly to the remote
    host) and the second one is only exposed for the leg inside the first
    gateway (but is still vulnerable there when NoHostAuthenticationForLocalhost
    is used.)

    As with a username that contains a space, use %SPACE (or %TAB) to
    indicate it in the SSH proxies, e.g.

 UltraVNC Proxies/Gateways:

    UltraVNC has a "repeater" tool (
    and that acts as a VNC proxy.  SSVNC can
    work with both mode I and mode II schemes of this repeater.

    For Unix and MacOS X there is another re-implementation of the
    UltraVNC repeater:

    So one does not need to run the repeater on a Windows machine.

    Note that even though the UltraVNC repeater tool is NOT SSL enabled,
    it can nevertheless act as a proxy for SSVNC SSL connections.
    This is because, just as with a Web proxy, the proxy negotiations
    occur before the SSL traffic starts.  (There is a separate UltraVNC
    tool, repeater_SSL.exe, that is SSL enabled and is discussed below.)

    Note: it seems only SSL SSVNC connections make sense with the
    UltraVNC repeater.  SSH connections (previous section) do not seem to
    and so are not enabled to (let us know if you find a way to use it.)

    Unencrypted (aka Direct) SSVNC VNC connections (Vnc:// prefix in
    'VNC Host:Display'; see Tip 5) also work with the UltraVNC repeater.


    For the mode I UltraVNC repeater the Viewer initiates the connection
    and passes a string that is the VNC server's IP address (or hostname)
    and port or display to the repeater (the repeater then makes the
    connection to the server host and then exchanges data back and forth.)
    To do this in SSVNC:

           VNC Host:Display:   :0
           Proxy/Gateway:      repeater://myuvncrep.west:5900+joes-pc:1

    Where "myuvncrep.west" is running the UltraVNC repeater and 
    "joes-pc:1" is the VNC server the repeater will connect us to.

    Note here that the VNC Host:Display can be anything because it is
    not used; we choose :0.  You cannot leave VNC Host:Display empty.

    The Proxy/Gateway format is repeater://proxy:port+vncserver:display.
    The string after the "+" sign is passed to the repeater server for
    it to interpret (and so does not have to be the UltraVNC repeater;
    you could create your own if you wanted to.)  For this example,
    instead of joes-pc:1 it could be joes-pc:5901 or,, etc.

    If you do not supply a proxy port, then the default 5900 is assumed,
    e.g. use repeater://myuvncrep.west+joes-pc:1 for port 5900 on
    myuvncrep.west then connecting to port 5901 on joes-pc.

    X11VNC: For mode I operation the VNC server x11vnc simply runs as
    a normal SSL/VNC server:

       x11vnc -ssl SAVE

    because the repeater will connect to it as a VNC client would.
    For mode II operation additional options are needed (see below.)


    For the mode II repeater both the VNC viewer and VNC server initiate
    TCP connections to the repeater proxy.  In this case they pass a string
    that identifies their mutual connection via "ID:NNNN", for example:

           VNC Host:Display:   :0
           Proxy/Gateway:      repeater://myuvncrep.west:5900+ID:2345

    again, the default proxy port is 5900 if not supplied.  And we need
    to supply a placeholder display ":0".

    The fact that BOTH the VNC viewer and VNC server initiate outgoing
    TCP connections to the repeater makes some things tricky, especially
    for the SSL aspect.  In SSL one side takes the 'client' role and
    the other side must take the 'server' role.  These roles must be
    coordinated correctly or otherwise the SSL handshake will fail.

    We now describe two scenarios: 1) SSVNC in Listening mode with STUNNEL
    in 'SSL server' role; and 2) SSVNC in Forward mode with STUNNEL in
    'SSL client' role.  For both cases we show how the corresponding
    VNC server x11vnc would be run.

    SSVNC Listening mode / STUNNEL 'SSL server' role:

      By default, when using SSL over a reverse connection the x11vnc VNC
      server will take the 'SSL client' role.  This way it can connect to a
      standard STUNNEL (SSL server) redirecting connections to a VNC viewer
      in Listen mode.  This is how SSVNC with SSL is normally intended to
      be used for reverse connections (i.e. without the UltraVNC Repeater.)

      To do it this way with the mode II UltraVNC Repeater; you set
      Options -> Reverse VNC Connection, i.e. a "Listening Connection".
      You should disable 'Verify All Certs' unless you have already
      saved the VNC Server's certificate to Accepted Certs.  Or you can
      set ServerCert to the saved certificate.  Then click 'Listen'.
      In this case an outgoing connection is made to the UltraVNC
      repeater, but everything else is as for a Reverse connection.

      Note that in Listening SSL mode you must supply a MyCert or use the
      "listen.pem" one you are prompted by SSVNC to create.

      X11VNC command:

        x11vnc -ssl -connect_or_exit repeater://myuvncrep.west+ID:2345

    SSVNC Forward mode / STUNNEL 'SSL client' role:

      x11vnc 0.9.10 and later can act in the 'SSL server' role for Reverse
      connections (i.e. as it does for forward connections.)  Set these
      x11vnc options: '-env X11VNC_DISABLE_SSL_CLIENT_MODE=1 -sslonly'

      The -sslonly option is to prevent x11vnc from thinking the delay in
      connection implies VeNCrypt instead of VNC over SSL.  With x11vnc
      in X11VNC_DISABLE_SSL_CLIENT_MODE mode, you can then have SSVNC make
      a regular forward connection to the UltraVNC repeater.

      Note that SSVNC may attempt to do a 'Fetch Cert' action in forward
      connection mode to either retrieve the certificate or probe for
      VeNCrypt and/or ANONDH.  After that 'Fetch Cert' is done the
      connection to the UltraVNC repeater will be dropped.  This is a
      problem for the subsequent real VNC connection.  You can disable
      'Verify All Certs' AND also set 'Do not Probe for VeNCrypt'
      to avoid the 'Fetch Cert' action.  Or, perhaps better, add to
      x11vnc command line '-connect_or_exit repeater://... -loop300,2'
      (in addition to the options in the previous paragraphs.)  That way
      x11vnc will reconnect once to the Repeater after the 'Fetch Cert'
      action.  Then things should act pretty much as a normal forward
      SSL connection.

      X11VNC 0.9.10 command (split into two lines):

        x11vnc -ssl -connect_or_exit repeater://myuvncrep.west+ID:2345 \ 
             -env X11VNC_DISABLE_SSL_CLIENT_MODE=1 -loop300,2 -sslonly

    We recommend using "SSVNC Forward mode / STUNNEL 'SSL client' role"
    if you are connecting to x11vnc 0.9.10 or later.  Since this does
    not use Listen mode it should be less error prone and less confusing
    and more compatible with other features.  Be sure to use all of
    the x11vnc options in the above command line.  To enable VeNCrypt,
    replace '-sslonly' with '-vencrypt force'.  If you do not indicate
    them explicitly to SSVNC, SSVNC may have to probe multiple times for
    VeNCrypt and/or ANONDH.  So you may need '-loop300,4' on the x11vnc
    cmdline so it will reconnect to the UltraVNC repeater 3 times.

    Note that for UNENCRYPTED (i.e. direct) SSVNC connections (see vnc://
    in Tip 5) using the UltraVNC Repeater mode II there is no need to
    use a reverse "Listening connection" and so you might as well use
    a forward connection.

    For Listening connections, on Windows after the VNC connection you
    MUST manually terminate the listening VNC Viewer (and connect again
    if desired.)  Do this by going to the System Tray and terminating
    the Listening VNC Viewer.  Subsequent connection attempts using the
    repeater will fail unless you do this and restart the Listen.

    On Unix and MacOS X after the VNC connection the UltraVNC repeater
    proxy script will automatically restart and reconnect to the repeater
    for another connection.  So you do not need to manually restart it.
    To stop the listening, kill the listening VNC Viewer with Ctrl-C.

    In the previous sections it was mentioned one can chain up to 3
    proxies together by separating them with commas: proxy1,proxy2,proxy3.
    Except where explicitly noted below this should work for "repeater://..."
    as the final proxy.  E.g. you could use a web proxy to get out of a
    firewall, and then connect to a remote repeater.

    The UltraVNC SSL enabled repeater_SSL.exe is discussed below.

 UltraVNC Single Click:

    UltraVNC has Single Click (SC) Windows VNC servers that allow naive
    users to get them running very easily (a EXE download and a few
    mouse clicks).  See for details on how to create
    these binaries.  Also there is a how-to here:

    The SC EXE is a VNC *server* that starts up a Reverse VNC connection
    to a Listening Viewer (e.g. the viewer address/port/ID is hardwired
    into the SC EXE).  So SC is not really a proxy, but it can be used
    with UltraVNC repeater proxies and so we describe it here.

    One important point for SC III binary creation: do NOT include 
    "-id N" in the helpdesk.txt config file.  This is because the with
    SSVNC the Ultra VNC repeater IS NOT USED (see below for how to
    use it).  Use something like for helpdesk.txt:

       My UltraVNC SC III

       Internet Support XYZ
       -sslproxy -connect xx.xx.xx.xx:5500 -noregistry

    (replace xx.xx.xx.xx with IP address or hostname of the SSVNC machine.)

    The Unix SSVNC vncviewer supports the both the unencrypted "SC I"
    mode and the SSL encrypted "SC III" mode.  For both cases SSVNC
    must be run in Listening mode (Options -> Reverse VNC Connection)

    For SC I, enable Reverse VNC Connection and put Vnc://0 (see Tip 5
    below) in the VNC Host:Display to disable encryption (use a different
    number if you are not using the default listening port 5500).
    Then click on the "Listen" button and finally have the user run your
    Single Click I EXE.

    BTW, we used this for a SC I helpdesk.txt:

       My UltraVNC SC I

       Internet Support XYZ
       -connect xx.xx.xx.xx:5500 -noregistry

    For SC III (SSL), enable Reverse VNC Connection and then UNSET "Verify
    All Certs" (this is required).  Let the VNC Host:Display be ":0"
    (use a different number if you are not using the default listening
    port 5500).  Then click on the "Listen" button and finally have the
    user run your Single Click III EXE.

    Note that in Listening SSL mode you MUST supply a MyCert or use the 
    "listen.pem" one you are prompted by SSVNC to create.

 UltraVNC repeater_SSL.exe proxy:

    For repeater_SSL.exe SSL usage, with Single Click III or otherwise
    (available at
    it helps to realize that the ENTIRE connection is SSL encrypted,
    even the proxy host:port/ID:NNNN negotiation, and so a different
    approach needs to be taken from that described above in 'UltraVNC
    Proxies/Gateways'.  In this case do something like this:

           VNC Host:Display:   :0
           Proxy/Gateway:      sslrepeater://myuvncrep.west:443+ID:2345

    The sslrepeater:// part indicates the entire ID:XYZ negotiation must
    occur inside the SSL tunnel.  Listening mode is not required in this
    case: a forward VNC connection works fine (and is recommended).
    As before, the ":0" is simply a placeholder and is not used.
    Note that the UltraVNC repeater_SSL.exe listens on port 443 (HTTPS),
    (it is not clear that it can be modified to use another port.)

    Non-ID connections sslrepeater://myuvncrep.west:443+host:disp also
    work, but the 2nd leg repeater <-> host:disp must be unencrypted.
    The first leg SSVNC <-> repeater is, however, SSL encrypted.

    sslrepeater:// only works on Unix or MacOSX using the provided
    SSVNC vncviewer.  The modified viewer is needed; stock VNC viewers
    will not work.  Also, proxy chaining (bouncing off of more than one
    proxy) currently does not work for repeater_SSL.exe.

 VeNCrypt is treated as a proxy:

    SSVNC supports the VeNCrypt VNC security type.  You will find out more
    about this security type in the other parts of the Help documentation.
    In short, it does a bit of plain-text VNC protocol negotiation before
    switching to SSL/TLS encryption and authentication.

    SSVNC implements its VeNCrypt support as final proxy in a chain
    of proxies.  You don't need to know this or specify anything, but
    it is good to know since it uses up one of the 3 proxies you are
    allowed to chain together.  If you watch the command output you will
    see the vencrypt:// proxy item.

    You can specify that a VNC server uses VeNCrypt (Options -> Advanced)
    or you can let SSVNC try to autodetect VeNCrypt.

 IPv6 can be treated as a proxy for UN-ENCRYPTED connections:

    Read Tip 20 about SSVNC's IPv6 (128 bit IP addresses) support.
    In short, because stunnel and ssh support IPv6 hostnames and
    addresses, SSVNC does too without you needing to do anything.

    However, in some rare usage modes you will need to specify the IPv6
    server destination in the Proxy/Gateway entry box.  The only case
    this appears to be needed is when making an un-encrypted connection
    to an IPv6 VNC server.  In this case neither stunnel nor ssh are
    used and you need to specify something like this:

              VNC Host:Display:       localhost:0
              Proxy/Gateway:          ipv6://2001:4860:b009::68:5900

    and then select 'None' as the encryption type.  Note that the above
    'localhost:0' setting can be anything; it is basically ignored.

    Note that on Unix, MacOSX, and Windows un-encrypted ipv6 connections
    are AUTODETECTED and so you likely NEVER need to supply ipv6://
    Only try it if you encounter problems.  Also note that the ipv6://
    proxy type does not work on Windows, so only the autodetection is
    available there.

    Note that if there is some other proxy, e.g. SOCKS or HTTP and that
    proxy server is an IPv6 host (or will connect you to one) then any
    sort of connection through that proxy will work OK: un-encrypted as
    well as SSL or SSH connections, etc.

    Unencrypted connection is the only special case where you may need
    to specify an ipv6:// proxy.  If you find another use let us know.

    See Tip 20 for more info.