One of the great beauties of SSH is that X Forwarding can be (and usually is) enabled during compilation, so that after you have connected to another server with:
giles@tesla$ ssh remotehost giles@remotehost's password: No mail. giles@remotehost$ |
You can start X clients simply by typing them as you would at the console of the remote machine, and they will appear on your local machine:
giles@remotehost$ xclock & [1] 26416 giles@remotehost$ xterm & [2] 26422 giles@remotehost$ |
This is because SSH has already set up your local machine as the machine to display programs on:
giles@remotehost$ set | grep DISPLAY DISPLAY=tesla.gcsu.edu:10.0 giles@remotehost$ |
If you want to start using your local machine as the work environment for your remote host, one of the cooler things you can do is start an application manager like the Gnome project's "panel", or perhaps something like "tkdesk" or "xfm" if that's more your style. If you're not familiar with doing something like this, a word of warning: you have to be cautious about remembering where any given app has been launched from, either locally or remotely. If you're reconfiguring the remote host, and you type "rm -rf /usr/local/bin/*" on the wrong machine, it will be very painful ... One solution for that is to colorize your prompts differently on every machine you work on, with the host name prominently displayed.
Often X forwarding is turned off on servers that have a lot of users. My ISP in Toronto, for example, has it turned off, presumably because their business is dial-up connectivity and web hosting, so they don't want the machine bogged down by fifty users all running Netscape on their processors. I tend to turn it on on my servers, but they usually only have twenty or thirty users, and most of those people are only using FTP.