Citeren "Stuart D. Gathman" <[email protected]>:
One advantage to client certs is that it avoids weak passwords - but the client could protect their private key with a weak password.
In case of upsmon, this is a huge waste of effort. The upsmon client has very little (master) or none at all (slave) influence on the operation of the server. The worst that can happen, is that a upsmon master sets the FSD on the uspd server, triggering a power cycle of all connected devices. All a upsmon slave can do, is delay shutting down for a handful of seconds. You should not grant any other privileges to these users.
You could also assign random strong passwords to clients to avoid weak passwords.
What you need to protect, is the username/password combination for users that need more privileges on the upsd server (the ones that need to run upscmd and/or upsrw). You should *never* grant those privileges to users that run upsmon. Since we don't offer SSL in either upscmd or upsrw, these commands should only be run locally (through a secure shell for instace), where snooping passwords is not an issue. Only the administration user needs a strong password and probably be restricted to connect only through the localhost address.
Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
