[pve-devel] vncpropxy question

[pve-devel] vncpropxy question

[Dietmar Maurer]

in qemu-server, I wonder why we set $ENV{LC_PVE_TICKET} conditionally? Does not make any sense to me, because it make all other connection failing...


diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index 99b426e..c6a3ac1 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -2102,7 +2102,7 @@ __PACKAGE__->register_method({
 
            } else {
 
-               $ENV{LC_PVE_TICKET} = $password if $websocket; # set ticket with "qm vncproxy"
+               $ENV{LC_PVE_TICKET} = $password; 
 
                $cmd = [@$remcmd, "/usr/sbin/qm", 'vncproxy', $vmid];

Re: [pve-devel] vncpropxy question

[Dominik Csapak]

On 6/30/22 13:02, Dietmar Maurer wrote:
> in qemu-server, I wonder why we set $ENV{LC_PVE_TICKET} conditionally? Does not make any sense to me, because it make all other connection failing...
> 
> 
> diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
> index 99b426e..c6a3ac1 100644
> --- a/PVE/API2/Qemu.pm
> +++ b/PVE/API2/Qemu.pm
> @@ -2102,7 +2102,7 @@ __PACKAGE__->register_method({
>   
>              } else {
>   
> -               $ENV{LC_PVE_TICKET} = $password if $websocket; # set ticket with "qm vncproxy"
> +               $ENV{LC_PVE_TICKET} = $password;
>   
>                  $cmd = [@$remcmd, "/usr/sbin/qm", 'vncproxy', $vmid];
> 
> 

AFAICS, this is a remnant of old code where we would start wsproxy.py instead of our
  'qm vncproxy'

i think we could remove the whole websocket parameter as it doesn't
do anything here

so we could do
1. remove the use of $websocket here
2. remove the websocket=1 parameter in novnc
3. remove the websocket parameter completely (in 8.0, since it's a breaking api change)

Re: [pve-devel] vncpropxy question

[Dominik Csapak]

On 6/30/22 13:25, Dominik Csapak wrote:
> On 6/30/22 13:02, Dietmar Maurer wrote:
>> in qemu-server, I wonder why we set $ENV{LC_PVE_TICKET} conditionally? Does not make any sense to 
>> me, because it make all other connection failing...
>>
>>
>> diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
>> index 99b426e..c6a3ac1 100644
>> --- a/PVE/API2/Qemu.pm
>> +++ b/PVE/API2/Qemu.pm
>> @@ -2102,7 +2102,7 @@ __PACKAGE__->register_method({
>>              } else {
>> -               $ENV{LC_PVE_TICKET} = $password if $websocket; # set ticket with "qm vncproxy"
>> +               $ENV{LC_PVE_TICKET} = $password;
>>                  $cmd = [@$remcmd, "/usr/sbin/qm", 'vncproxy', $vmid];
>>
>>
> 
> AFAICS, this is a remnant of old code where we would start wsproxy.py instead of our
>   'qm vncproxy'
> 
> i think we could remove the whole websocket parameter as it doesn't
> do anything here
> 
> so we could do
> 1. remove the use of $websocket here
> 2. remove the websocket=1 parameter in novnc
> 3. remove the websocket parameter completely (in 8.0, since it's a breaking api change)
> 

addendum:

'it doesn't do anything here' is not completely correct
for 'regular' vm displays it just does not set the ticket which
breaks the connection

for use with a serial terminal in the vm, we also
set '-notls' and '-listen localhost' for vncterm

if we'd drop the parameter anyway (with 8.0) and use always
'-notls -listen localhost' i think we could drop the custom
libvncserver package in vncterm and use the debian packaged
one (since we'd never use tls then anyway)

we could even go a step further and remove support for terminals
over vnc completely, since we have support for that in the
browser with xterm.js since quite some time

Re: [pve-devel] vncpropxy question

[Thomas Lamprecht]

On 30/06/2022 13:50, Dominik Csapak wrote:
> 
> we could even go a step further and remove support for terminals
> over vnc completely, since we have support for that in the
> browser with xterm.js since quite some time

and spiceterm, which can make some sense to keep to provide a single
client that can do all and is relatively feature full (also, IIRC,
Dietmar wasn't to happen when I proposed dropping both for 7.0, but at
least vncterm could really go with future 8.0 next year IMO)

Re: [pve-devel] vncpropxy question

[Dietmar Maurer]

> addendum:
> 
> 'it doesn't do anything here' is not completely correct
> for 'regular' vm displays it just does not set the ticket which
> breaks the connection

I think this ("break the connection") is important, because otherwise it would allow unecrypted VNC traffic over the network. I guess we do not want that.

But qemu now supports more VNC auth types, so maybe we can allow TLS encrypted VNC from outside, and unecrypted VNC for local proxy code.

I will take a look at that when I am back from vacation...

Re: [pve-devel] vncpropxy question

[Dominik Csapak]

On 7/1/22 08:39, Dietmar Maurer wrote:
>> addendum:
>>
>> 'it doesn't do anything here' is not completely correct
>> for 'regular' vm displays it just does not set the ticket which
>> breaks the connection
> 
> I think this ("break the connection") is important, because otherwise it would allow unecrypted VNC traffic over the network. I guess we do not want that.
> 
> But qemu now supports more VNC auth types, so maybe we can allow TLS encrypted VNC from outside, and unecrypted VNC for local proxy code.
> 
> I will take a look at that when I am back from vacation...


i don't understand your message.. not setting the Ticket here does not allow unencrypted VNC 
traffic? in 'qm vncproxy' we die if the ticket is not set, and even if we'd not,
the vnc server from qemu does not listen on a public ip, but on 127.0.0.1 (or ::1)

but yeah, we can look at that after your vacation ;)