Eric Stewart: Running Off At The Mouth

Previously, I had regaled you with the story of utilizing Synergy to use two workstations (with separate screens) but only one keyboard/mouse combination.  In this, the Synergy Server (where the keyboard/mouse are connected) was the Windows 7 side, and the client was the XUbuntu box.  Since Synergy on its own is not encrypted in any way, Cygwin was used on the Windows box to provide an always-on SSHD, and an SSH tunnel would be established from the Linux workstation to the Windows box to encrypt the communication between the two.  In this sense, the Windows is the server twice over: both for the SSH tunnel and for Synergy.

At home, this works great.  The Linux system isn’t on that often because my home system is more for games and websurfing.  At work … well, the Windows workstation is dual 22″ widescreen, but roughly 99% of the time the only two apps running on it are Thunderbird and Chrome.  Meanwhile, over on the single 19″ screen Linux box, I have a pile of 100×50 terminal Windows open, fighting for screen space.

So, I’m on the verge of taking my primary workstation at work and making it an XUbuntu box.  I still need Windows, and I still have a second (older, slower) machine, so I decided to switch which one did what.

But then how do you set it all up?

Turns out, with a little Googling, I discovered that when it comes to creating a service on the Windows box to establish the SSH tunnel, most folks advise not bothering; instead, they suggest making your Windows Synergy client the SSHD server.  So, the instructions for setting up Cygwin are essentially identical to the previous article.  The catch is that to establish your tunnel, you need to specify that it goes the other direction.  On the Linux workstation (which is now your Synergy Server) instead of:

ssh -4 -f -N -L localhost:24800:remotehost.address.or.ip:24800 remotehost.address.or.ip

which says “grab port 24800 here on the loopback, and stream the data to 24800 on remote host”, you use:

ssh -4 -f -N -R localhost:24800:localhost:24800 remotehost.address.or.ip

which essentially says “go to remote host, listen to port 24800 on that system’s loopback, and send the data to this system’s loopback”, and that should get you going in the right direction.

I currently have Synergy on the XUbuntu “server” running in Desktop mode.  That means Synergy doesn’t run until I’m logged in (you can try running it in “Service” mode or setting up a boot script to launch synergys with a configuration file if you so desire).  I have a small perl script that continually runs the “-R” version of the SSH command outlined above (without the “-N” and with a “sleep 300” or something similar, see below) at boot.  Once the SSHD is up on Windows, and Synergy is running on the XUbuntu box, the tunnel will remain up.  Then, it’s just a matter of having Synergy on the Windows side running in “Service”/”Client” mode, pointing at 127.0.0.1, and it works.  Don’t forget: When running Synergy initially on the Windows side to set up the options, you should right click the icon and choose “Run as administrator” – otherwise the “Service” mode may not work (and your settings might not be saved).

Windows May Need Some Help

There is one little gotcha on the Windows side (I’m using 7, so if you’re not using 7, YMMV).  You’ll need to tweak a policy setting on the Windows side to use CTL-ALT-DEL.  Windows is particularly picky about how and when that key sequence will be interpreted (if you’re using Windows as a Synergy server, I have no clue how you pass C-A-D to another Windows client or even a Linux box, if you have need).  Go to “Start” – “Run” and type: “edit group policy”.  Under “Computer Configuration”, browse to:

Administrative Templates – Windows Components – Windows Logon Options

Then, double click on “Disable or enable software Secure Attention Sequence”.  Enable it, and under “Options”, change the pull down to “Services and Ease of Access applications.”

Preliminary observations:

When using Windows as the Synergy server, I have no issues – no hesitation or skipping.  Problem is, my prelim tests at home showed that going the other way wasn’t as smooth.  Some Googling suggested it has to do with the -N argument for the SSH tunnel command, which says “don’t execute a command.”  Thing is, without it you end up with a running shell on the remote machine as well as the tunnel, and this is problematic.  The only solution I’ve come up with so far is to run a command that might take a bit of time, but does nothing, like “sleep 5”.  There’s also a sequence issue:

1. Synergy on the (Linux in this article, specifically XUbuntu for me) server must be running first.  The tunnel will crash when the Synergy server is either not running or is stopped, and absent a -N, live remote shell of some sort, or some kind of other tunnel restarting operation, the tunnel will not attempt to reestablish (the ssh command establishing the tunnel will stop, and with no tunnel actively running, the entire SSH command exits as should be expected).
2. Once the Synergy server operation is running, then you can establish the tunnel (assuming SSHD is running on Windows).  After that, your clients will connect (due to the nature of the SSH tunnel, it doesn’t matter when the client is launched – if the tunnel/Synergy server is there, great!  If it’s not, the client will continually attempt to connect until killed/closed, or it successfully connects).

That’s where I’m at so far.  If I come up with more, I’ll try to remember to let you know here!