Login attempt or request with invalid authentication from

Configuration
1

since transitioning to 0.101.1 from 0.100 i’ve started receiving
“Login attempt or request with invalid authentication from 192.168.1.x” from ipads i use to display HADashboards … i display a couple of camera entities on each display. the video widget display is blank now. these camera displays are working fine on an HA display web page although they appear much slower on this upgrade. it’s not clear what is wrong … my ha and hadashboards (4) are on a LAN only without SSL … to access remotely i use haproxy reverse proxy which terminates SSL on the haproxy host. all my testing is done on the LAN so the haproxy isn’t involved …

# my dashboard widget declaration 
widget_type: camera
title: Front Door
entity_picture: http://192.168.1.123:8123/api/camera_proxy/camera.front_door
refresh: 5

# appdaeam conf
appdaemon: 
  disable_apps: 1
  threads: 10
  app_dir: /home/homeassistant/conf/apps
  latitude: !secret lat
  longitude: !secret long
  elevation: 30
  time_zone: America/Los_Angeles
  plugins:
    HASS:
      type: hass
      ha_url: http://192.168.1.123:8123
      cert_verify: False
      token: !secret token

hadashboard:
  dash_url: http://192.168.1.123:5050
  dash_dir: /home/homeassistant/conf/dashboards
  dash_force_compile: 1
  dash_compile_on_start: 1
  accessfile: /home/homeassistant/conf/access.log

configuration file

# authentication
  auth_providers:
    - type: legacy_api_password
      api_password: !secret http_password
    - type: homeassistant
    - type: trusted_networks
      trusted_networks:
        - 192.168.1.0/24
        - 10.8.0.0/24
        - 10.9.0.0/24
        - 192.168.5.2
        - 127.0.0.1

# load packages
  packages: !include_dir_named packages

# use yaml for lovelace
lovelace:
  mode: yaml

# custom updater and tracker
#custom_updater:

# Enables configuration UI
config:

# enable system health
system_health:

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 192.168.1.235
    - 192.168.1.0/24

  - platform: mjpeg
    name: Shack
    mjpeg_url: http://192.168.1.36:1050/mjpg/shack/video.mjpg
    verify_ssl: false
    username: !secret bi_username
    password: !secret bi_password
    authentication: basic
1 Like
2

I think that your problem is related to trusted_networks that has been disable on 0.101.

3

It’s been oddly worded but it appears more a case of moved than disabled…

The support of configuring the auth providers for API Password and Trusted Networks via the HTTP configuration is also removed. It now needs to be configured in the auth provider section

…which it looks like he’s done.

4

I have the same issue as of 0.100 when sending Telegram messages from Appdaemon with a snapshot of the camera.

This is the relevant part of the Appdaemon code

self.call_service(
    self.args["notifier_telegram"],
    title=self.args["title"],
    message=self.args["message_telegram"],
    data={
        "photo": {
            "url": "http://192.168.1.131:8123/api/camera_proxy/camera.camera_buiten",
            "caption": "Er is aangebeld",
        }
    },
)

And the config.yaml part

auth_providers:
  - type: homeassistant
  - type: trusted_networks
    trusted_networks:
      - 192.168.1.0/24

The error messages in the log

Can't send file with kwargs: {'title': 'Deurbel', 'message': 'Er is aangebeld', 'url': 'http://192.168.1.131:8123/api/camera_proxy/camera.camera_buiten', 'caption': 'Er is aangebeld'}

Status code 401 (retry #5) loading http://192.168.1.131:8123/api/camera_proxy/camera.camera_buiten

The IP of HA even gets banned

Login attempt or request with invalid authentication from 192.168.1.131
Banned IP 192.168.1.131 for too many login attempts

It seems trusted_networks is not working anymore, although the release notes are not quite clear as it also states it must be configured in the auth provider section which I already had since a couple of releases back.

The other solution to use the long live access token in the camera url is not working, as also described here.

How should we fix this?

5

It works if it’s an auth provider…

  auth_providers:
    - type: trusted_networks
      trusted_networks:
        - 127.0.0.1
        - ::1
        - 10.90.11.0/24
        - fd00::/8
        - !secret zerotier_network
        - !secret my_ipv6_network
      trusted_users:
        127.0.0.1: !secret user_id
        "::1": !secret user_id
        10.90.11.0/24: !secret user_id
        "fd00::/8": !secret user_id
        !secret trusted_ipv6: !secret user_id
        !secret zerotier_network: !secret user_id
      allow_bypass_login: true
    - type: homeassistant
6

Trusted networks is only working for login since 0.101 (I still use that and have configured it as auth provider as shown in the config I posted). You can’t use it for stuff like cameras anymore. More details here.

7

Sorry to bring this up again but since upgrading from 0.100.x to 0.101.3 I have been getting IP address 127.0.0.1 banned, thus locking me out of HA when trying to log in via HA Cloud. It seems that using the local IP address from within my network still worked.

So I tried adding the below code for use_x_forwarded_for: true and trusted_proxies: hoping that it would prevent this ban, but then I was unable to get the HA login to load (via HA Cloud) at all, only local IP access worked.

http:
  cors_allowed_origins:
    - http://192.168.0.14:8123
  ip_ban_enabled: true
  login_attempts_threshold: 3
  use_x_forwarded_for: true
  trusted_proxies:
    - 127.0.0.1

Since I’m away at work I was luckily able to talk my girlfriend through logging in and #'ing out the use_x_forwarded_for: true and trusted_proxies: lines.

Any idea why these caused HA to not work for me?

8

What is cors_allowed_origins doing?

9

I’m not sure… Its been in my config for a very long time…

10

I’ve never used that or seem any need to.

11

So in the past, I tried adding auth_providers but that seemed to cause HA to not load the GUI… not sure why as it is straight from the docs and passes the config check. Would this work to prevent the 127.0.0.1 from getting banned?

homeassistant:
  auth_providers:
    - type: trusted_networks
      trusted_networks:
        - 192.168.0.0/24
        - 127.0.0.1
    - type: homeassistant
12

Maybe Dave… 192.168.0.0 is most probably a /16 network not a /24… what IP addresses do you want to allow?

13

How do I determine a /16 vs. a /24 network? Not terminology I’m familiar with to be honest.
EDIT: I just Googled it… pretty sure /24 is correct as my subnet mask is 255.255.255.0

I just want to allow my laptop, tablet, phones etc which are all in the 192.168.0.x range. As for the 127.0.0.1, that was hoping to prevent the banning of what I assume is a Docker container or HA Cloud?

14

Ok from what you said, /24 is correct. Your config should work fine. 127.0.0.1 should mean it won’t require auth for anything on the HA machine itself.
x.x.x.x = 32 bits so a /16 means the x.x at the start is the ‘network’ a /24 means the x.x.x is the network and the remaining octet(s) are the ‘host’ so if all yours are on 192.168.0.x then /24 is correct. You should also see this as a subnet mask of 255.255.255.0 in the network settings for each device.

15

So… last night I again tried to include the code as per my post above. HA accepts the code, restarts fine and local access (within my home network using the HA server IP address) is fine, however I can’t access HA via the HA Cloud address. Take out the above code, restart = Cloud access restored. Any ideas? It’s really annoying me because I see that code as being the only way to get HA to stop banning 127.0.0.1 which subsequently blocks HA Cloud access

16

I don’t pretend to know much about any of this, but I did remember reading something on the Nabu Casa website here:

Caveats

We are currently not forwarding the IP address of the incoming request. Because of this, we are unable to support Home Assistant instances that have configured 127.0.0.1 or ::1 as trusted networks or proxies. It also means that if you use IP bans, the remote connection will be banned as a whole instead of just the address from which the incorrect passwords were entered. We are currently exploring a solution for this issue.

17

Yeah, I did read that but I guess I didn’t understand correctly that it would block my access. So basically my only option to prevent HA Cloud getting banned is to remove the IP Ban functionality completely… Surely other people would be having this issue as well? I really only started having trouble after upgrading from 0.100.3 to 0.101.3

18

I am also having this issue with HA version 0.102.3 and the AppDaemon HA Dashboard. I have a HA Dashboard running on a kindle fire tablet and I am constantly getting the Login attempt or request with invalid authentication error message with the fire tablets IP address. My appdaemon.yaml file configured almost exactly like the OP. The HA Dashboard is working and there are no issues with access, but it would be nice if my log was not getting filled up with these error message. I have tried using the Auth trusted networks and trusted users, but neither of those config setting appear to be work anymore. I would like to hear if anyone has found a work-around for this issue or if the issues is being worked on by the development team.

Thanks for the support and guidance.

19

I could never figure this issue out with HAdashboard and appdaemon … I’ve since then switched to tileboard and wow what a major major upgrade for wall mounted tablets !!! Make the switch … I can send out my config.js file if that helps

20

YEEEEEES PLEASE :slight_smile: