Added "keyagents" domain config option.

[HuFlungDu]

This is an extremely draft PR, more just floating the idea with some code.

Meshcentral has the "lockAgentDownload" option so you can stop people who aren't users from downloading an agent. This works great under the assumption that every user of the instance is to be given a perpetual ability to add agents to the instance. However, given meshcentral has the ability to remove users, any user who is removed can be assumed to remember the meshid they once connected to (or read it from their .msh file in the case they had set their own device up at some point when they had permission) and can now add any number of devices to your instance without being logged in, even if the "lockAgentDownload" option is set.

The thought of this option is to close that hole a bit. If the option is set, downloading an agent will now create a record in the database of that agent being downloaded, along with a random identifier for that download. The first time that agent connects and generates its nodeid, that record will be associated to the nodeid, such that if someone tries to connect a different nodeid using that same key, it will not be allowed. Additionally, when the device is removed from meshcentral, that key is also removed and can never be used to connect again. This allows one to revoke an agent's ability to be added to the instance.

What isn't done

• I probably didn't implement the key correctly, I just made a random 128 lowercase letter key. I know this project mostly uses sha384 hashes for its keys, but I'm not sure what would be the desired way to set that up here. I made it store use a 64 byte random key and store the sha384 hash in the database. Still not sure if that's correct.
• I would probably add a timeout to the key, such that if an agent doesn't connect with that key in a certain amount of time, that key is no longer accessible. This would stop someone from downloading an infinite number of agents for future use.
• Added an expirery option for agent keys.
• I would like to create an upgrade path for existing servers. My thought would be to have an option for a grace period wherein any agent that connects will be given a key and updated. All that needs to change agent side is an update to its .msh file to add the key to the connection string, but I haven't found the mechanism for that yet.
• I have added an update mechanism where a server owner can set an option in the config (keyAgentsGrace) to a date, and until that time, any agent which connects will be given a new key and the association will be locked. I'm not sure if this will work in an update from 1.1.22 to 1.1.24, since it relies on the recent changes to the console msh command, and I'm not sure whether a core upgrade or a stable core is presented first. I think it will work, but I haven't tested.
• I probably didn't follow the style guide and probably forgot a semicolon or two. It'll probably need cleaned up a bit.

The code as is is functional on a basic test instance, though I only tried it with the default configuration and using the standard windows agent, I'm not sure if it will generalize to all agents, though I believe it will since I modified everywhere it creates the .msh file on the server side.

Let me know if this seems like something meshcentral could benefit from.

[si458]

just a side note, when an agent connects to your server, meshcentral will auto create the meshgroups if they DID exist but was removed recently. you can check the function out function getMeshAutoCreate() meshagents.js line 600

what might be an idea is we have an option for the server inside config.json under settings (not domains) something like recreateDeletedMeshGroups and if its set as true it creates the groups BUT if false it then doesnt recreate the meshgroup

[HuFlungDu]

I think that's also a good idea, and very easy to implement, but it doesn't address the problem of a removed user being able to add agents to your instance if they wrote down the mesh id and you never deleted it. Which I know is considered a minor concern since it doesn't provide the user any permissions on the server, but it just rounds out the lockAgentDownload option, which is otherwise only half effective.

Other side note: Is there a logic behind what goes in domains vs settings? I saw that lockAgentDownload was in both, and since I consider this to be a companion to that option I just stuck it in both places as well, but if there's official guidance I would be interested in knowing.

[si458]

normally if the is value listed in both settings and domains, then its a case of server or domain values so a value in settings applies to all domains on your server, but a value in domains only applies to that certain domain, as you can have multiple domains (multi-tenant if you where)