Impossible to connect using VncAuth

[reallaborious]

Describe the bug VNC works fine in vncviewer with VeNCrypt/plain (for now it supports it). But I can't use tigerVNC because of many reasons, I need remmina, and it cant use VeNCrypt/plain, it needs vncauth. So during connection with vncauth both Remmina and vncviewer fail connection with "authentication failure", journalctl -lu kvmd-vnc on pikvm shows: Jul 27 20:44:18 pikvm kvmd-vnc[7970]: kvmd.apps.vnc.rfb INFO --- [main] [::ffff:1.1.1.1]:47710: Using VNCAuth security type Jul 27 20:44:18 pikvm kvmd-vnc[7970]: kvmd.apps.vnc.rfb ERROR --- [main] [::ffff:1.1.1.1]:47710: Error: VNCAuth access denied (user not found)

So, the question is what user name should I use? admin and empty string and the name set in the vncpasswd have been tried.

To Reproduce To reproduce the behavior, you should turn off encryption in Remmina, if you are trying to use it. On PIKVM in /etc/kvmd/override.yaml vncauth: enabled: true

Pi-KVM info:

• Raspberry Pi board version 3
• Pi-KVM platform v0-hdmi
• Video capture type CSI bridge
• KVMD version: 3.11-1

Additional context Sorry, if my question is stupid, but I need it.

[mdevaev]

Try admin -> admin: i vncpasswd. Left side is a passphrase, right side is user and password like on web ui.

[arch1mede]

Just beware that Remmenia uses libvnc which is a known issue.

[mdevaev]

@reallaborious sup?

[reallaborious]

Problem solved, thank you @mdevaev. Actually, it was my bad, I understood the comments in vncpasswd wrong. I thought API password can be set there. Adding < VncAuth password > -> < user >:< API password which was set during the configuration of the OS >
- helped. However, it seems a kind of a weird decision for me, I mean to write in a file one password to set another password. It looks both unsafe and not obvious. May I ask, was this decision based on some specific requirements, or it is a workaround?

[mdevaev]

Glad to hear it :)

Pi-KVM uses authorization by user/pass. It's the only way right now. At the same time, the basic RFB (VNC) protocol does not provide authorization by user/pass at all. All that is there is a passphrase method with limited length. As you understand, that person who developed VNC did not think about security at all.

To implement the user/pass, there is an extension that also adds SSL encryption. But some clients don't support this (and I would say that they also spit on security, as did the author of the RFB protocol). Due to the length restrictions, I can't just ask the user to enter something like "admin:password" instead of a passphrase, and I didn't want to introduce a bad authorization mechanism inside pikvm. You are right that writing a password in plain text is not safe, but there is no other way out in this situation. I have done everything in my power to support good VNC clients implementing secure protocols. If you want to use something insecure - then the transmitting password in clear text (which can only be read by root) without encryption is the least of you problems :)

I strongly recommend rejecting clients that don't support vencrypt. Or, at least, ask their developers to wake up, realize that it's 2021 and implement reliable authorization methods that have long been described in the standard. This is not difficult and not impossible (I speak as a gay who implemented the first H264-over-VNC protocol and pushed it into the standard).

[mdevaev]

And there are also all sorts of corner because of which the vencrypt/plain method does not work. This is not part of the standard, but many good clients implement it, and others do not (like vinagre, but since this breaks the state machine, they are obviously wrong). Details here: https://github.com/LibVNC/libvncserver/issues/458

The VNC protocol is full of legacy.

[reallaborious]

After all, I've rejected using vnc. Remmina doesn't work with vncauth in pikvm. It needs X509 still, which isn't supported by kvmd-vnc. So I turned off vnc and using the web interface. Btw I've changed js code to track ctrl. it is a workaround and works for combinations only but for my purposes, it's enough. Maybe I'll create a pull request for it.

[mdevaev]

It needs X509 still, which isn't supported by kvmd-vnc.

It's supported, both X.509 and TLS. Even enabled by default