I just discovered something today that I should have looked for months ago. I got curious after doing a lab here in the RH253 (RHEL Network Services and Security) class about whether or not Synergy does any type of encryption over the wire. What I found out is actually NO.
To test this I loaded up wireshark and did some sniffing. Sure enough the input between the two is cleartext and this as also validated by the Synergy man page:
Synergy has no built-in support for encryption or authentication. The server accepts connections from any computer. The server and clients send all data unencrypted which means the clipboard and mouse and keyboard events (e.g. typed passwords) are easily examined by anyone listening on the network. Therefore, do not run synergy on untrusted networks.
In this case I wanted to share a solution for encrypting your synergy traffic on the LAN. This, of course, uses everyone’s favorite application, ssh. You’ll need to setup an encrypted tunnel between the machines using a command such as:
ssh -f -N -L 24800:synergy-server:24800 synergy-server
Now let me explain quickly what these flags do.
-f requests ssh go to background just before command execution. This is useful if ssh is going to ask for passwords or passphrases, but the user wants it in the background.
-N Do not execute a remote command. This is useful for just forwarding ports (protocol version 2 only)
-L [bind address]:port:hostname:hostport
24800, also, is the default port for synergy. So, if I wanted to create this tunnel between two of my machines on my LAN I would use something like:
ssh -f -N -L 24800:macbook:24800 macbook (note: macbook is defined in my /etc/hosts and will be running synergys)
Next I would then run the synergy client command which would forward over the encrypted tunnel to the server.
synergyc macbook
Also, you can run the synergys (server) as normal on the central machine.
synergys --config .synergy.conf
Now you also might want to use authorized_keys on the remote server to bypass the password authentication, but that is your preference. You can find a tip on doing that here (public key authentication).
Good idea, but the execution is *slightly* out. You’re running “synergyc macbook” at the end, but that won’t go over the ssh tunnel.
You need to do “synergyc localhost” to use the ssh tunnel.
David – in my original writeup I did use localhost but I decided I wanted to keep that open for something else. Binding the address to macbook (or any other hostname) will still work. I did test it before I posted 🙂
It won’t work as written – if macbook is defined (in /etc/hosts or elsewhere) as an alias for localhost then the ssh connection will also connect to localhost, not the remote ‘macbook’.
You’re ssh-ing and synergy-ing to the same place – either that’s localhost, or it’s the macbook. In neither case is this going to work as expected.
At the very least, if you’re doing something deeply cunning it’s not clear from the post what it is.
There is an option you could add, though for the little traffic of key press and mouse movement it is not that necessary. The option is -C for ssh which request the client to compress all traffic with the server.
So when you create your tunnel, you do:
ssh -f -N -C -L 24800:synergy-server:24800 synergy-server
And as they stated above, you would have to call: synergyc -f localhost
Unless, you have set some aliases in the synergy configuration… But I’m not sure anymore how it is… Too long I did not use it!
Furthermore, you forgot to mention that the security issue is mention on Synergy web site and that they have a dedicated page concerning tunnelling the traffic through SSH: http://synergy2.sourceforge.net/security.html
And keep in mind that really few – actually used – protocol are encrypting their sensitive data 😉 for example when you are logging-in to your blog, the password is sent clear. Once logged-in, WP hash it in a cookie, so it is only plain readable upon log-in.
using your method, the ‘synergyc macbook’ command simply bypasses the ssh tunnel, so nothing is actually being encrypted. I tested your method using Ettercap, and could see the unencrypted keystrokes being sent between the two machines.
David is correct, you need to use ‘synergyc localhost’. After using your method with ‘synergyc localhost’ instead, ettercap is now showing gibberish between the two machines, which is what we want.
I second Torin, David, and Ewan. In fact, if you want to see how it doesn’t work, you might wanna run wireshark and see where packets are going / their contents 🙂
@ Torin
This is correct – You need “synergyc localhost” NOT “synergyc macbook” if you want to use your ssh tunnel.
I don’t understand how this setting is secure. If i understand it correctly anybody who present himself with same hostname cat read output of the synergy server. He does not need any password.