[Nut-upsdev] Common NUT client auth setup

[Jim Klimov]

Reviving this thread a bit, I think that slowly brewing feature is close
for completion for the first coherent code drop, in branch
https://github.com/jimklimov/nut/tree/issue-3329 for issue
https://github.com/networkupstools/nut/issues/3329 as PR
https://github.com/networkupstools/nut/pull/3435 with implementations in C,
C++, Python and Perl bindings and test clients (not too idiomatic in the
latter though, piggy-backing on earlier passing of SSL/auth requirements
via envvars so far).

For kicks, I've also started a PR for WMNut at
https://github.com/networkupstools/wmnut/pull/30

I'll be largely offline for couple of weeks, so invite everyone to take a
look and give it a spin. Maybe extend NUT-Monitor GUI with that :)

Jim


On Tue, Mar 17, 2026, 09:06 Jim Klimov <jimklimov+nut at gmail.com> wrote:

> To alleviate the fears and defuse the FUD, none of this is going to
> suddenly become mandatory :)
>
> Looking at git, the SSL support generally is in-tree since before 2010
> (SVN import); NSS and certificate validation since 2011 or so. Did not
> become in any way mandatory for over 15 years, and adding another way to
> configure it (or at all use it in a non-default manner, in some NUT
> clients) should not change that.
>
> What I think is, that specifically lack of holistic support for this among
> default NUT clients is what could have blocked adoption of such setup,
> should anyone have wanted it ("hey, I can uber-protect my upsd-upsmon
> comms, but now I can't query with upsc!") So this effort is really about
> tying up loose threads that are already there, and finishing incomplete
> code.
>
> Specifically in the NUT use-case, for client code dealing with shutdown
> during a site-wide outage (e.g. someone's `upssched` script looking via
> `upsc` how bad the battery charge is instead of just letting `upsmon` open
> the Kingston valves), I think relying on actively networked authentication
> is a no-go, everything it needs at least in this situation should be within
> the box (maybe cached in some kerberos client, but not relying on
> back-and-forth with a powered-off remote server through a powered-off
> switch) :)
>
> Jim
>
>
> On Mon, Mar 16, 2026 at 9:43 PM Greg Troxel via Nut-upsdev <
> nut-upsdev at alioth-lists.debian.net> wrote:
>
>> Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes:
>>
>> > Well, regarding features I propose to pass via some `nutauth.conf`
>> files,
>> > this is about using settings that are already available in (mostly)
>> > `upsmon.conf` for the client side, varying based on whether the build
>> uses
>> > an NSS or OpenSSL backend.
>> > This partially mirrors the server side settings for `upsd.conf`.
>> >
>> > Ability for client auth via certs is in the tree (for NSS at least) for
>> a
>> > long time, but only upsmon had the endpoints attached to configuration
>> > options and calls made into `libupsclient`.
>> >
>> > I believe it originated from the fact that NUT reads like those with
>> `upsc`
>> > are inherently anonymous (maybe something can/should be done about that
>> > too/instead), so sites that want to use SSL to protect their engineering
>> > network from any sort of revealing their hardware and its state to
>> > unpermitted clients, would use CERTVERIFY to only allow the channel for
>> > whatever use (including auth/anon in the layer above that, before it
>> comes
>> > to that) to programs that have the correct client cert. Probably this
>> > implies some sort of private/corporate CA.
>>
>> I think we should step back and ask what the requirement is, and then
>> think about how to meet it and how that solution would go over with
>> users.
>>
>> I can see a "want to restrict commands to authorized users".  One can do
>> that with
>>
>>   client certs
>>   username/password
>>   SASL in general, perhaps openidconnect
>>   kerberos/gssapi
>>   etc.
>>
>> If you look at email, I am aware of very little use of client certs.
>>
>>
>> I hink it's a huge and incorrect leap to go from "want to control access
>> to upsc" to "we should use client certs".
>>
>> > Program-specific setup of crypto stuff is common in the web server
>> world I
>> > had a lot of experience with, whether it is Apache, or Nginx, or one of
>> > many Java web-app servers. These typically configure the trusted
>> credential
>> > locations (cert with public key and CA chain, private key, possibly the
>> > generally-trusted corporate CA to issue requests to nearby servers) and
>> do
>> > not use a system-wide location (or at best fall back to using it if the
>> > dedicated store lacks some info). It is similar with CI systems that can
>> > store such credentials and let them be used per remote system they use
>> (and
>> > trust) for a particular job; a neighboring job or a different run of
>> this
>> > one should not necessarily have access to that system if it is not
>> allowed
>> > to use the credential (e.g. to avoid tests aimed at one SUT to bombard
>> an
>> > unrelated system by mistake).
>>
>> A good argument for credentials of some sort, not for client certs in
>> particular.
>>
>> > I think the NUT approach is somewhat modeled after those examples, like
>> a
>> > web server and potentially trusted/trusting clients constrained to a
>> small
>> > population with access given on a need-to-know basis (perhaps NOT
>> trusting
>> > servers/clients from corporate-wide or world-wide public CA is the
>> point of
>> > an engineering network setup with its own CA for equipment like
>> networked
>> > UPSes, NMCs, ILOMs and stuff like that). I'm not a regular sysadmin
>> > anymore, but back in the days I did set up eng networks like that for
>> > dayjob and its customers, so would have been a prime user for this
>> feature.
>>
>> Wanting to use PKI but only trust your own CI is a particular approach
>> that some would want.  That's fine.  But it's a leap to think that
>> anyone who wants any access control wants to run a private CA.
>>
>> > I agree that building a binary with multiple SSL backend support is not
>> > likely to find real users, other than CI runners that can test all those
>> > code paths in one build... which in itself is not too bad a reason,
>> would
>> > probably shave a few hours off the build matrix :)
>>
>> except that it wouldn't be testing what users actually build and run.
>>
>> _______________________________________________
>> Nut-upsdev mailing list
>> Nut-upsdev at alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20260701/a98cfe73/attachment.htm>