Working remotely

Introduction

PCAnywhere sells for dollars – gobs of dollars. Most of the equivalents also cost money. however, there are ways you can administer your Linux box (or even your Windows box) from another site. Depending on your requirements and restrictions, there are three or four methods you can use, and I’ll go through them. I deliberately don’t cover the issue of copying files here, as that is covered in other ways by using ftp, or www (or Point-To-Point software that usually isn’t allowed within a corporate environment). So, this tutorial only documents the ways you can get to your machine to run programs.

SSH

First off, I’ll cover SSH. SSH has pretty much outdated telnet as a means of communicating with your remote box. Telnet is universally accepted as being insecure as anything, even WHEN you turn on encryption – because the initial password and username go “over the wire” in cleartext. So, it’s ssh, and not telnet.

TTY only

It’s a terminal method of communicating with the computer at the remote end, instead of using a GUI. The old hands would remember their time with DOS, the even older hands will remember a time when there WERE no GUI programs, and it was ALL text.

Terminal is text. Pure and simple. If you don’t have an X session running on your local machine (by the use of either of X.org, XFree86, or Cygwin’s X server), then don’t count on being able to start up any X programs. It won’t work, unless you have X running on your local machine, which I’ll describe in another paragraph.

So – no graphics – unless you count those linedrawing characters and upper-ASCII characters, or using ANSI to provide colours. So don’t expect to start up a copy of notepad, xchat, or IE – it just won’t happen. It’ll turn up on the remote end’s desktop instead of your own, and that’s probably not what you want, as you have no way of terminating these programs. Unless you have …

SSH with X forwarding

If you DO have an X session running on your local machine, then count yourself lucky. Provided your system at home is set up to forward X connections, you can actually start an X program from home, and, several seconds (or perhaps even minutes) later, you’ll have a X program window appear on your screen. It’s pretty darn slow – rather like waiting for the RedSox to win a World Baseball Series. So no, you won’t be using it to play a game of UT2004.

Another point to mention. The faster the connection is between your box at home, and the box where you are, the faster the window redraws will happen. I find that it’s slow even over 10baseT. X forwarding will NOT work for connecting to your Windows box at home unless it too, happens to have an X server running THERE, for example, Cygwin’s X server, AND it happens to also have an SSH server running. Only Windows 2000/WinXP have the capability to do this, Windows ME and older do not. Now, down to the …

Nuts and bolts

So – you require a SSH server on your home box, configured to allow your login. You may also have firewalling issues to consider. Then you require some way of communicating WITH your server from where you are currently. For Linux, BSD, or OS X, there’s the command ssh.

ssh user@host

If your home machine happens to get assigned a dynamic IP when it connects to the Internet, you can often sign up to a redirection service, such as dyndns.org. This will typically redirect web requests, and may redirect other sorts of requests too, depending upon the service. So – point your local ssh client to the “handle” that you’ve signed up to with dyndns, or whatever, and that’s it, once you provide your password. If you’re bright like me, you’ll copy over your public key from your local machine over into your .ssh directory, and add it to .ssh/authorized_keys at the remote end. Pretty much once you do this, you never have to worry about passwords again. This presupposes you have set up sshd to allow the use of keys, rather than only passwords.

A note: your .ssh directory contents must ONLY be visible to the user themselves, and NOT viewable by others on the machine, or sshd will refuse to use your files. The dir MUST be chmodded to 0700.

drwx------ viking root 2 Aug 2 2003 /home/viking/.ssh

For Windows, there are a couple of alternatives. There’s PuTTY, which can do telnet, or ssh, and allows you to save session settings for a variety of hosts. The window that gets produced can be resized to any size you wish within the limits of your windowing environment.

Another option is a program called TeraTERM. I’ve never used this program, but apparently it has similar capabilities.

That covers tty access to your machine.

VNC

Then, there’s the Linux equivalent to RDP. It’s called VNC. It doesn’t have quite the same weaknesses as Remote Desktop Protocol, but I’d imagine there are one or two weaknessess too, dependent upon firewalling. You can run a vnc server that attaches to your current running X session (x0rfbserver), or you can start a completely different session (vncserver) with its own programs.

I already mentioned one of the disadvantages – firewalling. Another disadvantage is: these programs don’t behave like Windows programs unless your vncserver is also running on a Windows box. You gain none of the OLE advantages you would otherwise have with RDP sessions (if indeed, they support OLE yet, or COM, or whatever). They behave like static windows, often with a shared clipboard if your home window manager supports one (most do).

Now let me mention an advantage.

In comparison to RDP, VNC can be set up to either behave like RDP – one write, all read, or otherwise, all read, all write.It is really easy to change, although it might require that all viewers reconnect when you toggle the status and restart the server. This way, you can do what I believe Remote Desktops were MEANT to do. BOTH (or ALL) users can interact with the windowing session.

RDP

This is more for the WinHeads amongst you that need to administer a Windows XP box from a remote location. It’s a lot more difficult to actually keep this one safe, as you have to somehow allow your machine at home to acknowledge your initial RDP request from a remote location, and (thankfully in some cases) Microsoft have elected to make this default to NO. But, apparently, it can be done. This will only work with other RDP clients that understand the protocol that the windows box at home would use. In short, if work doesn’t support it, tough.

There is another disadvantage. RDP is typically many-read, one write by default, and I think it’s very difficult to change that. What this means is that – everyone in a RDP session can see what is happening, but only one person at a time can make changes. Once the person has made changes, the person MUST return control to the originator of the RDP invitation. If they don’t, you end up with a hung desktop.

Then, there’s always the Web.

Webmin

If you only have a limited range of tasks you ever need to do, then you may also want to consider using webmin. This acts just like a webserver, but sits on port 10,000 instead. Firewalling issues may rear their ugly heads again, like usual. But other than that, you can set up webmin on the remote end, and use your web browser to log in and select from a set of administration tasks you wish to perform. Don’t forget to set up webmin so that it will respond to requests from wherever you expect to work from, and NOWHERE ELSE. You can add firewalling to this too.

I also saw a “terminal” in the collection of applets that webmin supplies, so that if you just HAVE to have one, you’ve got one available. The only restrictions are: you’ll have to have java running in your local machine for the applet to work, and the shell is only opened to the same host that webmin sits on. But then, that’s what you wanted, wasn’t it?

So install webmin, and start it up at system startup. Then, when you need to administer your box, fire up your browser, and point it at http://your.box:10000/

Wrap Up

Well, there we go. Three ways of accessing your system at home from anywhere else in the world that happens to have an Internet connection. I have glossed over a lot of details such as how to set up ssh, webmin, and VNC, as there is normally enough documentation with the software to help out. After all, this is only meant to be a starting point. Good luck.