qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: QEMU 7.2.0, -vnc :1, sasl=on ==> No matching security types (GTK-VNC


From: Frantisek Rysanek
Subject: Re: QEMU 7.2.0, -vnc :1, sasl=on ==> No matching security types (GTK-VNC SASL doesn't ring a bell)
Date: Wed, 18 Jan 2023 22:33:59 +0100

Dear everyone,

I've managed to move a little further and am kind of satisfied with 
the limited success.
This is my current set of options for the VNC-only video output, 
protected by a simple password (not even a login):

-vga std
-object secret,id=secvnc1,file=/etc/qemu/my-vnc-passwd.txt
-vnc :1,password-secret=secvnc1

Good enough for an internal LAN, I guess.

The minimal password protection can actually be achieved this way:

-vga std -vnc :1,password=on -monitor stdio

...but you need to define the password at the standard input of the 
qemu-system-* binary, after its startup! This is where you have asked 
the monitor commandline to live, and the command is:
  change vnc password
Good enough for basic testing, but not plausible for production 
operation.

Both these examples result in the QEMU VNC server proposing an auth 
mechanism called simply "VNC", i.e. just a single password. Which is 
supported by all the three VNC clients that I've tried: UltraVNC, 
TightVNC and TigerVNC. The mechanism does not transport the password 
in clear text, it uses a simple challenge-handshake exchange. Only a 
random challenge and an encrypted response are sent over the network.

It took me a bit of investigation to figure out.
I did recompile with TLS support, but that alone did not help.
Then I took a look inside ui/vnc.c , where I found some interesting 
options such as "sasl-authz" and "password-secret".
I tried googling those, and found the following links:

https://qemu-project.gitlab.io/qemu/system/vnc-security.html
https://www.qemu.org/docs/master/system/secrets.html#passing-secrets-a
s-clear-text-via-a-file
https://www.qemu.org/docs/master/system/authz.html 

It still took some trial and error, giving me a couple helpful hints 
about the mapping of an "-object" to the "-vnc" via password-secret.

I probably should've tried the TLS route long ago... :-)

Frank




reply via email to

[Prev in Thread] Current Thread [Next in Thread]