If it works, it works, if it doesn't you may need to dig around. Some NX variations and combinations can be a little prickly to set up. No additional auth (or encryption) details to think about as it just uses ssh. Less restricted than basic XDMCP since that part can be local to the serverĬleverer and faster than VNC. Session keeps running when you disconnect - can be handy for users, or in some situations a pain for admin or securityĬan be useful for multi-user setups.
(and could be done via VPN-style network)įairly simple (e.g. More involved (various configs, networking details) Next to impossible over WAN, at least without VPN (and SSH may be simpler than VPN). Some SSH servers disable X by default and your admin may have to configure it.Īvoids SSH overhead. Security (auth and encryption) is already handled. Good (draw commands, small lag for encryption) Nearly none (assuming exising SSH server)
In another common case this is an SSH tunnel (mostly just because end-to-end access over anything larger than a LAN is likely to be firewalled). this is usually transparent because it picks up the the contents of DISPLAY environment variable) In the typical case this is on the local machine (:0, :1, etc. You can tell any X app (technically X client) to display on any X display it can reach. If you want a remote X session that persists between (re)connections, look at ways of wrapping it - VNC, NX, Xpra, etc.Īlso note that, over time, X has become less efficient to use over a network see e.g. Note that remote X makes less sense over a large distance, or over wifi, as the connection and the session are transient, meaning the app would die the first network hiccup. Which were all connected to a single server that ran the actual programs for many such dumb terminals
0 kommentar(er)
