Let’s say you want to forward only port 8123, because that is all you need forwarded for Home Assistant.
Service Name: Whatever you want
External Starting Port: 8123
External Ending Port: 8123
Internal IP Address: hassio address
Done.
If you want to forward ports 80 and 443 (not necessary if you are connecting over port 8123), you would need 2 more forwards.
You want ADD CUSTOM SERVICE
Ok. I will give that a try. Please see my updated post which includes a screenshot of the drop down menu under ‘Service Name’ - I can ignore that and only click the ‘Add Customer Service’ button correct?
Then in the custom service section, I am leaving the default TCP/UDP option selected correct?
Yes. All you really need is TCP, but TCP_UDP is fine. It will work that way too.
Ok…before I proceed with the ‘Apply’ button, do I leave this option empty by default or also fill it in with the same hassio address?
It should stay empty and ANY
Never mind…logically it would be any because who knows which device I may be using to access it. Correct?
I would only specify an IP address if I knew the device I would be accessing it from.
Haha. It’s actually more complicated than that, but yes, you just leave it ANY
I absolutely DO NOT need more complicated right now! I am barely keeping up with you right now. LOL
My problem is having a complete understanding of how the networks work and tie in together. As soon as I figure out all that logic, I think I will have a better grasp on all these things I am doing.
Quick questions…on the DuckDNS website. When I setup the ‘Current IP’ for the domain I choose, am I leaving the default that loads or the hassio address? I could have sworn I read somewhere that it needs to be the hassio address. That would make sense but before I blow things up again, I figured I would ask.
Many thanks by the way for helping me along! Appreciated more than I can express. I like having my hand held apparently…
I have no idea. I own many domains and maintain my own stuff. I don’t use DuckDNS or Hassio. From what I understand it’s pretty straightforward on hassio
I found the video again by BRUH on YouTube. It’s my public IP that goes in that box. Looks like I am cooking with gas!!!
WOOOOO!!! Thank you @flamingm0e! I could hug you right now!
I was able to get to my login screen. I feel much better than I did last night about this whole thing. Now I will be moving forward with my setup of entities. Now, so I have a better understanding…this built in LetsEncrypt process in the DuckDNS add-on does not necessarily protect me from any talented folks that really want in to my setup? It simply protects my info going back and forth between HA and my remote device when I am accessing it? Am I understanding that correctly?
I also setup a login password for another level of security. I imagine that helps deter people.
What other methods of security would you recommend so that I never have to deal with coming home and having flickering lights and/or people prying into my network and devices?
Yes.
It simply encrypts the traffic going to and from your HASS installation.
Truthfully, it is unlikely that you will have too much to worry about. Make sure you have a STRONG password, and use the http: features to aid you in making it easier at home but a little more secure from outside.
Specifically these:
- trusted_networks (Optional): List of trusted networks, consisting of IP addresses or networks, that are allowed to bypass password protection when accessing Home Assistant. It should be noted that if you use a reverse proxy, all requests to Home Assistant, regardless of source, will arrive from the reverse proxy IP address. Therefore in a reverse proxy scenario, this option should be used with extreme care.
- ip_ban_enabled (Optional): Flag indicating whether additional IP filtering is enabled. Defaults to False.
- login_attempts_threshold (Optional): Number of failed login attempt from single IP after which it will be automatically banned if ip_ban_enabled is True. Defaults to -1, meaning that no new automatic bans will be added.
Awesome! Thanks again. I will look into this right now and do some more learning. Have a great weekend and do not be surprised if I end up asking some more questions. LOL
I do like the idea of the IP ban. I saw someone else with that setup. Makes sense to only have a few attempts then block them.
No problem. I am on the forums a lot scouring for ideas for my home automation stuff, so I am glad to help out where I can.
Just getting started with Hass.io. I think I understand the motivation for duckdns and lets_encrypt.
I’m interested in building my own custom frontend using Angular with WebSockets and the REST API. My Angular App will be making all the REST calls, so it needs to authenticate with HASS for each call.
Does the REST API support JWT?
I do not want to embed my HASS api_password into my Angular app, because if I post the code to GitHub, it will be there for everyone to see. That means I need to implement my own login page that requests the user to enter the HASS password. Sure I can do that. Now I don’t want to have to enter my password every time I login, so I’d like to cache the fact that I’ve recently authenticated, and not require me to login in again until my cookie/token expires.
Options:
The Websocket API page makes refers to “access_token” being an authentication option. Is that a JWT? I couldn’t find any documentation on how to generate/acquire such an access token.
Do you have any reference for that statement? I’ve been using localStorage for other projects, and so far I was under the impression, that the localStorage is handled per domain. So e.g. Google wouldn’t be able to access the storage of my custom application using another domain. If there is a known vulernability about this I’d be glad to know about that.
I know very little about infosec, but I did find this document that explains how cross-site-scripting attacks could inject javascript into your page, which would then have access to your localStorage.
With a JWT or Oauth, I can have the token expire, so if it does get out there, it’s not valid forever.
I guess the full blown solution for adding JWT support would be to introduce an API proxy. This API would be responsible for:
With this approach:
Are you sure you don’t have to enable port forwarding on the router after starting the duckdns? I’ve just installed is as described but I still can’t access it through xxx.duckdns.org:8123