Use SSH for Secure RDP Connections

In my article “Securing RDP” (June 2006, InstantDoc ID 50040), I showed you how to use Secure Sockets Layer (SSL) to connect to a server via Remote Desktop Protocol (RDP), the Microsoft proprietary protocol for Windows Terminal Services. This configuration provides security, but I also explained that SSL can’t guarantee that only trusted clients can connect to a server via RDP. Now, I’ll show you a way to connect even more securely by confirming the identity of both client and server. You do so by using a private/public key pair through a Secure Shell (SSH) gateway.

In the sample SSH implementation I'll walk you through, the SSH gateway is hosted on the RDP server. The RDP server is a Windows Server 2003 domain controller (DC) administered remotely. (Hosting the SSH gateway and RDP server on the same machine can potentially allow users, after they’ve been authenticated by Windows, to gain access to other services. If you want to ensure that access is granted only to RDP port 3389, you must host the SSH gateway on a separate machine and use a firewall to control access between the gateway and RDP server.)

It’s important to note that Windows 2003 doesn’t support SSH by default. To follow my instructions, you’ll need to install the OpenSSH for Windows SSH connectivity tools available at http://www.openssh.com. To tunnel an RDP connection to the server that's hosting SSH, you’ll need a specially designed RDP client called WiSSH (http://www.wissh.com). WiSSH is not free, but you can download a trial version for testing. To download the trial version, go to http://www.wissh.com/Trial (note that the URL is case-sensitive). Be sure to download the WiSSH client before following the steps in my example. Let's get started.

Set Up the SSH Gateway

After downloading the WiSSH client, you need to set up the SSH gateway. Download the latest version of OpenSSH for Windows and run the installer program on the RDP server. Accept the default settings. For the time being, you can ignore the warning given at the end of the setup routine—we’ll edit the passwd file in a moment.

If you’re using Windows 2003 Service Pack 1 (SP1), ensure that the security layer for RDP is set to RDP Security Layer because the SSH gateway will provide the end-to-end encryption and client/server authentication. To set the security layer, from the administration tools on the RDP server, open Terminal Services Configuration. On the right side of the window, under Connections, right-click RDP-Tcp, then click Properties. Set the security layer to RDP Security Layer, as Figure 1 shows. Then click Close.

Next, create a domain user account that you can use to connect to the server via RDP using the built-in Remote Desktop Connection client. In the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, create a domain user named sshuser. Next, we’ll create a password file for the OpenSSH server and add sshuser to the file.

To create a password file for the OpenSSH server, open the command prompt and change the working directory to:

c:program filesopensshbin

If you’re unfamiliar with using the command line, type these change directory (cd) commands:

cdcd program filescd opensshcd bin

To create the password, run this command:

mkpasswd -d -u sshuser >> ..etcpasswd

Now, in the MMC Active Directory Users and Computers snap-in, delete the domain user sshuser. The SSH user should be completely independent from the Windows user who will connect to the RDP server.

Next, we’ll configure the SSH server to reject simple Windows username/password connections and accept only connections from clients that provide a private key that corresponds to the server’s public key and OpenSSH username (sshuser, in our example). To use the private key, the client must also provide a password in this pre-authentication stage. After the client is authenticated via the gateway, the client must supply a Windows username and password to log on to the server.

Using Notepad, open the sshd_config file in the c:program filesopensshetc directory. Notice the odd formatting—and be sure to leave it alone. You must retain this formatting so that OpenSSH can read the sshd_config file. Before you change anything, make a backup copy of the configuration file so that you can access a clean, unaltered copy should you need to.

Next, ensure that the following values are set as shown here and uncommented (that is, remove # from the beginning of any lines, if necessary):

StrictModes noRSAAuthentication noPubkeyAuthentication yesAuthorizedKeysFile /etc/authorized_keysPasswordAuthentication noPermitEmptyPasswords no

Save the file. Then, from the command prompt, start the OpenSSH server by typing:

net start opensshd

Use WiSSH to Generate a Private/Public Key Pair

Now that OpenSSH is working, it’s time to install WiSSH and create a private/public key pair. Install WiSSH on the client machine that will connect to the RDP server via the SSH gateway. Accept the default settings. When installation is complete, go to the WiSSH program directory and open the WiSSH Private Key Generator. Figure 2 shows the details that appear in the Private Key Generator.

Enter a strong password (at least 10 characters long and mixing upper- and lowercase letters, numbers, and symbols) different from the password of the Windows account that you’ll use to log on to the RDP session. Click Generate Keys. Save the private key and the OpenSSH Style public key to the desktop (click Save Private Key and Save Public Key). Move the public key to the c:program filesopensshetc directory on the server and rename the file authorized_keys.

Configure WiSSH to Connect to the Remote Desktop Server via the SSH Gateway

From the Programs menu on the client machine, start WiSSH and click the Gateway tab, as Figure 3 shows. Under SSH Gateway Host, enter the IP address (or DNS name if resolution is working) of the server on which you installed OpenSSH. If the host can be contacted, the SSH Gateway Host box will turn green. Check the Use Private/Public Key Authentication box and browse to find the private key you saved to the desktop.

Next, click the Login tab. Under Gateway Credentials, enter the username sshuser. Enter the password you created for use with the private key. Under Remote Host, enter the same IP address or DNS name that you entered for SSH Gateway Host. In this example, the remote host and the gateway are the same server.

Click Connect and you should be able to connect to the remote desktop. If the connection is successful, you can now log on to Windows with any user account that has permission to log on via RDP, as Figure 4 shows.

Test Security

You’re almost finished, but before you expose your machine to the Internet, you’ll want to test that the SSH gateway will accept only connections that use the private/public key pair. Open the WiSSH client, click the Gateway tab, and clear the Use Private/Public Key Authentication check box. Now try to connect—you should get an error message. (Note that sometimes WiSSH needs to be restarted for the change to take effect.) Next, click the Login tab. Under Gateway Credentials, try to connect using Windows user accounts that would normally have permission to log on with RDP. Ensure that these connections are also rejected. After you’ve completed these tests, don’t forget to reconfigure WiSSH to use Private/Public key authentication and re-enter the gateway credentials on the login tab as you did earlier.

When the gateway is configured and fully tested, you can expose TCP port 22 to the Internet and be confident that only remote machines that have the corresponding private key will be able to connect to the server via SSH.

The solution I’ve shown you provides a way for you to safely publish an RDP server to the Internet. It allows machines with any IP address and that can confirm their identity to connect to the server without directly exposing access to the Windows logon interface. Consider it another tool to use to help keep your Windows systems secure.

Russell Smith ([email protected]) is an independent IT consultant. He has worked in IT for six years, specializing in security and systems management.