Remote Access

Recently I wanted my wife’s machine to be able to run a particular program (kmymoney) from my computer. I trust my security more than hers, plus she runs Windows 7 and I couldn’t find a good way to run kmymoney on 64-bit Windows without running VirtualBox or something similar.

I tried x2go, and it is very cool, but seemed to have a lot of stability problems and very poor documentation. I’ve used nx before too, but it is hard to set up. So instead, I loaded good old cygwin onto the Windows machine. I used cygrunsvc to setup sshd on the Windows machine (you’ll see why in a minute) and made sure the X server runs on startup. I also modified the X startup so that it does not launch an xterm or anything on startup. Finally, I set both machines up so you can log into the right account (pat on the Windows box or money on the Linux box) using RSA certificates so no password is needed (google ssh with no password if you need to know how to do that). I set up the Windows ssh client to automatically do X forwarding to the Linux box (in .ssh/config).

So when my wife’s machine boots there’s nothing different from her point of view. Windows 7 hides the rarely used X icon down in the task bar. However, I made a batch file for her and there’s an icon for it on the start menu. It is very simple:

@echo off
c:\cygwin\bin\ssh moneypc /home/money/start pat patpc /cygdrive/c

There are 5 arguments to the ssh command. The moneypc name is the name of the Linux box in the .ssh/config file. That’s where the real IP address and all the options are (including the passwordless certificate names). Then /home/money/start is the name of a script on the Linux box (I’ll show you that in a minute).

The next three tokens are arguments to the start script. They identify the remote user’s name, the remote user’s machine name (by IP address, hostname, or entry into the .ssh/config file) and the user’s local file system.

Why does start need all that? Here’s the start script:

sshfs $USER@$IP:$ROOT /home/money/media/drivec &
fusermount -u -z /home/money/media/drivec

So the script actually uses sshfs to mount the user’s local file system on /home/money/media/local (similar to what x2go does). That’s why I needed sshd on the Windows box. Of course, this would work just as well on, say, my Linux laptop.

The x2go software also makes printing work — not an issue for me since my intent is this is all local and it forwards sound. I didn’t put a pulseaudio server on the Windows box, but if I did it would be easy enough to set the default server to the user’s IP address in the start script.

This is nowhere near as handy as using x2go. But it seems to be way more robust and its workable. I don’t intend to use this remotely, but it would be reasonable to do so since my firewall is open for ssh and ssh provides good encryption.

One thought on “Remote Access

Leave a Reply