[SOLVED] Proxmox API - Token authentication error for vncshell (value 'root@pam!Test01' does not look like a valid user name)

[wardpire]

Hi, I'm currently testing the PVE-API and I've come across a strange behavior.

To access the API I use API Tokens according to the instructions at https://pve.proxmox.com/wiki/Proxmox_VE_API.

Almost all ednpoints work fine, but endpoints: HTTP: POST /api2/json/nodes/{node}/vncshell and HTTP: POST /api2/json/nodes/{node}/termproxy
returns error 500 with message value 'root@pam!Test01' does not look like a valid user name.

At first glance it looks like a the username for a terminal session was parsed incorrectly from the token, but i might be wrong. I have not been able to pinpoint this in the source files.

Is it a bug, or these endpoints do not support API Token authentication ... or have I completely missed something?

Thank you for any advice, help or information.

=========================

To reproduce:

1. Clean proxmox-ve version 7.3, Mon 21 Nov 2022 12:23:41 PM CET
2. Add (through web gui) new token "Test01" for root@pam (no privilege separation)
3. Call API:
   

   curl -kv -H 'Authorization: PVEAPIToken=root@pam!Test01=d688c5a0-b331-496a-bc70-377a47e0b2ca' https://169.254.88.70:8006/api2/json/nodes/pve/termproxy -d ''
   
   >Authorization: PVEAPIToken=root@pam!Test01=d688c5a0-b331-496a-bc70-377a47e0b2ca
   >POST /api2/json/nodes/pve/termproxy HTTP/1.1
   <HTTP/1.1 500 value 'root@pam!Test01' does not look like a valid user name
   <{"data":null}

Others endpoints are working well:

curl -kv -H 'Authorization: PVEAPIToken=root@pam!Test01=d688c5a0-b331-496a-bc70-377a47e0b2ca' https://169.254.88.70:8006/api2/json/nodes/pve/stopall -d ''

>Authorization: PVEAPIToken=root@pam!Test01=d688c5a0-b331-496a-bc70-377a47e0b2ca
>POST /api2/json/nodes/pve/stopall HTTP/1.1
<HTTP/1.1 200 OK
<{"data":"UPID:pve:000005AA:00004786:63C82611:stopall::root@pam!Test01:"}

Also when Cookie authentication is used all seems to be ok:

curl -kv -H 'Authorization: PVEAuthCookie=PVE%3Aroot@pam%3A63C80E94%3A%3An6o+EmmI0H71+88FGyZAZ3K/zB0Xo3eQFf4+Lk7PfcoDR85TMMzui7wX8bwugfGyBN/x7CPxJtb/KrB96wxzE31BXPAI0L/7g5di5R2ba9a9EjSneOH0Ist7i+WtaAZwGsQbxn5bS74kIfvOLlDtOdWqaAe99v6zgA0QEN4mvtHul6WRV0kJMwocTv6HX8+Q4qHWPTJMvyqAAtI4df41uCdE2bT0Tvd/BgiuoBT7ppGQprc20duRJOTwrelXESTGSBVrs6DgPyFjx2lc2m7l5KWyVn8wTtjAwZFbEcf4HGpGWS/6DECnBt0rD0AaDrkYq/S3sg23tZebLO5UGndirg%3D%3D' -H 'CSRFPreventionToken: 63C80EA2:JgKNYwgSnlCNIvabngcGNbLcpaYcenbmql975fao2L4' https://169.254.88.70:8006/api2/json/nodes/pve/termproxy -d ''

> POST /api2/json/nodes/pve/termproxy HTTP/1.1
> Authorization: PVEAuthCookie=PVE%3Aroot@pam%3A63C80E94%3A%3An6o+EmmI0H71+88FGyZAZ3K/zB0Xo3eQFf4+Lk7PfcoDR85TMMzui7wX8bwugfGyBN/x7CPxJtb/KrB96wxzE31BXPAI0L/7g5di5R2ba9a9EjSneOH0Ist7i+WtaAZwGsQbxn5bS74kIfvOLlDtOdWqaAe99v6zgA0QEN4mvtHul6WRV0kJMwocTv6HX8+Q4qHWPTJMvyqAAtI4df41uCdE2bT0Tvd/BgiuoBT7ppGQprc20duRJOTwrelXESTGSBVrs6DgPyFjx2lc2m7l5KWyVn8wTtjAwZFbEcf4HGpGWS/6DECnBt0rD0AaDrkYq/S3sg23tZebLO5UGndirg%3D%3D
> CSRFPreventionToken: 63C80EA2:JgKNYwgSnlCNIvabngcGNbLcpaYcenbmql975fao2L4
< HTTP/1.1 200 OK
< {"data":{"port":"5901","ticket":"PVEVNC:63C8299F::d+YsrXZ6qy+okq9Hz/XJWh9oSGmIKh+4eUrSJFu1NOWMNumOgwnaIzeGOFIPNUmZ6MXnZSe0coxP7w3jNr0qiDlX6Nk8a/ehPLjFW9BsoTnN5KIBc0RoRZgZGDhOleFpMKf95Dnt/eUCeIfqtdLi6PTsn32wiForjVE6Kp0wMqKn6JFvzRrLZvBPicYX4pDL4DivZVfr1SCRB5EVCaGV7mrLLc0hWF0IjBinkh3klFHRL4qblCIoAPPjxuKdFgfNimPc1FEiMJDYYOyOznHa45r6gzhKnVKvyQNFz2rRmRjdr+r51HKsNV5lq8cqCYnTpikdIKJgYmzjHWJfHBtaOA==","user":"root@pam","upid":"UPID:pve:00000E14:0001AB40:63C8299F:vncshell::root@pam:"}}

VncShell has the same problem:

curl -kv -H 'Authorization: PVEAPIToken=root@pam!Test01=d688c5a0-b331-496a-bc70-377a47e0b2ca' https://169.254.88.70:8006/api2/json/nodes/pve/vncshell -d ''

>POST /api2/json/nodes/pve/vncshell HTTP/1.1
>Authorization: PVEAPIToken=root@pam!Test01=d688c5a0-b331-496a-bc70-377a47e0b2ca
<HTTP/1.1 500 value 'root@pam!Test01' does not look like a valid user name
<{"data":null}

 

[fiona]

Hi,
the API endpoint documentation you already linked to mentions the fact that it's restricted to users in the pam realm. That is, because you actually are logged in as those users afterwards. That is also why a token doesn't really make sense there. The shell is not (and can't really be) limited to any token permissions after all.

 

[wardpire]

Thank you for the quick reply and explanation.

It look like I totally missinterpreted these restrictions.

Restricted to users on realm 'pam'
Check: ["perm","/nodes/{node}",["Sys.Console"]]

I wrongly assumed that if API Token is acting on behalf underlying root@pam user, there will be created temporary login session for this user only for time, when particular vnc connection is active.

Hopefully it will help others interprret the limitations at least.

One small additional questinon. Is there any way to execute arbitary command on cluster node with token only, without knowing the password of underlying user?

 

[fiona]

One small additional questinon. Is there any way to execute arbitary command on cluster node with token only, without knowing the password of underlying user?

No, tokens are not designed for arbitrary commands. They are for interacting with API endpoints. What non-arbitrary thing do you actually want to achieve? Maybe that is already implemented or can be implemented.