Eric Stewart: Running Off At The Mouth

This page is subject to change; I might later update it with instructions regarding Synergy 1.4.x, when I’ve installed it.

Synergy is a software package available for Linux, Windows, and Mac that allows you to control any number of systems from a single keyboard and mouse.  It does not do any video; each workstation is to have its own screen.  You set Synergy up so that when you move the mouse to an edge of a screen on one system, it appears on the edge of another.  So, it’s not a KVM solution … just a KM.

Synergy’s current drawback is that there is no built in encryption.  So, if you slide your mouse over to a Linux system and type in a password, that password is going over the network in clear text.  And while you shouldn’t be using Synergy over a network that you don’t trust, still, there are things you can do to encrypt the traffic between a Synergy client and the Synergy server.

SSH Tunnels and Cygwin

SSH supports Tunnels.  Essentially you tell SSH: “Hey, set up a process that listens to a particular (must be currently unused) port here, send the data encrypted to a server machine, and tell the server machine to dump the data to a particular port (that hopefully has something listening to it) on the remote machine.”  For Synergy, you don’t have to do anything different to the server box to encrypt the traffic … assuming that box is already running the Synergy server and an SSH server.  However, SSH not being native to Windows … this was an issue for me.  Luckily Google hooked me up with some really nice instructions that I will basically regurgitate here, but without the helpful pictures (because I’m just mean):

1. Download the most recent setup.exe for Cygwin.
2. Run it (which you may want to do by right clicking it and “Run as Administrator”).  At a minimum, you’ll need to install “openssh:” under “Net”  (as well as the basic stuff like a shell and whatnot) by clicking on the “n/a” under “Bin?” and making it become a nice x’ed out box.  There’s a lot that Cygwin can do for the budding Linux user, so if it’s new to you, you might want to look into it.
3. Go through the rest of the setup process for Cygwin by “Next>”ing through.
4. Once the setup is done (you may want to reboot at this point), go to your “Cygwin Terminal” (or possibly your “Cygwin Bash Shell”) icon and right click it, choosing “Run as Administrator”.  Then at the prompt enter “ssh-host-config”.
5. The “ssh-host-config” script will ask to create a new account – let it.  You should also let it install sshd as a service.
6. When asked to “Enter the value of CYGWIN for the daemon:”, type “ntsec”.
7. Unless you know for sure of a privileged account, when prompted to create one, be sure to say “no” to the “different name” question, and “yes” to allowing the script to create this user.  Then you’re going to have to give that user a password you know.  Some systems have password guidelines so be sure at this point that your password will satisfy those guidelines to avoid issues.
8. Before starting the service, you’ll want to make sure the SSHD can accept connections through your Windows Firewall.  It’s port 22 (TODO: Write an article about how to create this rule if it doesn’t exist).  You might also want to narrow the “Scope” in the rule, limiting where your SSH server will accept connectivity from.
9. Start the service.  Many ways to do this; I like to right click “Computer” and use the “Manage” option, which has under “Services and Applications” a “Services” option.  You’ll find what you’re looking for listed under “CYGWIN sshd”.
10. Next try logging in.  If it doesn’t work … um, start Googling.  Things to check are making sure the service is running, that you know your password, that you’re using the right account, and the above mentioned Windows Firewall hole.

You’re going to have to log in (or at least attempt to) at least once to get your host keys worked out.  SSH likes to identify systems using these keys. If SSH attempts to connect to a system and the remote system’s key has changed, it means any number of things, a few of which are:

1. The system has been replaced or rebuilt.
2. Someone’s listening in the middle.

If you’ve rebuilt or replaced a system, then you will get a message explaining what you need to do to resolve the issue with the keys (in more recent implementations, you just use ssh-keygen to remove the offending key, reconnect and accept the new key).

If you think it’s #2, that’s a problem that unfortunately is beyond the scope of this article.

Next, we install Synergy.  While writing this article I was using version 1.3.8 (see my article on a recent Ubuntu upgrade for notes about that), but for the purposes of completeness I decided to upgrade to the most recent beta of 1.4.x (I had also been using a different SSH server option on the Windows box but after having found instructions for Cygwin, preferred that; my previous SSH server option was just a stripped down version of Cygwin anyway).  EDIT: I lied – I haven’t committed to the beta quite yet.

Synergy On The Server : Arranging Your Screens

Installing Synergy is mainly academic – download and install for your given platform (okay I lied – there may be issues installing the beta under Ubuntu 12.04).  It’s configuring Synergy that’s the hard part.

On the Windows server, you’ve already gotten SSHD running per above.  That really was the hard part.  When running the Synergy GUI, always be sure to right click it and run it as Administrator – it’s not savvy to the ways of the UAC.

Once you run it, you’ll want to choose the “Share this computer’s keyboard and mouse (server)” radio option.  Before using the “Configure …” option there:

1. Check the options under “Options …”  Personally I uncheck everything, except the “Synchronize screen savers” option … which doesn’t seem to work for me 100% anyway.
2. Under “Advanced …” you’ll want to set the “Screen Name:” of your Windows server.  If you have multiple interfaces on your system, you might want to specify which one Synergy should listen to.  It’s too bad the loopback interface on Windows isn’t easily identified, since for these purposes you’re doing everything through the localhost anyway.
3. For “AutoStart…”, I usually choose “When Computer Starts”.  I figure someone should have to log in before being able to control another workstation.  This also seems to have the side benefit that if you lock your workstation, the keyboard and mouse can’t control the clients until your workstation is unlocked.
4. Finally, the “Configure … ” button.  You’re going to list all of the screens (both the server and all clients) in the “Screens:” section, using the “+” button to add new ones.  This is where the “–name” option for the clients (and the “Screen Name” you set above) become important.  Once you have them listed, then you need to arrange them in the “Links” section.  I’ve seen screenshots of the 1.4.x beta – it has an easier way to set up the screen arrangements. In 1.3.x, for sanity’s sake, leave the “0 to 100%” sections alone.  Only worry about what side of what screen goes to what other screen – and cover both sides.  In other words, if you set the “left of server goes to client”, be sure to do a “right of client goes to server” or there’s no telling what will happen.

Synergy On The Client: SSH Tunnels and synergyc

On the client, which for my cases and these instructions are Ubuntu Linux boxes:

1. Set up your SSH tunnel.  You should review all of the command line options, but i use:

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

   optionally you can include a “-l user” argument to tell the command what account on the server you’re logging in to, if the user name is different from the user name of the account on the client.  The command interpreted into plain English: Hey, use ssh via IPv4, forking it; don’t execute any commands, just start listening on the local machine at port 24800 (the Synergy port), and send it to the same port on the remote host.  Yes the command needs to know the remote host address twice (I guess theoretically you could set the tunnel up between two systems with a third in the middle, but that sounds ugly and scary).

2. Fire up Synergy:

   synergyc --name clientname 127.0.0.1

That’s pretty much it.  If the server’s configured right, you should be able to move your mouse onto your Linux box.

The other thing you’ll probably want to do (that can be a minor security risk) is set up key authentication so that you don’t have to enter passwords.  Here’s what you need to do:

1. For the user on the client that will be setting up the SSH tunnel, create a public/private key pair:

   ssh-keygen -t dsa

   without using a key password. This, by default, should create an .ssh directory with at least two files in it: an “id_dsa” (the private key, which you should protect at all costs) and “id_dsa.pub” (the public key, which you should also try to protect at all costs).

2. Next, copy the contents of the “id_dsa.pub” file over to the server, into a file named “authorized_keys” in the .ssh directory for the “target” account on the server (which on a Windows/Cygwin installation will be by default in C:\cygwin\home\username\.ssh – best edited via Cygwin terminal/shell using one of the available editor programs there).
3. Test that puppy – just do a straight ssh from the client to the server (using “-l username” if you need to) and verify that no password is needed.

Now, using the “localhost” options provide you with some neat opportunities, really.  I wrote a little perl script (which eventually I’ll be including here once I polish it up and make it more portable) that checks the IP address of the wireless card, and fires up an SSH session to the proper system based on that (assuming your home IP range and your work IP range are different).  Put it in the end of /etc/rc.local (with

su -c "command" user

to run it as my regular user, in case I need to kill it for some reason) to have it run on start up.  This means that with no change to my synergyc command line (which I will explain the easiest automation of in a second), I can have my laptop just figure out where it is and connect to the right server – even if I’ve hibernated it between work and home.  In addition to cleaning it up and making it more durable, I’m also thinking of figuring out how to set up an /etc/rc5.d/ start up script (as getting it to run in Ubuntu’s supported upstart method is failing me) that I can run as either root or myself to stop/start/restart/just kill the tunnel and restart it.  But enough of my ToDo on this.

The best way to do the synergyc automation?  On Ubuntu, anyway, you edit /etc/lightdm/lightdm.conf and at the end of the “[SeatDefaults]” section:

greeter-setup-script=/usr/bin/synergyc --name clientname 127.0.0.1

That’s it.  It will die off on logout of a session, but restart once the login screen comes up.

And finally, some props now to the Synergy programmers – if you have an arrangement like: “Client2” – “Client1” – “Server”, and “Client1” doesn’t connect (because it’s off or your tunnel or Synergy broke on it), it will smartly take the arrangement “Client2” – “Server”.