TigerVNC viewer: no matching security types

Question

I'm trying to remote control the desktop of a Raspberry Pi (Raspbian Jessie) from a Samsung Chromebook (ARM Arch Linux).

The VNC server running on the Pi is RealVNC.

The VNC viewer on the Chromebook is TigerVNC

I'm getting the following error when I try to connect to the server:

$ vncviewer

TigerVNC Viewer 32-bit v1.7.1
Built on: 2017-01-23 06:48
Copyright (C) 1999-2016 TigerVNC Team and many others (see README.txt)
See http://www.tigervnc.org for information on TigerVNC.

Sat Apr  1 17:25:49 2017
 DecodeManager: Detected 4 CPU core(s)
 DecodeManager: Creating 4 decoder thread(s)
 CConn:       conectado a puerto 192.168.1.200 de origen 5900
 CConnection: Server supports RFB protocol version 5.0
 CConnection: Using RFB protocol version 3.8
 CConnection: No matching security types
 CConn:       No matching security types

As far as I understood by reading the man pages, vncviewer attempts by default every supported scheme:

   -SecurityTypes sec-types
          Specify  which security schemes to attempt to use when authenti‐
          cating with the server.  Valid values are a comma separated list
          of  None,  VncAuth,  Plain, TLSNone, TLSVnc, TLSPlain, X509None,
          X509Vnc and X509Plain. Default is  to  attempt  every  supported
          scheme.

Does RealVNC use some encryption scheme that is not supported by TigerVNC?

Solution 1

Using RealVNC

As user rodrunner suggested in the comments, one way to get the VNC connection going is by using RealVNC's vncviewer.

Make sure to uninstall TigerVNC or any other VNC implementations before proceeding.

The package of RealVNC viewer is currently in AUR, you can install it via aura:

sudo aura -A realvnc-vnc-viewer

Assuming your Raspberry Pi's host name is the default, connect to it with

vncviewer raspberrypi

You'll be prompted for your Raspberry Pi's login credentials:

Press OK and you should be connected:

Caveat

On their company blog, RealVNC published an article on May 28th, 2019 titled "The Dangers of Open Source VNC-based Software". The article claims that proprietary software is superior to open source software in terms of security, support, regulatory compliance, and user-friendliness.

In combination with TigerVNC's incompatibilities with other VNC implementations, it seems to be an attempt at vendor-lock in, making me steer clear of TigerVNC.

The blog article used to be at https://discover.realvnc.com/blog/the-dangers-of-open-source-vnc-based-software, was since taken down, but a version from September 3rd, 2020 can still be accessed via this Wayback Machine entry.

Here's the full blog article:

The Dangers of Open Source VNC-based Software

Author: Eden Jefford | 28 May 2019

Everybody loves a freebie, from a sample of chocolate at the mall to a promotional stress ball, but is it always a good idea? When it comes to sweets and sundries, we’re not going to stop you unless you’re taking them from a stranger in a van, but for software, there might be more risks than you think.

While the “stranger in the van of candy” scenario presents fairly obvious risks, using an open source program with no price tag can seem on paper much less dangerous. It does the job you need it for, doesn’t break your budget, and it has glowing reviews from people who greatly appreciate its most attractive feature: not costing any money – what could go wrong? We’ve put together a list of a few good reasons why open source VNC-based software can be a wolf in sheep’s clothing. Publicity of exploits

Open source at its core means that all the code behind the program is visible for anyone on the internet. This can work out great when bugs arise – lots of passionate eyes on the code means potential issues could be spotted quicker, and therefore patched quicker – but it can also pose a very real security risk for those using the program. While most users in the community will be purely focused on improving the software, some will be examining the code for ways to exploit and hack into any vulnerabilities.

Especially with remote access software, a well-placed hack can be devastating, and expose whole networks to the hacker without them needing to be anywhere near your computers in person. However, with closed source (also known as proprietary) software, the source code is not published outside of the organization with the rights to it.

This makes it far less vulnerable than open source, as not just anyone can scrutinize the code, therefore making it much more difficult to crack into. Think of it like trying to complete a 10,000-piece jigsaw in the dark – it’s still technically possible to do, but it’ll be a lot easier if the light is on!

Lack of support

While a community with a broad range of skills and expertise can be great for finding solutions to problems you’re encountering, it can also have its downsides. Every user on a support forum for open source software is a volunteer. They have no obligation to respond to queries, or to even check for new questions in the first place.

This means that you’re fully reliant on the goodwill of the internet to provide support, and when using the software is critical for your business, that can mean not only lost time, but lost revenue too.

With proprietary software, you can pick up the phone, send an email, or use a live chat knowing that a dedicated and highly trained person will get back to you as soon as possible, and do everything they can to help: in fact, helping you solve a problem is literally their job. Additionally, customer service agents are made accountable for the advice they provide – on a forum, an anonymous username can very easily give deliberately wrong or harmful ‘advice’ with no consequences.

Indemnity

Data breaches are unfortunately an ever present risk, and there seems to be a new one in the news every other day. Especially with recent data protection laws, such as the GDPR for those doing business in Europe, the repercussions for such leaks can also be catastrophic.

As open source software isn’t owned by anyone, and is offered under a General Public License (GPL), there isn’t a company to guarantee for its security (or lack thereof). If a data breach happens through that software, it’s all on the user, aka you or your business. You would be responsible for any legal or financial impact the leak causes, the fallout of which could be considerable depending on the size of the breach and the sensitivity of the data exposed.

Even if your company has professional indemnity insurance, if you are using software that is not secure and compliant with data protection regulations in your industry, your insurance can be rendered invalid due to willful negligence. Not to mention the reputational damage.

Compliance with industry governance

Compliance is a great concern for many industries, with many having very specific requirements in order to meet the necessary standard, be it HIPAA, PCI-DSS, GDPR, or any other regulatory laws. With records now being almost entirely digital, it is more important than ever for software to comply with industry governance, and not all software is going to fit the bill.

Open source software can be added to by anyone, with no thorough testing or vetting, and is not compliant with regulations by default. This not only negates the savings of using free software by requiring custom code (skillful coders aren’t cheap!) but can also leave you vulnerable through a lack of updates.

For instance, open source VNC-based software runs on the last publicly available release of the RFB (Remote Frame Buffer) protocol – v3.8, which came out in 2010: to put it into perspective, the current version of RFB is v6, and was released in early 2019.

Technology has moved at lightning speed over the last decade, and regular updates are vital to keeping software secure. Using a highly outdated version of any software can be dangerous when it comes to security, and fines for non-compliance with standards can be considerable. Can you afford to take that risk when you really don’t need to?

Low level of security

Brute force password attacks are still the easiest way hackers can gain access to your accounts and data, as many people use simple passwords that are very quick for an automated program to crack, especially with so many cracked passwords circulating on the internet.

Using longer and more complex passwords along with Multi-Factor Authentication (2FA/MFA) are the best ways to combat this vulnerability, but with open source VNC-based software, passwords have a hard limit of 8 characters, and there is no native 2FA/MFA. Open source VNC-based software does not encrypt any session data, but on proprietary software all sessions are now 128/256-bit AES encrypted. This is again due to the outdated version of the RFB protocol mentioned earlier, and is probably the most dangerous part of open source VNC-based software on this list.

Using proprietary remote access software, security tools are built in and updated regularly, as security is the biggest concern within the remote access industry. High levels of encryption, complex password capabilities, 2FA/MFA, and rich session permissions are now built in as standard with many paid remote access services, giving you and your company peace of mind you just can’t get with open source.

Not user friendly

Open source projects are primarily built and updated with only developers in mind, so the usability for people less technologically savvy can suffer considerably. From clunky and confusing user interfaces, to complicated installation and setup, they just aren’t designed to be used by the layman.

This can result not only in a poor experience for the user, but also in additional vulnerabilities. With a baffling UI, an inexperienced user could easily end up giving access to unauthorized people, getting stuck in strange glitches, and opening a portal to the underworld, all in a single session.

Open your eyes, not your source!

Consider the total cost of ownership (TCO) rather than the upfront cost – while free is appealing, it could easily end up costing much more than a paid service in the long run. Your business is worth the investment, and the freeware is not worth the possible risks.

Written by Eden Jefford

Solution 2

Assuming RealVNC is not supported on the platform you are using (which is my case with arm64 Arch) I found the following solution.

1. As root, edit the config file in /root/.vnc/config.d/vncserver-x11
2. Insert the following at the bottom of the file

Authentication=VncAuth
Encryption=AlwaysOff
Password=e0fd0472492935da

3. Restart RealVNC sudo systemctl restart vncserver-virtuald.service (or just reboot)
4. Change the password (which is apparently foobar but never leave a password to something that has been posted.) with

sudo vncpasswd -service

You can now use another VNC client to access you RealVNC server. You will get a warning that the connection is not secure, that is the cost of access as far as I can tell; but, inside my LAN it is probably OK.

Comments

[Admin]

(Almost?) everything about VNC encryption and authentication is proprietary. Interoperability is very limited. I suggest you just use TigerVNC everywhere.

[Admin]

The latest Rasbpian distro (with pixel) has RealVNC by default and I would like to keep it. I've installed RealVNC viewer from AUR in my chromebook

[Admin]

duplicate of unix.stackexchange.com/questions/77885/…?

[Admin]

@rodrunner did you find any solution yet? I'm facing the same issue.

[Admin]

@LoïcFaure-Lacroix I installed RealVNC viewer from AUR in ARM arch linux

[Admin]

You can also use SSH with X forwarding to use GUI applications remotely. This way, you have no client/server incompatibilities.

[Admin]

Looks like the issue is because RealVNC authentication is proprietary: github.com/TigerVNC/tigervnc/issues/1286 (seriously, I don't know which side is right, but the fact that nobody have implemented it and RealVNC wrote that blog post...) ■ See also github.com/TigerVNC/tigervnc/issues/51 for Mac.