TurboVNC won't connect to new Apple Mac Mini

[jgwinner]

I THOUGHT it worked before ...

so when I connect via TurboVNC, it pops up a window, and doesn't allow me to select a user name. If I put in the password for the ONLY user on the system (as far as I know, it's a brand new Mac Mini), TurboVNC says "Authentication or authorization failure"

Connected to Bobs-Mac-mini port 5900
RFB server supports protocol version 3.889
Connected to RFB server, using protocol version 3.8
Authentication scheme: (null)
Empty password
Connected to Johns-Mac-mini port 5900
RFB server supports protocol version 3.889
Connected to RFB server, using protocol version 3.8
Authentication scheme: (null)
RFB connection failed, reason: Authentication or authorization failure
Authentication or authorization failure
Connected to Johns-Mac-mini port 5900
RFB server supports protocol version 3.889
Connected to RFB server, using protocol version 3.8
Authentication scheme: (null)
RFB connection failed, reason: Authentication or authorization failure
Authentication or authorization failure

So I went through 'options' and tried "Clear the list of saved connections" but got nearly the same results. Again the user name is grayed out, I put in the correct password, and the /loglevel 8 gives me this result:

[C:\Program Files\TurboVNC]cvncviewer.exe /loglevel 8
Started and Winsock (v 2) initialised
WinTab library not available
Buffer size expanded to 4352
Registered connection with app
Connected to Bobs-Mac-mini port 5900
RFB server supports protocol version 3.889
Connected to RFB server, using protocol version 3.8
Choosing security type VncAuth(2)
Authentication scheme: (null)
RFB connection failed, reason: Authentication or authorization failure
Authentication or authorization failure
AUTHENTICATION FAILURE: Authentication or authorization failure
Buffer size expanded to 4352
Registered connection with app
Deregistered connection from app
Deregistered connection from app
Exiting
VNC viewer closing down

It always grays out the User name

Any ideas? RealVNC is a bit sluggish but I haven't purchased their server either.

[jgwinner]

Ok, turns out it's an encryption issue. I noticed with RealVNC if I turned off encryption, I would get the same "user name less" prompt, and again it would not connect.

So it looks like maybe VNC encryption is missing? Ah, looks like this is issue: https://github.com/TurboVNC/turbovnc/issues/8 and https://github.com/TurboVNC/turbovnc/issues/107

I'll close this ticket. Maybe it'll help someone else!

Note that the log files don't mention "No suitable Authentication Scheme Found" or that would have been more obvious.

Also, issue 8 has some great info on the Java vs. native version; I chose the native version as that'll be faster, plus, Java is now no longer free.

    == John ==

[dcommander]

You are incorrect regarding the Java viewer. In fact, on Windows clients, the Java viewer is faster than the native viewer, and for that reason and many others, the native viewer is going away in TurboVNC 3.0. Also, OpenJDK is released under the GPL v2 with a classpath exception, and Java versions later than 8 are based on OpenJDK. The TurboVNC 3.0 Viewer embeds a GPL-licensed stripped-down JRE based on OpenJDK 11, in fact. You can try it out in the 3.0 evolving pre-release build (no separate JRE required.)

In order to use user/password authentication with the Windows native TurboVNC Viewer, the VNC server must support the TightVNC security descriptor. In order to use user/password authentication with the Java TurboVNC Viewer, the VNC server must support the TightVNC security descriptor or VeNCrypt. Few VNC servers support the TightVNC security descriptor (it is mainly a legacy feature that we inherited from the TightVNC Server when we forked from it in 2004.) VeNCrypt, to the best of my understanding, is only supported by a few open source VNC servers-- mainly TurboVNC, TigerVNC, and LibVNCServer. It's unclear whose VNC server you are using on your Mac, but if it's Apple's VNC server or RealVNC's, then it's not surprising that the VNC server doesn't support VeNCrypt or the TightVNC security descriptor. Also, the order in which the VNC server advertises security types to the viewer matters. If the server advertises VncAuth (VNC password authentication) first, then the viewer will automatically use that security type unless you override it. You can override that decision either by limiting the available security types that the viewer will use (by passing -securitytypes to the viewer or modifying the check boxes in the Security tab of the TurboVNC Viewer Options dialog) or by specifying a user name (by passing -user to the viewer.)

Note also that VNC password authentication uses a dedicated password for the VNC session, which you can set in the VNC server's configuration. (If you're using Apple's VNC server, this is under "System Settings-->Sharing-->Screen Sharing-->Computer Settings-->VNC viewers may control screen with password".) It does not ever use the password for any of the user accounts on the host.

In my testing with Apple's VNC server, I can't authenticate at all with the TurboVNC Viewer unless I set the aforementioned VNC password. That tells me that Apple's VNC server doesn't support VeNCrypt or any of the other user/password authentication methods we support. If their server supports user/password authentication at all, it is apparently using an authentication method that is incompatible with ours.

[jgwinner]

The most important point has been lost, it's not clear that there is an encryption issue. The error mentioned in issues #8 and

107 don't appear in the new log file.

I get it, you don't want to focus on the native version any more, but want to focus on one code base, and it's a lot better. Makes sense.

I DO think it should be more clear that there is an encryption issue to the user, instead of having to dig through log files for missing statements, even with the .exe version.

But, it's up to you of course.

It's unclear whose VNC server you are using on your Mac, but if it's Apple's VNC server or RealVNC's, then it's not surprising that the VNC server doesn't support VeNCrypt or the TightVNC security descriptor.

It's a completely brand new Mac Mini, no software installed other than what it came with, so Apple's VNC server.

Sorry if "Brand New" wasn't clear. Not sure how to find out what "version" it is. VNC is supposedly built in, and did seem to be.

Also, OpenJDK is released under the GPL v2 with a classpath exception, and Java versions later than 8 are based on OpenJDK.

Look, I've seen what happened to MySQL. It was "Free" and "Open Source" until Oracle decided to make people start paying for it. I heard Larry say on stage from two dozen feet away "I'm going to find a way to make money on this".

I don't really care if there is a link from 1991 that says the OpenJDK is free, Oracle could change this - and has shown they have in the past. (which is why I use MariaDB at work, even if we pay). It may already be changed, it's not terribly clear to me. Oracle tends to work through lawyers; I had a lot of our Oracle clients squawk when suddenly that DR server that they thought was "development" was defined by Oracle to mean a seven digit licensing bill.

Wikipedia says:

Oracle released the last zero-cost public update for the legacy version Java 8 LTS in January 2019 for commercial use, although it will otherwise still support Java 8 with public updates for personal use indefinitely.

So, maybe the OpenJDK is free, maybe not. Probably though.

In fact, on Windows clients, the Java viewer is faster than the native viewer, and for that reason and many others, the native viewer is going away in TurboVNC 3.0

Well, for sure, bad software, or at least less maintained, always beats good JIT/compilers. In general though, would you make a bank investment at a -20% rate of return? No. https://en.wikipedia.org/wiki/Java_performance

It's fine for most stuff though and I'm sure fine for VNC.

[dcommander]

The most important point has been lost, it's not clear that there is an encryption issue. The error mentioned in issues #8 and #107 don't appear in the new log file.

It was not clear to me what encryption has to do with the issue. Does Apple’s VNC server even support encryption? Regardless, their server doesn’t appear to support VeNCrypt, which is the only way to encrypt the RFB stream with open source VNC viewers. Your statements above regarding encryption and RealVNC did not make sense to me.

I get it, you don't want to focus on the native version any more, but want to focus on one code base, and it's a lot better. Makes sense.

I DO think it should be more clear that there is an encryption issue to the user, instead of having to dig through log files for missing statements, even with the .exe version.

Again, what encryption issue? Is it a bug that the native viewer doesn’t support encryption? The User’s Guide never claims that it does and actually does state that only the Java viewer supports VeNCrypt. Unifying the TurboVNC Viewer and thus jettisoning the native Windows-only viewer is partly to eliminate this confusion, in fact. Adding encryption support to the native viewer would be a difficult prospect. It would take hundreds of hours, and since no one is paying me for that work, I had to make an intelligent business decision not to do that work for free. (I’m also not getting paid to answer GitHub issues like these, incidentally.) Nothing would prevent you or anyone else from forking the native TurboVNC Viewer and adding features to it, if you prefer that code base. I will continue to support the native viewer on a break/fix basis, but given that it is written using raw “Petzold” Win32 GUI code, extending it is a royal PITA. It has become a business liability, since adding features to both TurboVNC viewers adds a disproportionate amount of cost that many of my funded development customers are unwilling to pay.

But, it's up to you of course.

I bend over backwards for my users, and historically, I’ve invested hundreds of thousands of dollars’ worth of pro bono labor into making TurboVNC as performant and easy to use as possible, but I’m only one person competing with large corporations such as RealVNC. I certainly want the TurboVNC Viewer to work with the macOS VNC server, but I can only control my own VNC server. There are limits to what I can do without going broke, and since no one is paying me to support Mac or Windows VNC servers, those don’t get a lot of my attention. Sorry not sorry.

If you can give me something concrete to work with, such as specific steps to reproduce a problem or even information necessary to understand the problem, then I’m happy to work with it.

It's unclear whose VNC server you are using on your Mac, but if it's Apple's VNC server or RealVNC's, then it's not surprising that the VNC server doesn't support VeNCrypt or the TightVNC security descriptor.

It's a completely brand new Mac Mini, no software installed other than what it came with, so Apple's VNC server.

Sorry if "Brand New" wasn't clear. Not sure how to find out what "version" it is. VNC is supposedly built in, and did seem to be.

It wasn’t clear that you were using Apple’s VNC server, because you mentioned RealVNC. Please be professional, thanks. I am not your personal punching bag.

Look, I've seen what happened to MySQL. It was "Free" and "Open Source" until Oracle decided to make people start paying for it. I heard Larry say on stage from two dozen feet away "I'm going to find a way to make money on this".

I don't really care if there is a link from 1991 that says the OpenJDK is free, Oracle could change this - and has shown they have in the past. (which is why I use MariaDB at work, even if we pay). It may already be changed, it's not terribly clear to me. Oracle tends to work through lawyers; I had a lot of our Oracle clients squawk when suddenly that DR server that they thought was "development" was defined by Oracle to mean a seven digit licensing bill.

Wikipedia says:

Oracle released the last zero-cost public update for the legacy version Java 8 LTS in January 2019 for commercial use, although it will otherwise still support Java 8 with public updates for personal use indefinitely.

So, maybe the OpenJDK is free, maybe not. Probably though.

OpenJDK is literally released under the same OSS license as TurboVNC, and it has shipped with Linux for many years. With Java 9, Oracle started sourcing OpenJDK for their own Java release, so OpenJDK is the official source base now, as opposed to having separate source bases for Oracle and OpenJDK releases in Java 8 and prior. Anyway, it’s irrelevant, because TurboVNC 3.0 isn’t using the Oracle JDK. It’s using OpenJDK (specifically supplied by AdoptOpenJDK.) Will Java continue to use the GPL for the next 100 years? I don’t know, but why do I care? I am an engineer. I get paid to solve problems as effectively as I can using technology available today. Right now, because of where the monetary investment has occurred in TurboVNC over the past 10 years, the Java viewer is in a much better technological position to move forward than the native viewer is. If someone wanted to pay me the tens of thousands of dollars it would take to develop a new native viewer using a maintainable cross-platform C++ GUI framework (something like GTK or Qt), then I would gladly accept that contract, but right now, I’m staring down the barrel of eating 100+ hours in labor cost just to get the 3.0 release out the door, which is in addition to hundreds of hours in pro Bono labor I’ve already devoted toward that release. If you want to make that easier on me somehow, then I’m all ears, but no one has any cause to complain about my inability to give them everything they want for no money.

In fact, on Windows clients, the Java viewer is faster than the native viewer, and for that reason and many others, the native viewer is going away in TurboVNC 3.0

Well, for sure, bad software, or at least less maintained, always beats good JIT/compilers. In general though, would you make a bank investment at a -20% rate of return? No. https://en.wikipedia.org/wiki/Java_performance

My performance claims come from the built-in benchmark feature in the TurboVNC Viewer. I ran those benchmarks literally last week. Happy to share the spreadsheet with you. If you want to dig into how those benchmarks work and make specific arguments in the context of peer review, great, but you are arguing past me using data that does not apply to this specific situation.

[jgwinner]

I think this has gotten really complicated.

From my viewpoint:

TurboVNC, the native mode version, wouldn't connect to a brand new Mac Mini with no software on it other than what Apple ships.

TurboVNC never asks for user name. As requested in the issue template, I posted the log files.

It fails with the error "RFB connection failed, reason: Authentication or authorization failure"

Another VNC product, DOES ask for user name. It connects fine.

I'll switch. Thanks for your efforts.

[dcommander]

OK, that was the clarification I needed all along. I assume that the other VNC product is RealVNC. I’m guessing that they and Apple are using some type of authentication and encryption extension other than VeNCrypt. RealVNC implements some RFB protocol extensions that are not specified openly, and if this is one of them, then the open source community would have to reverse-engineer it in order to support it. It’s a shame that Apple chose not to support open source VNC viewers properly. (Note that most of what we’re discussing here would also apply to the TigerVNC Viewer.)

Anyhow, in my testing, Apple’s VNC server doesn’t support Tight encoding, which would be necessary to achieve optimal performance with the TurboVNC Viewer (TigerVNC Viewer as well.) So there is little point to using the TurboVNC Viewer with Apple’s VNC server. Use whatever works best with it. I make the same money either way. The TurboVNC Viewer works with Apple’s VNC server, if you set a VNC password as I suggested above, but the fact that our open source viewer doesn’t work optimally with a proprietary VNC server is unsurprising and out of my control.

[jgwinner]

I assume that the other VNC product is RealVNC.

The viewer, not the server, correct.

I tried TigerVNC's VNCViewer; it had the same symptom. Interestingly, the same error message too.

I'd forgotten the idiot Mac only allowed 8 characters for the password, and missed by a letter. Once I connected again with RealVNC from a 2nd PC (validating the connection), I reset the password.

Then TurboVNC does connect! Thanks for your help.