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:
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. Proxies/Gateways: 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 e.g.: 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,myhome.net:443 So it goes: viewer -> myproxy.west -> myhome.net -> 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: http://www.karlrunge.com/x11vnc/faq.html#ss_vncviewer http://www.karlrunge.com/x11vnc/faq.html#faq-ssl-java-viewer-proxy 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: "ssh.company.com" (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 Proxy/Gateway: ssh.company.com It is OK if the hostname "joes-pc" only resolves inside the firewall. The 2nd leg, from ssh.company.com -> joes-pc is done by a ssh -L redir and is not encrypted (but the viewer -> ssh.company.com 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 Proxy/Gateway: ssh.company.com,joes-pc this requires an SSH server also running on joes-pc. So an initial SSH login is done to ssh.company.com, 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 firstname.lastname@example.org) 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: email@example.com: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: firstname.lastname@example.org:0 Proxy/Gateway: http://myproxy.west:8080 or for SOCKS: VNC Host:Display: email@example.com: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,firstname.lastname@example.org: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,ssh.company.com,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. john%SPACEsmith@ssh.company.com UltraVNC Proxies/Gateways: UltraVNC has a "repeater" tool (http://www.uvnc.com/addons/repeater.html and http://koti.mbnet.fi/jtko/) 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: http://www.karlrunge.com/x11vnc/ultravnc_repeater.pl 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. MODE I 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 192.168.1.4:1, 192.168.1.4:5901, 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.) MODE II REPEATER: 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 http://sc.uvnc.com/ for details on how to create these binaries. Also there is a how-to here: http://www.simply-postcode-lookup.com/SingleClickUltraVNC/SingleClickVNC.htm 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: [TITLE] My UltraVNC SC III [HOST] 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: [TITLE] My UltraVNC SC I [HOST] 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 http://www.uvnc.com/pchelpware/SCIII/index.html) 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.