Open ohadperry opened 8 years ago
Yes, that would be easier. Taking a look at both issues.
hi Daniel, sorry for the nudge, but any update?
Can you confirm you re-compiled the agent with the new code? I just tried and it auto found OpenSSL properly on Debian. Try to remove it and get the latest version again...
confirmed . reinstalled
wget -O latest_ossec.zip https://bitbucket.org/dcid/ossec-hids/get/00fbcbe7ab2a.zip
unzip latest_ossec.zip
cd dcid-ossec-hids-00fbcbe7ab2a
./install.sh
/var/ossec/bin/agent-auth -m xxx.xxx.xxx.xx -p 1515
ERROR: Not compiled. Missing OpenSSL support.
@dcid any updates on this ? anything else I can try?
Get this one:
https://dcid.me/ossec-packages/ossec-hids-latest.tar.gz
And make sure that libssl-dev is installed. If that doesn't work, mind sending a paste of the whole install process? It should show what flags are used.
@dcid ok , some progress now. on the client:
root@client-server:~/ossec-hids-2016-04# /var/ossec/bin/agent-auth -m 10.128.0.8 -p 1515
2016/04/11 06:12:27 ossec-authd: INFO: Started (pid: 519).
WARN: No authentication password provided. Insecure mode started.
INFO: Connected to 10.128.0.8:1515
INFO: Using agent name as: chef-production2-doctor-simulator01
INFO: Send request to manager. Waiting for reply.
ERROR: Unable to create key. Either wrong password or connection not accepted by the manager.
INFO: Connection closed.
on the server
tail -f /var/ossec/logs/ossec.log
2016/04/11 09:13:47 ossec-authd: INFO: New connection from 10.128.0.2
2016/04/11 09:13:48 ossec-authd: ERROR: Invalid password provided by 10.128.0.2. Closing connection.
in here I don't need to pass any cert , right? just create on the server?
@dcid any answer on the Invalid password
?
Can you paste the output when you run authd on the manager side? Right now we force a password by default, and explains this error:
2016/04/11 09:13:48 ossec-authd: ERROR: Invalid password provided by 10.128.0.2. Closing connection.
So you need to re-run authd and get the password and use that on agent-auth. Can you try that?
I got a random password on the server
/var/ossec/bin/ossec-authd -p 1515
Random password chosen for agent authentication: 7b9....ba
but... "use that on agent-auth"? can you paste some code to explain that? I didn't see anything in the
/var/ossec/bin/agent-auth -h
OSSEC HIDS ossec-authd: Connects to the manager to extract the agent key.
Available options:
-h This help message.
-m <manager ip> Manager IP Address.
-p <port> Manager port (default 1515).
-A <agent name> Agent name (default is the hostname).
-D <OSSEC Dir> Location where OSSEC is installed.
@dcid sorry to bother you , but do you have an answer for me?
Can you try with the option -P (uppercase P) followed by the password?
Forgot to update the help message with it, but should work.
hi @dcid , tried with P
, --password
and no password :
/var/ossec/bin/agent-auth -P 334a89e00a9c63457894ff8d306cd766 -m 10.128.0.8
/var/ossec/bin/agent-auth --password 334a89e00a9c63457894ff8d306cd766 -m 10.128.0.8
/var/ossec/bin/agent-auth -m 10.128.0.8
on the server
2016/04/18 09:35:16 ossec-authd: INFO: New connection from 10.128.0.20
2016/04/18 09:35:17 ossec-authd: ERROR: Invalid password provided by 10.128.0.20. Closing connection.
2016/04/18 09:35:42 ossec-authd: INFO: New connection from 10.128.0.20
2016/04/18 09:35:43 ossec-authd: ERROR: Invalid password provided by 10.128.0.20. Closing connection.
2016/04/18 09:47:59 ossec-authd: INFO: New connection from 10.128.0.20
2016/04/18 09:48:00 ossec-authd: ERROR: Invalid password provided by 10.128.0.20. Closing connection.
2016/04/18 09:48:19 ossec-authd: INFO: New connection from 10.128.0.20
2016/04/18 09:48:20 ossec-authd: ERROR: Invalid password provided by 10.128.0.20. Closing connection.
You sure the password matches the one auto generated by the manager? Just tried it out on my test setup and it worked well.
Can you paste the terminal output from manager and agent?
Actually, update your manager and agent to the latest here:
https://bitbucket.org/dcid/ossec-hids/get/tip.tar.gz
Found the issue and made some changes to make sure it works now.
hi @dcid ,
Invalid password provided by
message/var/ossec/bin/ossec-authd -p 1515
got ERROR: Not compiled. Missing OpenSSL support.
i'm getting hopless...@dcid any update?
Is there a way to disable password auth that actually works? Passing -n to ossec-authd tells me i need an argument
@mvam75 using "-n" works for me. I compiled OSSEC from source on master branch and install on CentOS 7. On server, you can run ossec-authd with following command: ossec-authd -d -p 1515 -n
on server: ./ossec-authd -d p 1515 -n on clinet: ./agent-auth -m x.x.x.x
error:unable to create key. either wrong password or connection not accepted by the manager.
dose "-n" works?
-n appears to work on the server side, but clients can't actually talk to it.
My machines recently updated to ossec 3.0.0 and now I can't automatically add new agents at all. Is there any workaround for this?
INFO: Send request to manager. Waiting for reply. ERROR: Unable to create key. Either wrong password or connection not accepted by the manager
On the server:
Running /var/ossec/bin/ossec-authd -p 1515 -n
2018/08/06 07:30:29 ossec-authd: INFO: Started (pid: 27790). 2018/08/06 07:30:29 Accepting connections. No password required (not recommended) 2018/08/06 07:30:34 ossec-authd: INFO: New connection from 2018/08/06 07:30:34 ossec-authd: ERROR: Invalid request for new agent from:
I got the same problem following an upgrade to 3.0.0. I no longer have agents added automatically, resulting in a total hids protection failure. I can't find a way back to 2.9.x, so where do I go from here? As it stands, the deployment of hids protection to a large UK organisation is on its knees, and this doesn't look great.
Workaround for this:
Create /var/ossec/etc/authd.pass on the server, containing one of the random passwords it otherwise likes to create. Start the server without the -n.
Create /var/ossec/etc/authd.pass on new clients at install time containing the same password value. Specify -P /var/ossec/etc/authd.pass on the call to /var/ossec/bin/agent-auth; this is important, although it claims that's the default location it doesn't actually work unless you specify the file name.
That works -- thanks for your help!
in relation to this issue, opening a related one here.
on the server
even after installing the latest version
SIDE NOTE: why do I have to put the server external ip in the agent setup and in the agent-auth params? won't a hostname be much more convenient ?
@dcid