Home Home
Sign up | Login

Author Archive

Using openSUSE as a reverse tunnel site for Windows 7 or 8.1 remote desktop

April 20th, 2015 by

If you can’t open a hole in your office / home firewall then a reverse tunnel can let you workaround the issue.  This blog post uses cygwin, ssh and autossh to create and maintain a reverse tunnel through your firewall.

You should be aware that if you follow the below steps you will punch a hole through your firewall, so be sure and consider the security issues associated with that hole.  Many organizations require security beyond a simple login and password when connectivity is allowed from outside the firewall.  In some organizations following the below instructions without authorization from your IT security team could be a firing offense.

In theory this functionality is relatively basic, but there are lots of resources on the web that only serve to complicate the matter.  The below instructions were followed in 2015 with current SSH to create an actual working reverse tunnel.

The assumed situation is you have:

– Windows 7 or 8.1 PC behind a firewall you want to remote desktop to (the target PC)
– A openSUSE server in the cloud that you are able to ssh into and open appropriate ports and firewall holes
– A client PC from which you want to originate Remote Desktop sessions

The instructions here borrow heavily from the below blog post, but I was unable to get the tunnels to work by following the steps described at that site:

Creating persistent SSH tunnels in Windows using autossh

What has worked for me so far is:

  1. On the openSUSE server
    1. Ensure you have a user account “autossh” (or whatever you want to call it).  This will be used exclusively for reverse tunnels.
    2. Ensure you have a normal user account you can use with scp with to copy files from the target PC to the openSUSE server.
  2. On the target (destination) PC:
    1. Ensure you have remote desktop setup.  Machines on the local LAN should be able to remote desktop into the PC prior to starting this procedure.
    2. Download Cygwin (http://www.cygwin.com/)
    3. Install Cygwin, selecting the autossh and openssh packages.
    4. Start the Cygwin shell (Start -> Programs -> Cygwin).
    5. Generate a public/private key pair.
      1. At the command line, run: ssh-keygen
      2. Accept the default file locations
      3. Use an empty passphrase
    6. Copy your newly-created public key to the SSH server.
      1. scp .ssh/id_rsa.pub user_account@ssh.host.name:id_rsa.pub
  3. Add your public key to your list of authorized keys on the server.
    1. Login to your SSH server as your normal user_account
    2.  mv id_rsa.pub  /tmp
    3. su –  # become root
    4. Ensure /home/autossh/.ssh exists
      1. # ls -ld /home/autossh/.ssh
        drwxr-xr-x 2 autossh users 4096 Apr 24 2015 /home/autossh/.ssh
      2. If not: mkdir /home/autossh/.ssh; chown autossh.users /home/autossh/.ssh; chmod 755 /home/autossh/.ssh
    5. cat /tmp/id_rsa.pub >>  /home/autossh/.ssh/authorized_keys
  4. Tweak the sshd_config on the server
    1. By default openSUSE enables “AllowTcpForwarding” and “TCPKeepAlive”. Verify they are either commented out or set to “yes” in /etc/ssh/sshd_config
    2. Set “GatewayPorts yes” and “ClientAliveInterval 300” in /etc/ssh/sshd_config.  Also make sure they are not commented out.
    3. restart sshd to get the config values to be re-read:    sudo systemctl restart sshd.service
  5. Test your SSH key.
    1. Logout of your SSH sever.
    2. Login to your SSH server again, but as autossh this time. This time, your key will be used for authentication and you won’t be challenged for your login credentials. If you are not logged in automatically, review the previous steps. Or contact your server administrator.
      1. ssh autossh@@ssh.host.name
    3. Logout of your SSH server.
    4. Exit of the Cygwin shell.
  6. Test your SSH Tunnel capability
    1. Open a cmd prompt on your target PC as administrator
      1. start -> run -> cmd -> right click on “cmd” -> left click “run as administrator”
    2. C:\cygwin\bin\ssh -N -R 4489:localhost:3389 autossh@ssh.host.name
      1. Note that this should open an alternate port (4489) or your openSUSE server in the cloud.  openSUSE uses 3389 by default, so you need to use an alternate port on the openSUSE server end.
      2. Any connections to the alternate port should be funneled through the SSH tunnel back to the windows 7 PC on port 3389
    3. From a 3rd computer open a remote desktop connection to ssh.host.name:4489
      1. Note that remote desktop uses :4489 after the server name to designate an alternate port.
      2. If it acts like you’re not connecting at all, in all likelihood you’re not.  You probably have a firewall in place on the openSUSE server.
        1. Open port 4489 in your opensuse server firewall
          1. https://doc.opensuse.org/documentation/html/openSUSE_122/opensuse-security/cha.security.firewall.html#sec.security.firewall.SuSE.yast
          2. Or   “sudo /sbin/yast -> security and Users -> Firewall -> Allowed Services -> Advanced -> add 4489 to list of TCP Ports -> OK -> next -> finish -> quit
      3. retry remote desktop connection
    4. Once it works, from the Windows 7 command prompt kill the the ssh connection to your openSUSE server (contrl-C)
  7. Test your AutoSSH Tunnel capability
    1. From the CMD prompt running as administrator
      1. C:\cygwin\bin\autossh -M 20000 -N -R 4489:localhost:3389 autossh@ssh.host.name
        1. Note that-M opens a monitoring port (I’m not sure how to leverage that)  The monitoring port is opened on the server (ssh.host.name) so if you have multiple autossh commands pointed at the same server, each should use a unique monitoring port as well as a unique tunnel port (4489 in the above.)
    2. From a 3rd computer open a remote desktop connection to ssh.host.name:4489
      1. Make sure you terminate your remote desktop session from the 3rd computer when done testing
    3. If it worked, from the Windows 7 command prompt kill the autossh command (contrl-C)
    4. exit out of your cmd window
  • At this point you can manually invoke autossh to setup a semi-persistent tunnel

Setup the autossh feature as a Windows service

Note:

  • the below uses cygrunsrv to install the Windows service.  If you experience problems cygrunsrv -L, cyrunsrv -LV, and cygrunsrv -R <service>    may all be useful for diagnosing the problem.  The first 2 commands list the installed services, and -R removes installed services.
  • Logs for cygrunsrv default to C:\cygwin\var\log\AutoSSH.log
  1. Install autossh as a Windows service
    1. Open a cmd prompt on your target PC as administrator
      1. start -> run -> cmd -> right click on “cmd” -> left click “run as administrator”
    2. cd C:\cygwin\bin
    3. cygrunsrv -I AutoSSH -p /bin/autossh -a “-M 20000 -N -R 4489:localhost:3389 autossh@ssh.host.name” -e AUTOSSH_NTSERVICE=yes
      1. If you get an error with this command, manually type the ” marks.  They may not be handled properly with cut&paste.
      2. Be very careful with the above.  A misbehaving service can be hard to remove in Windows.  It may require safe mode if the service won’t accept stop commands.
    4. Tweak Windows service settings.
      1. Open the Services management console (Administrative Tools -> Services).
      2. Edit the properties of the AutoSSH service.
      3. In the “Log On” tab, select the “This account” radio button and set the service to run as your current user.  This is very important to do before starting the service in order for the ssh certificate to be used.
      4. Change the startup mode to “Automatic (Delayed Start)”
      5. Start the service.
  2. Test your tunnel as described in 6.2 above
    1. Be sure to test after rebooting your target Windows 7 or 8.1 PC.
    2. I have had it working for 6months and used it a lot.  I’ve seen network drops.  Target PC reboots.   openSUSE server reboots.  The tunnel just keeps working.

If all went well, congratulations you now have a persistent tunnel

You should be aware you have just punched a hole through your firewall, so be sure and consider the security issues associated with that hole.  Many organizations require security beyond a simple login and password when connectivity is provided from outside the firewall.