Change:
description = '' Specifies the hashed password for the MQTT User. <option>hashedPassword</option> overrides <option>password</option>. <del> To generate hashed password install <literal>mkpasswd</literal> package and run <literal>mkpasswd -m sha-512</literal>. </del> <ins> To generate hashed password install <literal>mosquitto</literal> package and use <literal>mosquitto_passwd</literal>. </ins> ''; };

Discussion:
The documentation for states: I believe this is incorrect. The output of this hash function appears to be different than what is generated by and incompatible with the mosquitto daemon. At least, the mosquitto daemon seems to not accept any passwords that were configured this way. However, passwords generated with seem to work just fine. Note that this issue becomes apparent only when a separate issue, , is fixed. Without that fix, the server performs no password validation, so passwords generated with (or even ) would appear to work just fine. Apply a fix for The easiest to apply at the time of this writing is to addUse as directed to generate a hashed password and put it in your NixOS configs. Rebuild. Verify that fails for authentication reasons. Then try again using to generate your password and notice the starts to work. System: NixOS 17.03 Nix version: 1.11.8
:wave: not sure if this is important to ya'll but I recently butted up against this, because is pretty awful to use when generating the hashed password from some cli password manager (as it doesn't take stdin or stdout and so you have to deal with writing a temp file and cleaning it up & securing it & parsing it & etc). I figured there had to be a better way, and it turns out that works just fine, you just have to suffix the output with . i.e.: Let me know if ya'll think a note about this is appropriate in nixpkgs and I'll be happy to open a PR to add it. EDIT sorry for the necrobump, I just realized how old this issue is. My comment stands though, let me know if ya'll want the note.
How about this?
I don't see any indication that there's any way to use on stdin/stdout correctly.

The out-of-the-box configuration of Mosquitto will accept any password. The setting is irrelevant. I don't think these details make much difference, but I'll document them here just the same. up Mosquitto with TLS. up a user with some ACLs and a password. to connect as this user. Note that the password argument is irrelevant. The problem seems to be that the option is not specified. An effective work-around is: It seems this is expected behavior. See this matrix at: System: NixOS 17.03 (deployed with NixOps)
I don't think this fix is within the spirit of the Mosquitto project. The Mosquitto project makes it easy to get started with the service, but you are now throwing that away too. The way I would like to see it work is to have a boolean option "insecure" where true means the behavior as it was before the PR. Additionally, when the password file is not set, a helpful hint is given pointing at the insecure option with a big warning about the security implications as well as the option for setting the password file to a real secure configuration.
Sorry, I don't often get time to work on this. I'll try to leave enough information here that you can make decisions and push forward without much more iterations. I wrote some tests: And here's a default-ish NixOS config for mosquitto: And here's the result: Invocation with allowAnonymous --------------------------------- No auth PASS Unregistered user PASS Registered user, no password PASS Registered user, bad password PASS Registered user, good password PASS This is so far from my expectations that I'm inclined to treat it as a bug. Why should the NixOS configs allow the user to specify the contents of the password file when those contents will be completely ignored? Here's what it looks like when we modify the config so that the password file is actually used: Invocation with allowAnonymous --------------------------------- No auth PASS Unregistered user FAIL Registered user, no password FAIL Registered user, bad password FAIL Registered user, good password PASS This is more like what I would have expected. I believe this is not too much of an extra burden on setup. If ease of use is your primary concern, you can either turn on and have your client not specify a username and password, or just hard-code every password to .

I understand opinions may differ, and my arguments could prove unconvincing in the end. pointed out this is a breaking change, which is a very good argument against it. So here's my plan. I'll update the PR to include a new option and leave it off by default. If the value is false, you get the classic behavior as seen in the first table above. If the value is true, you get the behavior from the second table. I'd hope that one day could default to true, but just having it in the first place seems like an improvement.
just fyi, as of right now the default config is secure as no client is allowed to write or read any topic. This is due to a change in mosquitto server where an empty ACL file means no access for anyone. I stumbled over this issue after my upgrade to 19.03. For future generations, this is a setup for a server:
Ouch this last comment really saved my day -- and saved a deep dive into more detailed logs. What I like most about Nixos is how its configs are short, to the point, and sane/secure by default making a working setup. I think we should update the service definition just a bit to make it workable by default. I just can't think up the best way here -- so that it worked for new configs and didn't make any unsafe surprises for the existing old configs.
given the comment of do you think this issue can be closed?
Thanks for fixing this bug :) In my opinion the the description of the checkPasswords option is misleading. It should better be something like „Allow user authentication“. When it is not set to true, even clients using the correct password are refused (assuming the default allowAnonymous=false). I would plead for setting the default of checkPasswords to true, since this is what a new user would expect. If we don't want this to be a breaking change, it could wait till the next nixos release. A compromise would be to set checkPasswords=true whenever allowAnonymous==false. I see no usecase for both being false, it just yields an unusable setup.
the next release will have a rewritten mosquitto module () that defaults to checking passwords and not allowing anonymous logins. additionally allows omitting password checks once merged, but will still default to checking passwords.

For anyone interested, this is how a configuration for Mosquitto looks like on 21.11 with the rewritten mosquitto module: thanks to on Edit: closing this issue for now, as a lot has changed since 2017