Client certificates are not generated

1

I’m using Incus on my laptop as ordinary user in incus group (not incus-admin), after update to version 6.16 I started to receive strange errors while running cli commands, something related to certificate, so I removed ~/.config/incus dir hoping for client configuration would be recreated, but now whenever I run any incus command I get an error Error: not authorized, and I noticed that there’s no client cert generated in ~/.config/incus so I cannot ad it to trusted. what can be the cause?

PS: Authenticating with web UI works fine, BTW

2

The incus CLI client either uses the Unix permissions to access the Incus server, or uses certificates just like the Web UI.

If you remove the ~/.config/incus/ directory and then run an incus CLI command, the incus CLI tool will recreate a default config.yml file with the standard contents:

$ cat config.yml 
default-remote: local
remotes:
  images:
    addr: https://images.linuxcontainers.org
    protocol: simplestreams
    public: true
  local:
    addr: unix://
    protocol: incus
    public: false
aliases: {}
defaults:
  list_format: ""
  console_type: ""
  console_spice_command: ""
$

That means, you get the default configuration file with the Unix socket authentication to the Incus server. That means that the incus CLI needs to be running on the same host as the Incus server.

With the Unix socket authentication, your Unix account should have access to these Unix sockets. In your case, your non-root account should be a member of the incus Unix group so that the CLI client utility can access the Unix socket /var/lib/incus/unix.socket.user.

$ ls -l /var/lib/incus/unix.socket*
srw-rw---- 1 root incus-admin 0 Σεπ  15 07:00 /var/lib/incus/unix.socket
srw-rw---- 1 root incus       0 Σεπ  15 07:00 /var/lib/incus/unix.socket.user
$

Therefore, have a look at your setup and verify that the Unix sockets are accessible by your Unix account as shown above.

If all fails, you can get the CLI client to authenticate with certificates just like the Web UI. But better check what’s up with the Unix sockets.

3

OK, I think I see what’s the problem: I have no access to /var/lib/incus

realgecko@rog-strix ~> groups
realgecko games incus systemd-journal
realgecko@rog-strix ~> ls -l /var/lib/incus | grep socket
ls: cannot open directory ‘/var/lib/incus’: Permission denied
realgecko@rog-strix ~ [2|1]> ls -la /var/lib | grep incus
drwx–x–x 17 root root 4096 сен 15 00:12 incus
realgecko@rog-strix ~>

I guess something related to Arch packaging, what permissions I need to set to /var/lib/incus?

4

Run chmod 755 /var/lib/incus, now I can see inside the dir and see sockets with ls, however still get error:

~> groups
realgecko games incus systemd-journal
~> ls -l /var/lib/incus/unix.socket*
srw-rw---- 1 root incus-admin 0 сен 15 00:12 /var/lib/incus/unix.socket=
srw-rw---- 1 root incus 0 сен 15 00:12 /var/lib/incus/unix.socket.user=
~> incus ls
Error: not authorized
~ [1]>

5

Apologies for the misinformation. I was root when I run the command earlier and I could list the content of the directory. Here is the proper output.

$ ls /var/lib/incus/
ls: cannot open directory '/var/lib/incus/': Permission denied
$ ls /var/lib/incus/*socket*
ls: cannot access '/var/lib/incus/*socket*': No such file or directory
$ ls -l /var/lib/incus/unix.socket
srw-rw---- 1 root incus-admin 0 Σεπ  15 07:00 /var/lib/incus/unix.socket
$ ls -l /var/lib/incus/unix.socket.user
srw-rw---- 1 root incus 0 Σεπ  15 07:00 /var/lib/incus/unix.socket.user
$ ls -ld /var/lib/incus
drwx--x--x 19 root root 4096 Σεπ  15 07:00 /var/lib/incus
$

Therefore, the default permissions for /var/lib/incus are drwx--x--x (711). The Incus client knows the full path to the socket, which means that it can blindly access the exact file /var/lib/incus/unix.socket.user and since it exists, it can open it (the individual permissions are OK, i.e. group membership to the incus Unix group).

To fix back the permissions of /var/lib/incus, run the following

sudo chmod 711 /var/lib/incus/
6

To answer the topic title. The client certificates are not auto-generated. You need to perform a set of steps to generate them. Whereas with the default authentication with the Unix sockets, the CLI client has hard-coded information on the location of those sockets, and tries to open them (i.e. /var/lib/incus/unix.socket.user and /var/lib/incus/unix.socket).

7

So, I’ve generated client cert like this incus config trust add-certificate /home/realgecko/.config/incus/client.crt --restricted --projects user-1000. I now have a proper cert and I’ve also added it as trusted incus config trust add-certificate /home/realgecko/.config/incus/client.crt --restricted --projects user-1000. Restarted the service and still get Error: not authorized. journalctl contains few lines like this level=warning msg="Rejecting request from untrusted client" ip=@
Any other ways to diagnose the cause?

incus config trust ls shows both UI and my certs as accepted, but only one from web UI works.