Changing hostname/domain name for remote access

Configuration
1

I’m at my wit’s end with this one.

I was setting up remote access, but need to wait until my ISP opens up the port for that to work. Meanwhile, I set up duckdns and installed dnsmasq so I can use the same address locally. I set my router to use dnsmasq for dns, as well as directly on my laptop, from which I’m accessing the Home Assistant web ui. I confirmed that dns is working from a terminal using ‘host [my-duckdns-domain-name]’, which returned the local IP address of ha.

I also setup https by adding the info from the duckdns plugin to configuration.yaml. That worked using homeassistant.local, but obviously with the security warning.

On the first run, I got to the login screen using the duckdns address. But when I logged in, it hung for a while then dropped me to a page saying it couldn’t connect. But the default https://homeassistant.local:8123 still worked. I set the “internal URL” setting at Configure ->General, and that didn’t change anything. I then set internal URL via the configuration.yaml file, and that didn’t change anything either. I went through many things at this point that I can’t even remember, but the only way I could get to the web ui is with homeassistant.local:8123, not even the IP address worked.

I added the parameters host_server and host_port to the ssl settings in configuration.yaml, setting them to the duckdns address and port 8123. And that’s what brought me here. That made the web site inaccessible by any means, and now all I have available is the console ha interface, which doesn’t seem to allow me access to the configuration.yaml for editing.

I had setup ssh, but didn’t realize it’s not accessible outside of the web ui by default, so I can’t ssh into it.

So, I need:

  1. Reference for how to use ha, can’t find anything anywhere and the --help info is not enough to figure it out.
  2. Any ideas on how to edit the configuration.yaml using only the console ha interface
  3. And once that’s taken care of, how do I make the web ui accessible by a hostname/domain name other than homeassistant.local? Instructions I’ve seen so far seem to indicate it should just work by pointing a dns record at it, possibly needing to edit internal/external URL settings. But that doesn’t work.
2

What hardware are you running on?

Do you have access to the machine via keyboard+monitor?

3

Yes, that’s how I have console access. I’m running HA in a virtual machine on a QNAS. I could create a linux VM and mount the HA drive to it, but I’m hoping for an easier route than going through an install.

4

I think nano, or if not vi/vim are installed.

5

I only have the ha interface, not a normal linux shell. If that has the ability to open and edit config files, I have no idea how.

6

from memory type login

7

Oye, it’d be nice if the help dialogue in ha mentioned that. Thanks, that got me in.

vi seems the only editor it has, more punishment! :slight_smile:

8

I remember the first time I set up BSD vi was the only editor!

1 Like
9

OK, so I was able to use my console access to edit the files. Thanks to nickrout for this.

For posterity, here’s how to get to the config files from the HA OS console prompt:

  1. type ‘login’ at the ‘ha >’ prompt and you get dumped to a traditional unix shell (ash, not bash)
  2. cd /config
  3. vi configuration.yaml
  4. For vi virgins, remember that vi has a special edit mode and view mode and makes heavy use of key commands.
  5. This quick reference for vi key commands might come in handy: https://web.mit.edu/merolish/Public/vi-ref.pdf

And that’s where you’ll find all the config files you may be familiar with from the web ui.

1 Like
10

Now, back to the original problem, how can I get the web ui to be accessible through a different hostname/domain name, assuming a proper DNS configuration?

Reiteration of the problem:

It’s worth noting that I get a strange alert from HA, about my router attempting to login:

Login attempt or request with invalid authentication from 192.168.0.1 (192.168.0.1). See the log for details.

I have no idea if that’s relevant, or why my router would be trying to login (or even know how to try).

11

Well, I’ve figured out how to reproduce the problem, but it makes no sense to me.

  1. I first got it working without ssl, which just worked once I removed the ssl settings in configuration.yaml
  2. At this point it worked with my duckdns address, the default homeassistant.local address, and just using IP address.
  3. Then I reintroduced ssl, but removed the extra settings and turned off ip_ban just in case that was causing problems (although I don’t have any file of banned ips, so I doubt that was causing any issues), so it’s just this:

http:
ssl_certificate: /ssl/fullchain.pem
ssl_key: /ssl/privkey.pem
ip_ban_enabled: false

  1. Then I did one weird thing, I added the ipv4: attribute to the duckdns add-on to point to my local ip address. I’m fairly certain the duckdns server is not being hit, and shouldn’t be, but since I have to wait for remote access until my ISP opens up the ports, I just didn’t want this to be in the way of getting something working for now.

All that enabled ssl for all three addresses. It all worked like a charm.

Once I got comfortable that everything was working, I removed the ipv4: setting from the duckdns client, allowing it to update duckdns with my external ip address. And that’s when the duckdns address stopped working, but default and ip addresses still worked.

This is totally weird. I have confirmed beyond any doubt that local devices are using dnsmasq for hostname lookups (logs confirm). I even ran “host” from the homeassistant machine and properly got the local ip address back. When attempting to log in via the duckdns address, I end up on the page that gives the homeassistant logo and reads, “Unable to connect to Home Assistant.” Checking the dnsmasq logs, there is a massive amount of lookups for the duckdns address’ ip address, and the logs indicate it returned the local ip address just fine.

I put the ipv4: setting back in, and all works again. So, I have everything working locally, but once I’m ready to open up remote access, it’ll break.

So, anyone know why an external dns server that’s not ever being queried by local machines would effect my ability to log into HA, using a local record that properly points to the local ip address?

Something is happening here that must be above my pay grade.

1 Like
12

After a lot of trial and error, I finally figured out why this wouldn’t work. First, to recap the problem:

I was trying to setup remote access in a way that I can get to the HA web ui with the same duckdns address whether I’m coming from my internal network or an external network. To do this, you first setup remote access as you normally would, setting up duckdns and a port forward from your router to the HA web ui internal IP address (look it up, directions are everywhere).

Then you install a local dns server (dnsmasq add-on) and enter you duckdns domain name there to point to the local IP address of the HA application, and make sure that either your router’s DHCP server is pointing to that dns server as primary, or the device/computer’s dns settings are overridden to point to that dns server as primary (the dnsmasq IP is the same as the HA application IP, on port 53 – the default for dns).

Problem was, when accessing the duckdns address on the local network, it would give you the login screen, but once you logged in, it drooped to the page where it says it couldn’t connect – but obviously did since that page is rendered by the HA application itself.

So what was the problem? Well, browsers these days come with default settings that use a different dns server for ssl connection lookups. So, once I logged in, the browser was trying to verify the IP address using a completely different dns server, and thus got confused. To fix this will vary by browser, but it’s usually somewhere near the proxy server settings. Here’s how I fixed it in Firefox.

Go to: Settings->Network Settings

  1. Select “No proxy”
  2. Scroll down and unselect “Enable DNS over HTTPS”
  3. Boom, local and remote work with duckdns address.
2 Likes