Candid authentication

Thanks to Mr. Graber for pointing me to discuss forum, as the above mentioned github issue, not really an appropriate space to discuss this.
lxc remote add localhost http://localhost:8443 --auth-type=candid
keeps showing error:
user-open error: exec: “dbus-launch”: executable file not found in $PATH
Even if I can make it in time by some mentioned way around for a headless Server environment like open new console and
still not working.
I agree with the necessity of an external centralized and secure auth system for lxd.
But Candid in this stage is an absolute anti automation.
I see all sorts of efforts to automate the processes including cluster wide concepts, than comes again this auth system which claims production suggestions of mongodb and pgsq to mimic a huge cluster operation, but again you need to login in each instance, do the manual input and copy paste, y/n … and finall open a browser and type in user an password?? I am happy they s from that google captcha find cars and cats!
Is lxd really walking towards home PC and Laptop with open browser and play?
It is not documented.
No idea, how to authenticate for remote lxd api interactions.
Below worked for the classic lxd key/cert. How to deal with Candid?
curl -s -k --cert ‘.$crt.’ --key ‘.$key.’ -X ‘.$method.’ ’ . $data . ’ https://’ . $address . ‘:8443’ . $api_endpoint;

In this case, you may be better served by tooling managing client certificates, possibly using the PKI mode we have in LXD to generate a certificate authority, issue server certificates for your servers and client certificates for your clients.

With such a setup, you can avoid the use of the trust password so long as the client certificate is valid and issued by your certificate authority and if you add that CA to your client’s system trust store, this will also save you from the fingerprint prompt as the validation will happen through the trust chain on the CA.

This setup is documented in:

The candid based authentication is useful for environments with a large user base where easy access revocation is critical. I normally run candid with just a local sqlite database since it’s really just a gateway to your authentication systems and so doesn’t need HA persistent state. The web-based workflow is a deliberate security measure as it avoids our CLI ever knowing your user’s username, password, 2FA token, … All that our client ever gets is an authentication token with a short expiry and a cookie to do background renewal of that token. So even if there is a critical bug in our code or someone replaced lxc with a malicious one, all you get is a token valid against that LXD server, not enterprise-wide user credentials.

To avoid some of the pain you’re describing, I usually make sure that the candid server itself is easily reachable by users, often just running it on a public IP/domain. The target servers can remain heavily firewalled or put behind a VPN but that means that the user can still just open the link in any regular local web browser to validate access and don’t need to jump through hoops like using a remote text browser.

It is not documented.
No idea, how to authenticate for remote lxd api interactions.
Below worked for the classic lxd key/cert. How to deal with Candid?
curl -s -k --cert ‘.$crt.’ --key ‘.$key.’ -X ‘.$method.’ ’ . $data . ’ https://’ . $address . ‘:8443’ . $api_endpoint;

Candid effectively uses a bunch (usually 3) cookies, so you’ll need a persistent cookie jar and follow the redirects to authenticate against candid and its backing servers.

I don’t think I’ve ever dealt with plain curl when using that authentication method, but you can use bhttp or lxc query to do that if you wish.

Mr. Graber,
I am an admirer of your work and your colleagues’.
Your regular insights about LXD are quite legendary.
The more excited, by getting your fast reply to issues.
I hope my well intended critics help you a bit more by getting once more a user’s experience feedback.

Candid is very web centered and web browser based.
As great as that concept is, it is not a perfect match for LXD in server environments, from my point of view.