Incus console terminal issue

Incus
1

Incus version 6.22
Ubuntu 24.04. 6.8.0-101-generic

We had a remote conole with xterm.js running for years.

Posting to /1.0/instances/{name}/console works, get the operation and data/control secrets.

ControlURL: wss://host_IP:8443/1.0/operations/{opertaion}/websocket?secret={[“fds”][control]}
DataURL: wss://host_IP:8443/1.0/operations/{opertaion}/websocket?secret={[“fds”][0]}

though websocket dies with:
[error]: Data undefined
[close]: died Data1006
Keystrokes producing “WebSocket is already in CLOSING or CLOSED state”

Can not debug it further, lxc monitor shows class websocket created, going than from status code 105 to status code 103.

Tested with Ubuntu and alpine containers.
Certificates and config trust certificates are fine, all other API trusted transactions working so far.

It had worked for many years, recently after an upgrade, stopped working, unfortunately can’t trace back which Incus upgrade broke it.

Could it be related to host/container root subuid & subgid?

2

Is the same API user doing the POST to /1.0/instances/NAME/console and then connecting to the websocket? We did add tighter security around that a little while back to prevent someone from monitoring the background operations and then connecting to it before the requestor gets to it.

3

Not same.
All done from within a container, aiming at Incus host internal IP (10.0.4.1:8443, 192.168.1.1:8443, even tried server public IP or server https://serverdoamin:8443 with SSL).
Post done by nginx, php as webuser (www-data, user 1000100 on host), websocket connection runs from same container as root (user 1000000 on host).

4

Websocket was node wss://
I also tried using an nginx proxy httpupgrade (websocket) as alternative, that has failed too. I guess the nginx wss:// would have been the same user (www-data) as POST requester.

5

Appreciate any hint, how to comply with that tighter security or disable the new security feature.

6

The check makes sure that the requestor credential matches for those API routes.
It checks that the username and protocol is the same.

Basically run incus info | grep ^auth_user in both environments, if the result is the same, then you won’t have a problem with the check, if you’re getting different values, then you are trying to access another user’s operations and the security check will block you.

7

For example, if you create the operation using the unix socket as the root user, you’ll have protocol=unix user=root, if you then access it over the network using an HTTPS client certificate, you’ll get protocol=tls user=FINGERPRINT, that won’t work.

If you connect using OIDC authentication, you’ll get protocol=oidc user=USERNAME.

And if you’re using two different system users with the same unix socket, then you’ll both get protoocl=unix but username= will be different.

8

Thanks.

It is a little bit difficult to achieve, I probabely don’t get the concept fully.

Incus is running on host, web application in a container, a incus info | grep ^auth_user not possible inside container.

Operation created by webuser (nginx) as PHP Curl, user nginx (1000100 on host), streams transported by node server, can be nginx (1000100), still possible to run as root (1000000).
From Container to host, there is no way of Unix socket, all over TCP, Operation https://hostip:8443, Terminal proxied wss://hostip:8443.

So, either way result might be protocol=tls user=FINGERPRINT, but I guess with different fingerprints. Can’t trace on Incus host who (unix user or Fingerprint) exactly triggers the operation and/or the subsequent websocket.

Could try OIDC, but it will add one more complexity, dealing with Incus OIDC, PHP/WSS OIDC authentication and the OIDC (Server) Client profile definition.