Permissions needed to monitor an authorized_keys file.

[nktech1135]

Hello.
I'm trying to monitor roots authorized_keys file so i can see if ssh keys were changed.
I set up an item with the following key: vfs.file.cksum[/root/.ssh/authorized_keys]
and a trigger tell if the file changed. This is working for other files but on the authorized_keys file i get the following error on the agent log.
12466:20200616:111909.585 active check "vfs.file.cksum[/root/.ssh/authorized_keys]" is not supported: Cannot open file: [13] Permission denied
permissions on this file are set at 600 for the root user which i believe is required for ssh.
So how can i monitor this file?

Thanks.

[tim.mooney]

The 'root' user's home directory (/root) is closed to non-root users, as a default security measure. In addition, as you've mentioned, the permissions on the authorized_keys files needs to be restrictive, again as a security measure.

The zabbix agent runs as a non-privileged user by default. Again, that's the best default behavior from a security standpoint. You can override this by changing a setting in the zabbix_agentd.conf file and then modifying how zabbix-agentd is started as a service, but this opens up a wide range of potential security risks.

There are potentially multiple ways you might approach granting limited access to this file for the 'zabbix' user (or the 'zabbix' group) while continuing to run zabbix_agentd as a non-privileged user.

The first way I can think of, that allows you to continue to use the built-in item vfs.file.cksum, would be to use ACLs (see acl(5), getfacl(1), and setfacl(1)) on the /root directory, possibly the /root/.ssh directory (if needed) and the /root/.ssh/authorized_keys file. These ACLs would need to grant the 'zabbix' user (or group) read and execute on the directories and read on the file. The advantage to this approach is that you can continue to use vfs.file.chksum. The disadvantage is that it's a bit hidden/opaque. People (other sysadmins you work with) that aren't familiar with POSIX ACLs might be very confused by the "magic" that allows the non-privileged 'zabbix' user/group to access the file that has apparent permissions that wouldn't allow it.

The second way I can think of involves creating a custom item via a UserParameter and which runs some script or command via sudo. Then you add a sudo rule so that the 'zabbix' user can run the script or command with NOPASSWD. The advantage to this method is that it's a bit more obvious: anyone looking at the item configured in the Zabbix UI can see that it's a custom item and if they know how UserParameters work in Zabbix, they can follow the config on the client to figure out what command is being run. It also allows you to grant the absolute minimum access needed, since you control exactly what the command does as part of the UserParameter. The disadvantage is that you have to do a bit more setup on the client, both in the zabbix_agentd.conf or zabbix_agentd.d/*.conf and by setting up a sudoers entry that uses NOPASSWD.

There might be other ways I'm not thinking of, and as mentioned above there's the (what I think is) dangerous way of just allowing zabbix_agentd full root access to your client(s).

[nktech1135]

Thanks for the advice. I tested the acl method which works. The custom item method i'm not really familiar with at this point so i'll probably not do that for now.

[carl]

As they are public keys not private ones, as a third/fourth options suggested you could synchronise the file via cron to path and permissions for which zabbix does have access, or ofc AllowRoot=1 while using the filters in v5.