Oh god… And I thought our internal UI framework was bad… 
1 Like
It’s MVVM, it’s literally the best standard you can have for UI development… That’s how core continues to run without the UI. The problem with MVVM is that it’s extremely complicated, but you can replace the UI with anything. 
2 Likes
why this setting got available under condition of having new ssh add-ons then?
something doesn’t click here.
1 Like
For me the command:
ha resolution check options --enabled=false addon_pwned
didn’t work (also after a HA reboot), both notifications still reappear.
Also HA core needs to be at latest version?
| Version | core-2021.2.3 |
|---|---|
| Installation Type | Home Assistant OS |
| Development | false |
| Supervisor | true |
| Docker | true |
| Virtual Environment | false |
| Python Version | 3.8.7 |
| Operating System Family | Linux |
| Operating System Version | 5.4.99 |
| CPU Architecture | x86_64 |
Home Assistant Supervisor
| Host Operating System | Home Assistant OS 5.12 |
|---|---|
| Update Channel | stable |
| Supervisor Version | supervisor-2021.03.6 |
| Docker Version | 19.03.13 |
| Disk Total | 30.8 GB |
| Disk Used | 7.9 GB |
| Healthy | true |
| Supported | true |
| Board | ova |
| Supervisor API | ok |
| Version API | ok |
| Installed Add-ons | Samba share (9.3.1), Terminal & SSH (9.1.0), deCONZ (6.7.2), Duck DNS (1.12.5) |
All the custom commands for the HA CLI are “obscure”. It’s a custom CLI.
It’s literally been this way since day 1, but now it’s a problem? Give me a break.
Did you dismiss the notifications or just restart?
All I’m trying to say is you guys are inconsistent in provided information.
cogneati said it requires newer ssh addons whivh might mean that developers listen to us and working hard recently on disable option.
you are saying opposite - this is supervisor setting available from beginning. So it was possible to disable it for days but devs left us discussing about that so long giving no solution till today?
The command needs to be built into the ssh addon… so update your SSH addon… that’s all he was saying.
No you’re not understanding.
The api didn’t exist in the supervisor. It was added in 2021.3.6.
The ssh addons don’t know that the supervisor added a new api call. So, that was added to the 2 SSH addons.
In order to make the calls in SSH, you need the latest SSH addons.
2 Likes
If you can figure out another way to get to the console on your raspberry pi and run the command, I’m all ears.
It’s an API under the hood so I guess one could write an addon to do it
1 Like
My results using:
- Home Assistant Supervised 2021.3.4 on Debian
- SSH services hosted by Debian (not as an Add-on).
- Supervisor 2021.3.6
- Connected via ssh and executed:
ha resolution check options addon_pwned --enabled=false
- Restarted Supervisor.
- Checked Supervisor’s log; Warning reports the addon_pwned check is skipped.
- The persistent notification warning me about Node-Red Add-on’s password is absent.
Seems to work as advertised. 
5 Likes
Thanks for confirming
Can I please be pointed to the right location if I want let’s say to change my mqtt password?
It seems that if I “just” change the password in the mosquitto addon everything stops working for e.g. OZW… although that does not use a password!?
Is there any guidance on how to act when a password should be changed and where to look at possible “usage” of the passwords in homassistant? Addons? Users? People?
Thanks…
Mosquitto broker is easy. You can have no user and password in the config at all, so it would look like this:
logins: []
anonymous: false
customize:
active: false
folder: mosquitto
certfile: fullchain.pem
keyfile: privkey.pem
require_certificate: false
Then go to configuration > users in your UI.
Add a new user. You can call it whatever you want, and it does not need to be admin. Then for the username and password, enter the same mqtt credentials you were using in the add-on configuration. Save the user, and restart the Mosquitto add-on.
Now your add-on passes the Pwned test, because there is nothing to check. The Mosquitto broker add-on will use the list of HA users. Any of them are valid credentials for connecting to the broker, and you don’t need to change the configuration on all your devices.
Sorry, I have read it 3 times and I do not get it 
So I have the mosquitto addon:
logins:
- username: mqtt
password: mqtt
anonymous: false
customize:
active: false
folder: mosquitto
certfile: fullchain.pem
keyfile: privkey.pem
require_certificate: false
Of which I use the login credentials for devices to “publish” mqtt stuff (esphome/tasmota/etc.) to the mqtt server (mosquitto addon on port 1883 with user/pass - mqtt/mqtt). You say I can delete the username and password from the addon!? How will that keep working?
I had a user in Link to Users – My Home Assistant that I deleted (mqtt/mqtt) because I thought I did not use it anymore… (don’t know why I ever created it).
then you say:
But how and what will my mosquitto addon will user the list of HA users? Do you mean it will just use “any” users of homeassistant in mosquitto? Like for example user/pass dfsdfsdggsrt/werwerwer@#4 ?
And then I need to reconfigure al my devices to use dfsdfsdggsrt/werwerwer@#4 on port 1883 to mosquitto?
And what is that user in homeassistant then for?
Sorry, think I am not getting it, or thinking too complex or whatever 
It is built into the add-on. The add-on checks against the list of HA users.
Get rid of this:
logins:
- username: mqtt
password: mqtt
And whatever username and password you had there, add it as an HA user.
Thank you
So it’s not like the disabling addon_pwned has been added, but ha command has been extended with resolution option. Now it makes sense.
Ok, but what if I add mqtt/mqtt as an ha user? that would be FAR MORE insecure than in only the addon!? The addon is only open on 1883 LOCAL and my homeassistant is connected to the internet (via nabu)!?
EDIT: To be clear, I do not care if mqtt has no password, that is why I added mqtt/mqtt…?
That kind of touches on the whole point. “It’s only local” is not a great excuse. Yes, we can all point to this one thing or that, but in general something unique is better to have started with in the first place.
One option would be to enable MFA for this “mqtt/mqtt” user and then suddenly it is very secure.
A better option would be to change it, and change it on your mqtt clients, AND enable MFA. It just depends on how much work that would be for you.