Security of SSH vs. RDP

I have the pleasure of teaching introductory Linux Administration at a local college.  During class, students raised the question of relative security between SSH and RDP, as protocols for remote server management.  I responded based on my general understanding of the protocols (I’ve always considered SSH to be generally more secure), but I felt this was worth further investigation.  This is a quick summary of my findings.

Microsoft RDP

RDP has come a long way since its early days, when it was trivial to compromise via network traffic sniffing / man in the middle attacks.  As of RDP 6.0, Microsoft introduced additional security features around data encryption and mutual authentication that significantly improve the security of RDP.  When an administrator enables the highest level of security (FIPS-compliant) on the remote desktop host, very secure encryption algorithms are used.  These features are configurable on the server, so it is still possible to create a less-than-secure RDP scenario.

Configuration recommendations for increased security:

  • Force NLA, which uses CredSSP to secure the authentication process
  • Set the encryption level to 4 (FIPS compliant), which uses 3DES and SHA-1 for bidirectional traffic encryption
  • Alternatively use encryption level 3, traffic is encrypted with 128-bit RC4 and MD5/SHA-1, which should be sufficient for most environments.

One big caveat – this was written specifically within the context of remote server administration.  Further recommendations are appropriate for a complete remote desktop / remote application solution built on Microsoft RDP, for example deploying a Remote Desktop Gateway with certificates issued by a trusted third party.

For reference:


Secure Shell (SSH) was created as an encrypted network protocol, with security as a first priority.  It is highly secure.  Authentication is based on public key cryptography, and data is encrypted using one of many well-established secure algorithms.  The DigitalOcean article below provides an excellent, clear and easy to read description.

Configuration recommendations:

  • Use key based authentication and disable password-based authentication
  • Many secure encryption ciphers are supported. Be aware of which algorithms are enabled on your servers.

For reference:


Windows and SSH

As an additional point of interest, Microsoft has announced plans to introduce SSH support via the PowerShell team.

We actually published an updated roadmap for the OpenSSH port here:…/10648817.aspx

Per that roadmap, we still hope to deliver a production-quality Windows port of OpenSSH within the first half of 2016.

See for more details.

My goal here was to compare the methods used to secure RDP vs. SSH.

Certainly the usage of Microsoft RDP and SSH have some important differences.  There are several interesting discussions about why comparing RDP, SSH, and other remote management technologies is a matter of apples to oranges.  These are my two favorite write-ups that discuss this topic in depth:



Some Quotes on Encryption (Off Topic)

Warning to my typical audience, this is going way off topic.  Skip this one if you are just here for the technical stuff.

Given the current discussions around government surveillance, technological encryption measures and their legal standing, I wanted to collect a few meaningful quotes on the topic of encryption.

There’s a lot of fascinating discussion on this subject but there is also a lot of nonsense from various camps.  I’ve attempted to keep the quotes and links below to logical and practical topics and avoid alarmist comments in any direction.

In my own words, I feel strongly on a couple keys points.  It is not possible to enforce with technology a process that allows only authorized government agencies to access data at authorized times, with effective governance when approved through some process that we all agree to as part of our system of law. Once encryption is weakened in this manner, it will inevitably be exploited by a bad actor.

You also can’t prevent bad people from using strong encryption, any more than you can outlaw mathematics or programming.

So, we have a fascinating challenge to address – what processes do we use to protect ourselves from those who seek to harm us?  However, the answer is definitely not crippling encryption or creating government back doors.

I think this quote from huffpo sums up the core issue nicely:

It is simply not possible to give the good guys the access they want without letting the bad guys in. There’s nothing new or novel in this statement. Experts have been saying the same thing for 20 years. While the message is old, with the integration of Internet technologies into nearly all aspects of life, the stakes are higher than they’ve ever been.


A great nugget from Schneier, but you really have to read the complete blog entry:

Today, we are seeing government pushback against encryption. Many countries, from States like China and Russia to more democratic governments like the United States and the United Kingdom, are either talking about or implementing policies that limit strong encryption. This is dangerous, because it’s technically impossible, and the attempt will cause incredible damage to the security of the Internet.

Interestingly, some tech companies are speaking up:

After Apple’s chief executive Tim Cook’s claims that “any backdoor is a backdoor for everyone”, the Information Technology Industry Council, which represents 62 of the largest technology companies worldwide, said: “Encryption is a security tool we rely on everyday to stop criminals from draining our bank accounts, to shield our cars and airplanes from being taken over by malicious hacks, and to otherwise preserve our security and safety.”

Another comment from the Guardian, on the technical infeasibility of weakening encryption:

The strength of the encryption derives from the underlying mathematics. It’s not something governments can wish away or make illegal any more than parliament can repeal the law of gravity.

Key escrow solutions don’t work either:

Whitfield Diffie, co-inventor of public-key cryptography, highlighted a different reason why he thinks such a system is not practical—“not to disparage the other ways in which it’s not going to work,” he said to the audience’s amusement.

With the current state of technology it’s much easier to pre-encrypt what is sent into the encrypted channel than it was when the same problem was raised 20 years ago, Diffie said. In such a case, the government is going to exercise a warrant and break the outer encryption layer that is accessible to them and then find out that you’ve encrypted it in some other way, he said.

“In that case they’ll do what they might have had to do anyway: come down on you with a bench warrant or something and order you to tell them how to read it,” Diffie said.


Finally, I’d just like to add that encryption does not mean total privacy.  Encryption is one technical measure that can be used for good or harmful purposes, but simply using encryption does not preclude the ability for a determined actor (lawful government agent or otherwise) to compromise encrypted communications, for example by attacking the endpoint.

For further reading, I highly recommend Bruce Schneier’s blog on security, as one of the leading experts on computer security he never fails to deliver thought-provoking comments on technology and security for the world we live in today.


VMware View, Google Earth, and Group Policy

While deploying the VMware Horizon suite for one of my customers, they expressed a requirement for Google Earth.  The specific business consumer use case does not demand high performance, and the environment has a hardware constraint of “no hardware GPUs” (for now).  Therefore we deployed software 3D rendering for the virtual desktops.

To ensure optimal performance given these constraints, we implemented the following tweaks outlined on this blog post:

For this customer, Microsoft Group Policy is the primary method for user environment management.  I created a classic ADM template from the registry settings listed in the above article, and am happy to share the contents with you here.  Download link at the end of the article.  You can see the result of importing this .adm template into a GPO in this screenshot:

Each setting handles a particular set of registry values.  I hope this can be a useful template for others if you need to make similar tweaks.  Importantly, this is a simple re-usable approach that can be quickly deployed to any environment using Google Earth in a remote desktop scenario.

Download here: Google_Earth_VDI_Tweaks

Full content of .adm file: