For some reason, all of a sudden, I have been getting Login attempt failed from 192.168.86.1 from devices on my home network, and when that occurs, I am locked out of my frontend permanently, until I delete the entire storage folder and redo everything. I have done this probably five times this evening. I have tried trusted_networks
trusted_networks
192.169.86.0/24
I have enabled and disabled legacy api. I am not sure what is causing this issue, but I would love to solve it. I didn’t change anything before this start occur, so not sure what I can do to walk back the issues. I am on a manual installation on .81.6
i was looking in /home/homeassistant/.config? Do you mean the directory with the configuration.yaml? On my instance, thats in /home/homeassistant/.homeassistant, but either way, no ip jail in that directory either
Oops fat fingered it in the OP, it is 168 and is 168 in the configuration.yaml as well. I just remembered that I am in the process of migrating to a NUC from a Pi, and I spun the NUC up and ran my HASS instance from the NUC about a week or so ago. The first time the login went haywire was when I was using a computer I hadn’t used since my NUC run (I’m back on the Pi instance). Would that have caused the issue, even though I am accessing via duckdns?
I don’t think so… are you using a reverse proxy?
I used to get my ‘localhost’ locked out all the time till I had a trusted_proxy set but it doesn’t seem like that’s your issue here. I’ve seen ssh shit itself when you do that as it doesn’t update the key for the connection (on a mac anyway) but not with a web address… You’re using ssl as well as duckdns?
Can you specify " I am locked out of my frontend permanently"?
You can access front end but cannot login or some other error?
I not sure but if accessing through duckdns I would expect your IP not match trusted network IP, especially without use-x-forward-for set. But in this case I would expect you get a login screen unless you disable this somehow.
So unless I clear the . storage, when I try and login, I get the failed attempt notification. After that notification, I can’t login anymore, and I get unable to connect to home assistant.
Why would x-forward trigger now, without any update?
Not sure, just not clear if you get login screen but cannot login or nothing. I provided that as possibility to latter.
Authentication related items are in .storage deleting this I think would provide at least short term access.
What Auth providers have you enabled in configuration.yaml?
Honestly, in these instances it is easier to do default install and get frontend working, then enable components in groups or 1by1. Otherwise this will just drag on. This quickly verifies if HA setting or networking is cause then helps you quickly verify full install setup properly.
The only provider I have enabled in the yaml is legacy_api, and I believe i disabled that. However, legacy API is still provided as an option at the login screen, along with user and trusted networks (which never works). I have had this install working for months and months, and I had no change to the system (aside from trying migrate over to my NUC)
Verify default install works and allow login, then slowly enable components
OR
enable (1) auth provider of your choosing; homeassistant (recommended) or legacy_api. resart and attempt login
If you try #2 without success, #1 will 100% work and is strongly recommended.
actually it sound like your current install has no user set. I would guess that deleting .storage may clear any configured user for “homeasstant” auth and you say api_password was disabled so I think no user exist. sound like you try to use trusted_network auth but as I stated earlier, I think you need x_forward_for and trusted_proxies set to get this working correctly if connecting through WAN (duckdns). Its a little much to guess over web so it simpler you try #1 or #2 to get install working. After that you may make changes with knowledge of what is and not working. Currently anything you do is guess and create more doubt. #1 or #2 remove all doubt. Really #1 remove all doubt but #2 possibly may work and quick to try so why not.