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 a

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 http://so.piskvor.org/87443/vncssh.sh SSH provides enough security (pubkeys), Autossh reestablishes the connection if needed.