[SOLVED] How to tell /vncwebsocket to reply in text mode suitable for xterm.js?

[b6r]

Hi

While integrating an xterm.js-based web terminal that talks to a Proxmox VM into my application I stumbled across the following issue.

How can I tell the /vncwebsocket endpoint to answer using the text-based protocol documented in readme?
I assumed that passing it a `vncticket` obtained from the /termproxy endpoint does this automatically, but that does not seem to be the case.

I can successfully get the ticket from the /termproxy endpoint and pass it to /vncwebsocket. But the resulting websocket always sends an immediate binary message with the content "RFB 003.008.". I assume this is part of the VNC protocol for clients like noVNC.

I tried using API tokens and regular user tickets, but both did not work.

Has anyone more insights into this?

Thanks in advance.

 

[b6r]

I figured it out!

The /termproxy endpoint checks the Referer http header for query params. If I set it so something like

https://192.168.3.6:8006/?console=kvm&xtermjs=1&vmid=100&vmname=ubuntu-24&node=flitzer&cmd=

I get a ticket that opens a websocket read for xterm.js. I think this behavior is kind of unintuitive for an HTTP API and also not really documented but at least it works now.

Additionally I stumbled upon the issue that you cannot use API tokens for opening a /termproxy websocket but they seem to work fine for a /vncproxy websocket. This does not really make much sense to me, since they are functionally the same thing (you can execute arbitrary commands).

@fiona mentioned in this topic that API tokens are not designed for remote shells but since they seem to work for vnc websockets I'm wondering if this is a security issue? It's worth noting that I only tested it with an API token with privilege separation disabled, so that might be the reason.

Related issues

• https://forum.proxmox.com/threads/t...oxy-tickets-created-by-api-token-users.91733/
• https://forum.proxmox.com/threads/p...ok-like-a-valid-user-name.121248/#post-527042

 

[fiona]

Hi,

Additionally I stumbled upon the issue that you cannot use API tokens for opening a /termproxy websocket but they seem to work fine for a /vncproxy websocket. This does not really make much sense to me, since they are functionally the same thing (you can execute arbitrary commands).

@fiona mentioned in this topic that API tokens are not designed for remote shells but since they seem to work for vnc websockets I'm wondering if this is a security issue? It's worth noting that I only tested it with an API token with privilege separation disabled, so that might be the reason.

the topic you reference is not about the vncproxy endpoint. It is about the vncshell API endpoint giving access to a shell on the Proxmox VE node. You cannot use an API token to connect to that.

What exactly do you think is a security issue? The API token needs VM.Console permissions for the VM for the vncproxy and termproxy API endpoints.

 

[b6r]

Hi,

the topic you reference is not about the vncproxy endpoint. It is about the vncshell API endpoint giving access to a shell on the Proxmox VE node. You cannot use an API token to connect to that.

What exactly do you think is a security issue? The API token needs VM.Console permissions for the VM for the vncproxy and termproxy API endpoints.

Hi,

Thanks for your answer. Okay I missed that.

I don't think it's a security issue then but just inconsistent behavior. I see the same value 'root@pam!Test01' does not look like a valid user name error (as mentioned in the linked topic) when using the termproxy endpoint with an API token.

Based on your statement I guess this endpoint should work with an API token?

 

[fiona]

Hi,

Thanks for your answer. Okay I missed that.

I don't think it's a security issue then but just inconsistent behavior. I see the same value 'root@pam!Test01' does not look like a valid user name error (as mentioned in the linked topic) when using the termproxy endpoint with an API token.

Based on your statement I guess this endpoint should work with an API token?

For me

curl -k -H "Authorization: PVEAPIToken=root@pam!remote2=xxxx-xxx" -H "CSRFPreventionToken: $csrf_token" -X POST https://localhost:8006/api2/json/nodes/pve8a1/qemu/1234/termproxy

does not give that error.

Please share the exact steps and parameters you are using (masking only the token secret) as well as the output of pveversion -v.

 

[b6r]

Sorry, I think I expressed myself unclearly.
The error happens when authenticating to a /vncwebsocket with a vncticket you previously obtained from /termproxy using an API token. Obtaining the ticket with the API token is no problem.

More specifically the error occurs when sending the authentication message over the websocket root@pam!my.token:PVEVNC:67866C76....HeZOymA==\n.

Here's how I get the token (note the Referer header for explicit xterm.js support).

curl -i -X POST \
  -H "Accept: application/json" \
  -H "Authorization: PVEAPIToken=root@pam\!my.token=da01f75e-3ea5-4105-87bf-7b69dc7cbe54" \
  -H "Referer: https://192.168.3.6:8006/?console=kvm&xtermjs=1&vmid=100&vmname=ubuntu-24&node=flitzer&cmd=" \
  "https://192.168.3.6:8006/api2/json/nodes/flitzer/qemu/100/termproxy"

When I then pass the resulting ticket to Postman (since curl does not support websockets) I can establish the websocket connection. But upon sending the authentication message the following error is logged by pvedaemon.

Jan 14 14:54:14 flitzer pvedaemon[1594190]: authentication failure; rhost=127.0.0.1 user=root@pam!my.token msg=value 'root@pam!my.token' does not look like a valid user name
Jan 14 14:54:17 flitzer pvedaemon[1600623]: command '/usr/bin/termproxy 5900 --path /vms/100 --perm VM.Console -- /usr/sbin/qm terminal 100 -escape 0 -iface serial0' failed: exit code 1
Jan 14 14:54:17 flitzer pvedaemon[1594190]: <root@pam!my.token> end task UPID:flitzer:00186C6F:02114E35:67866C76:vncproxy:100:root@pam!my.token: command '/usr/bin/termproxy 5900 --path /vms/100 --perm VM.Console -- /usr/sbin/qm terminal 100 -escape 0 -iface serial0' failed: exit code 1

The same process works if I use a session ticket instead of the API token.

Output of pveversion -v:

pveversion -v
proxmox-ve: 8.3.0 (running kernel: 6.8.12-5-pve)
pve-manager: 8.3.2 (running version: 8.3.2/3e76eec21c4a14a7)
proxmox-kernel-helper: 8.1.0
proxmox-kernel-6.8: 6.8.12-5
proxmox-kernel-6.8.12-5-pve-signed: 6.8.12-5
proxmox-kernel-6.8.12-4-pve-signed: 6.8.12-4
ceph: 19.2.0-pve2
ceph-fuse: 19.2.0-pve2
corosync: 3.1.7-pve3
criu: 3.17.1-2
dnsmasq: 2.89-1
frr-pythontools: 8.5.2-1+pve1
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx11
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.1
libproxmox-backup-qemu0: 1.4.1
libproxmox-rs-perl: 0.3.4
libpve-access-control: 8.2.0
libpve-apiclient-perl: 3.3.2
libpve-cluster-api-perl: 8.0.10
libpve-cluster-perl: 8.0.10
libpve-common-perl: 8.2.9
libpve-guest-common-perl: 5.1.6
libpve-http-server-perl: 5.1.2
libpve-network-perl: 0.10.0
libpve-rs-perl: 0.9.1
libpve-storage-perl: 8.3.3
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 6.0.0-1
lxcfs: 6.0.0-pve2
novnc-pve: 1.5.0-1
proxmox-backup-client: 3.3.2-1
proxmox-backup-file-restore: 3.3.2-2
proxmox-firewall: 0.6.0
proxmox-kernel-helper: 8.1.0
proxmox-mail-forward: 0.3.1
proxmox-mini-journalreader: 1.4.0
proxmox-offline-mirror-helper: 0.6.7
proxmox-widget-toolkit: 4.3.3
pve-cluster: 8.0.10
pve-container: 5.2.3
pve-docs: 8.3.1
pve-edk2-firmware: 4.2023.08-4
pve-esxi-import-tools: 0.7.2
pve-firewall: 5.1.0
pve-firmware: 3.14-2
pve-ha-manager: 4.0.6
pve-i18n: 3.3.2
pve-qemu-kvm: 9.0.2-4
pve-xtermjs: 5.3.0-3
qemu-server: 8.3.3
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.6-pve1

 

[fiona]

Oh, I see. Might be that handling tokens is not implemented yet somewhere along the way. I can see that termproxy is used for both, guest consoles as well as node consoles. Spawning the console on the node does require the Sys.Console permission. Still, needs to be evaluated carefully when adding support for tokens, so that a token alone cannot get access to a node console as that user.
Feel free to open an issue on the bugtracker linking back to the thread here: https://bugzilla.proxmox.com/

 

[b6r]

Bug is filed: https://bugzilla.proxmox.com/show_bug.cgi?id=6079
For now I guess I have to rely on the VNC console or create a service that turns my API token into a session ticket.