v0.1.1 - Credential Issues Cause Crowdsec Service to Fail to Start

[zkhcohen]

In v0.1.1, the /usr/local/etc/crowdsec/local_api_credentials.yaml file is generated without credentials the first time you start Crowdsec via the UI (Services > Crowdsec). I believe this may actually be caused by its inability to overwrite the prexisting local creds file.

Error:

[2.7.0-RELEASE][admin@pfsense]/root: tail /var/log/crowdsec/crowdsec.log
time="2023-12-30 18:59:56" level=warning msg="No matching files for pattern /var/log/httpd-access.log" type=file
time="2023-12-30 18:59:56" level=warning msg="No matching files for pattern /var/log/httpd-error.log" type=file
time="2023-12-30 18:59:56" level=info msg="loading acquisition file : /usr/local/etc/crowdsec/acquis.d/pfsense.yaml"
time="2023-12-30 18:59:56" level=info msg="Force add watch on /var/log" type=file
time="2023-12-30 18:59:56" level=info msg="Adding file /var/log/filter.log to datasources" type=file
time="2023-12-30 18:59:56" level=info msg="Force add watch on /var/log" type=file
time="2023-12-30 18:59:56" level=info msg="Adding file /var/log/nginx.log to datasources" type=file
time="2023-12-30 18:59:56" level=info msg="Starting processing data"
time="2023-12-30 18:59:56" level=info msg="Error machine login for  : ent: machine not found "
time="2023-12-30 18:59:56" level=fatal msg="starting outputs error : authenticate watcher (): API error: ent: machine not found"

After manually deleting this file from the server and then restarting the service, credentials are populated in this file and the service starts successfully.

If you save the configuration again via the UI (Services > Crowdsec), even without making any changes, the credentials appear to be invalidated and the service fails to start again. Deleting the file by hand again and then restarting the service generates new credentials and the service starts successfully.

---

EDIT: I'm not sure if this is related in any way, but I'm only seeing 2 scenarios in my S.E., versus 30-40+ in v0.1.

EDIT 2: I also had to run sysrc crowdsec_enable="YES" on this version.... I'm guessing both of these were supposed to be handled by the UI's start routine. (confirmed)

EDIT 3: Deleting the local creds file manually then saving the settings via the UI resolved those issues on a fresh install. So it appears that the best solution is to manually delete the creds file before the first save of the settings.

EDIT 4: Seems like every subsequent reboot requires you to follow the same steps. Restarting the service via service crowdsec restart doesn't regenerate the local api creds, either -- you have to use the UI. This also makes me wonder if there are other scenarios which would invalidate the credentials.

EDIT 5: After looking at crowdsec.inc it seems like the only time the creds actually get set by the UI is when a remote LAPI is being used. What's populating the credentials, then?

[voglcloud]

+1. I think I have the same problem here:

After a fresh installation of pfSense and a fresh installation of CrowdSec (each in the latest version), CrowdSec can only be used/service started again after a reboot of pfSense if the credential file is manually deleted. As long as this doesn't happen, I get the error message when I try to start the service:

root: service crowdsec.sh start crowdsec is not running. crowdsec is not running. Registering LAPI FATA[2024-01-01 06:07:02] credentials file '/usr/local/etc/crowdsec/local_api_cr edentials.yaml' already exists: please remove it, use "--force" or specify a different file with "-f" ("-f -" for standard output)

[p-schneider]

After every reboot the "pfsense" machine is forgotten so i re-add it manually every time:

cscli machines list | grep "^ pfsense "
cat /usr/local/etc/crowdsec/local_api_credentials.yaml
cscli machines add pfsense --force --password [the-password-that-was-printed-out-above]

(I'm not sure reusing the same password is necessary, maybe using a new/random password every time would work just as well.) Then I can start the service in pfsense (/status_services.php). Afterwards the output of cscli machines list | grep "^ pfsense " would show that "pfsense" is once again registered as machine and the last heartbeat should be within 1 minute.

(That already happened in the previous version, but in the new release the "--force" parameter is now needed.)

[mmetc]

Hi,

from a quick look the issue seems to be with the crowdsec 1.5.6~rc8 package, I'm going to build a new one asap or replace it with the stable version.

The crowdsec and bouncer services should not be enabled with sysrc or in rc.conf, pfsense does its own thing.

Can you install the previous version from the v0.1 release? And remove it from rc.conf

https://github.com/crowdsecurity/pfSense-pkg-crowdsec/releases/download/v0.1/crowdsec-1.5.5.pkg

Thanks!

[p-schneider]

time="2024-01-03 09:24:01" level=info msg="Error machine login for pfsense : ent: machine not found "
time="2024-01-03 09:24:01" level=fatal msg="starting outputs error : authenticate watcher (pfsense): API error: ent: machine not found"

I still saw this in the logs after upgrading to crowdsec-1.5.6.r8_1 and pfSense-pkg-crowdsec-0.1.2 so i manually had to use cscli machines add pfsense --force --password ... to re-add the machine "pfsense" once again.

I'll see if that still happens after a reboot the next time i reboot the machine.

But I think my issue is similar to, but not exactly the same as the issue mentioned by zkhcohen.

[danielholm]

I do still have this issue, and re-adding the credentials/machine as the comment above, works. But I have to do it every day.

[Y0ngg4n]

Same problem here. Even if i register machines with lapi register multiple times i get a new machine id every time. Sometimes i have to readd the pfsense like every 15 minutes.