You can encrypt the cleartext key in Agent, or on Server, thats OK.
Or you can only encrypt the key on one side, thats also OK.

Yes, this is what I found myself with the three different tests, and this is why I said that from the documentation I wasn't able to understand that you can have all the combination, since for the clear text on the agent side there is the field SharedSecret

 
Regards,
Marco

You can encrypt the cleartext key in Agent, or on Server, thats OK.
Or you can only encrypt the key on one side, thats also OK.

Since encryption is a reversable process, as long as both parties can get the cleartext key (either have it input directly, or decrypt it when provided as encrypted using nxencpasswd), then communication can happen.

After both parties have the cleartext key, they can use hashing crypto functions to assure that communication is authenticated and secured.

I hope that better explains it

Maybe its best to exactly describe a scenario that you think should not work, and we can see whats happening

In which case should communication not be possible?

As I posted above, even if you put a secret that is a hash itself into the configs, NetXMS doesnt treat it as a hash, but as a clear-text shared secret.

n your example 2, its actually the same, but the shared secret '01b307acba4f54f55aafc33bb06bbbf6ca803e9a' is hashed using SHA1.
That means, that while you input a shared secret that is theoretically a SHA1 hash in itself, Agent and server still hashed it.

According to documentation I understand that I have to put encrypted value (with nxencpasswd) into the EncryptedSharedSecret parameter but in my 2nd and 3rd example I didn't encrypt anything:

https://wiki.netxms.org/wiki/Agent_Configuration_File
EncryptedSharedSecret
Agent's shared secret used for remote peer authentication, encrypted using "nxencpasswd -a". If RequireAuthentication set to no, this parameter has no effect.

I'm aware that technically I can just compare the two values and if they don't match I can try to decrypt one then check again if they match (and so on...), but honestly to me doesn't seems so clear reading the doc, this is the reason for the question

Regards,
Marco

As I posted above, even if you put a secret that is a hash itself into the configs, NetXMS doesnt treat it as a hash, but as a clear-text shared secret.

n your example 2, its actually the same, but the shared secret '01b307acba4f54f55aafc33bb06bbbf6ca803e9a' is hashed using SHA1.
That means, that while you input a shared secret that is theoretically a SHA1 hash in itself, Agent and server still hashed it.

I'm still not understanding

@tomaskir said in Agent authentication:

You dont put a hash into the config, you put the shared secret in there.
The agent and server then hash it internally to communicate.

my point is that I'm able to successfully communicate with the agent in all the three cases and, as per your explanation, sounds differently:

@tomaskir said in Agent authentication:

Communication would not be possible if both sides only knew the hash, thats not how cryptography works.
Both sides need to know the clear-text secret in order to create hashes and validate the payload.

and I should'n be able to communicate in all cases I shown.

Regards,
Marco

So in your example 1, agent hashed '1234567890' into a SHA1 hash, sent data to server.
Server checked data by checking if its configured secret matches the SHA1 hash.

In your example 2, its actually the same, but the shared secret '01b307acba4f54f55aafc33bb06bbbf6ca803e9a' is hashed using SHA1.
That means, that while you input a shared secret that is theoretically a SHA1 hash in itself, Agent and server still hashed it.

Communication would not be possible if both sides only knew the hash, thats not how cryptography works.
Both sides need to know the clear-text secret in order to create hashes and validate the payload.

In case 3, you input an encrypted shared key.
Agent decrypts it, then hashes the cleartext value and sends data to server.
Server also decrypts the shared key, and again checks if the hash of the received data matches its cleartext shared secret.

The encryption only serves the purpose of both parties not exposing the shared secret directly in cleartext in configuration files / database.