I avoid it :) I had a lot of control over the HW+SW deployment, hence the software was preinstalled (although I could imagine scripting an on-demand installer as well). With reverse SSH (the workstation connects to a server outside the NAT), no port forwarding is necessary. Although the tunnel-in-tunnel method used introduces additional network overhead and latency, it is acceptable for an occasional remote session (VPNs were considered, but ultimately on-demand userspace tools without a need for permission elevation were chosen), and has performed admirably over a wide variety of connections ;-)

Specifically:

- the workstation has screen, autossh, openssh-client, openssh-server and x11vnc preinstalled.

- there's a (local user-initiated) script, launched via a desktop icon

- that opens a GNU Screen session

- inside the screen, it autossh-s into a limited account on a jumphost and remote-forwards a (preconfigured) 127/8 address:port back to 127.0.0.1:22

- this makes the workstation's SSH server accessible on the jumphost

- (actually, several jumphosts are used - not everything is accessible from everywhere on the Internet, but I've yet to see a case when no jumphost can be contacted)

- remote user connects to workstation via SSH to jumphost and thence the forwarded SSH tunnel

- localforwards a port for a VNC connection

- runs x11vnc at workstation

- connects to x11vnc via the localforward

- and/or attaches to the GNU Screen

Voila, console and desktop access, with file transfer also available. The "remote" part is a single script, based originally on this script for VNC-through-SSH: http://so.piskvor.org/87443/vncssh.sh

SSH provides enough security (pubkeys), Autossh reestablishes the connection if needed.

I'm guessing the idea is you set it up for them one day when you are visiting and then wrap the whole thing up in a script that they can trigger by clicking a nicely labeled icon.