If you are using openHAB as your Home Automation Controller with the default configuration, you might be overlooking a pretty big point. Accessing your Smart Home from the outside world its a huge risk, but implementing an openHAB reverse proxy can help you overcome it.
Needless to say, that your home automation exposed to the world can present a pretty obvious security breach and today we are going to solve that problem.
What are we Trying to Solve Here?
Let’s get this out of the way as soon as possible.
There are two main reasons to implement an openHAB reverse proxy.
- By default, the web server that comes with openHAB is not password protected. Using a reverse proxy gives you the possibility to implement authentication.
- The other security concern is that the openHAB remote access by default doesn’t use any type of encryption. A reverse proxy won’t only add password protection it can also add SSL encryption.
Now that we know why let’s get to the how.
Get yourself a Dynamic DNS
The first step is to get yourself a Dynamic DNS. Most of the ISP’s don’t assign you a static IP, instead, they give you a dynamic one that can change at any moment.
If this happens to you while you are away, and trust me, it will, you will lose the access to your home automation system and the worst part of all…You could have avoided it.
Really? How?
The easiest solution to this problem is getting a Dynamic DNS, which is free and takes 10 minutes to create.
And…What is Dynamic DNS you might be wondering…or maybe not.
I am going to tell you anyway.
A dynamic DNS is a service that points to your current IP and provides you the means to update it when it changes, automatically of course.
Using a dynamic DNS for your Raspberry Pi, you will always be able to remote to your openHAB server.
There are many services you can use, my favorite one and the one I use is Duckdns. It is fast, reliable and free, I love free stuff…
Check Setting up a dynamic DNS provider on a raspberry pi 3 for a detailed installation guide.
openHAB Reverse Proxy: Installing Required Packages
The process of getting openHAB Remote Access using a Reverse Proxy is automated through the openHABian-Config tool, so let’s get started.
Start by doing SSH into your Raspberry Pi and opening the openhabian-config Tool.
1 |
sudo openhabian-config |
Select openHAB related -> Reverse Proxy to kick-off the installation of the required Packages.
Assign a User and Password to Access openHAB Remotely
The next life-changing decision that we are going to make is the user and password to access openHAB remotely.
You are going to hit yes…this tutorial would be pretty pointless otherwise.
The script will ask you to chose a username and a password but don’t worry, you will be able to add additional users later if you need to.
Give yourself a pat on the back, you are one step further on the fortification process. At this point, your openHAB is already password protected.
openHAB Reverse Proxy: Adding SSL Encryption
The other security concern that we want to address here is the communication in plain text.
If you use the default web server provided by openHAB (over http), people in your network could intercept and manipulate the commands that you send and receive from your Home Automation System.
This might not be a concern in most environments but I bet you connect to public wifis every once in a while…
Implementing SSL to communicate with your home automation server is a must and the openHAB reverse proxy can accommodate that.
If you want to know more about SSL you should have a look at the Beginner’s Guide to SSL. It covers the topic in depth and it is an interesting reading.
A bit of a Background about SSL Certificates…
Prior to 2016, before Let’s Encrypt rolled out, if you wanted a certification authority to issue an SSL certificate, you would have to through some serious money into it.
This was an obvious drawback, and in many cases, paying 200 bucks to implement SSL was really not justified for most sites.
What happened then? Well, people would create their own certificates.
In principle this is fine, the communication is still encrypted even if it is a self-signed certificate.
What is the issue then?
Damn right! fake certificates! Basically, anyone could generate a self-signed certificate so there is no way to know that the person/entity you are communicating with is who they claim to be. For this reason, most browsers basically flag as a security threat any self-signed certificate.
Bear trespassing was a big issue for websites on a budget until Let’s Encrypt came around.
Let’s Encrypt is a certificate authority that verifies and issues SSL certificates for free. These certificates are trusted by all the major browsers.
This has revolutionized the internet, there is no excuse anymore to use HTTPS.
Now seriously…Let’s add SSL Encryption
OK…I have gotten carried away…let’s get back into the process…
The next screen on display asks you if you want to secure the connection with SSL and unless you haven’t learned anything about the deadly effects of not doing so, you may want to hit yes here.
If you put a domain name or a Dynamic DNS, the script will request a Let’s encrypt certificate for you by default.
If you only have an IP you will have to go with a self-signed certificate and leave yourself at the mercy of trespassing bears.
Once all the details are provided, openHAB will ask you to confirm and move forward. The screenshot already says so but make sure that you open ports 80 and 443 before you proceed!
On this step, the script will try to get you a Let’s Encrypt certificate issued, but first, the authority has to verify that you own the domain (due to the whole issue with the bears impersonating your mom).
There is a number of ways to do this verification, HTTP-01 being the default one.
And voila! your openHAB reverse proxy with password authentication and SSL encryption is up and running.
There might be issues with the verification challenge if you use a Duckdns domain. If the process fails, there is still hope, go over to the troubleshooting section, I have a solution for you.
Adding New Users
You can add or revoke users at any time with a couple of simple commands.
To add a new user:
1 |
sudo htpasswd /etc/nginx/.htpasswd {username} |
To remove a user:
1 |
sudo htpasswd -D /etc/nginx/.htpasswd {username} |
Conclusion
Using an openHAB reverse proxy is just one of many ways to get openHAB remote access, it is simple, versatile and fairly secure.
I hope you found what you were looking for. If you want to help other people find this content please share the post!
What do you plan to use your remote access for?
openHAB Reverse Proxy: Troubleshooting
You made it all the way till the end but the domain verification failed…don’t panic yet.
if you see a bunch of errors on the terminal that look like the image below followed by Operation Failed!
Obviously, something didn’t go quite well here.
If you are using duckdns like me, you are likely to run into a similar issue.
The HTTP-01 method to verify the domain and obtain the Let’s Encrypt certificate failed.
If that is the case, no worries, DuckDNS happens to have an API to use DNS-01 verification and I am going to show you how to do it.
Btw, I found the original solution on this thread so all the credit goes to jmorahan, a community leader in the Let’s encrypt forum.
First, go to your home directory and create the following two shell scripts.
auth.sh
1 2 3 |
#!/bin/bash DUCKDNS_TOKEN="your_token_here" [[ "$(curl -s "https://www.duckdns.org/update?domains=${CERTBOT_DOMAIN%.duckdns.org}&token=${DUCKDNS_TOKEN}&txt=${CERTBOT_VALIDATION}")" = "OK" ]] |
cleanup.sh
1 2 3 |
#!/bin/bash DUCKDNS_TOKEN="your_token_here" [[ "$(curl -s "https://www.duckdns.org/update?domains=${CERTBOT_DOMAIN%.duckdns.org}&token=${DUCKDNS_TOKEN}&txt=${CERTBOT_VALIDATION}&clear=true")" = "OK" ]] |
Don’t forget to replace your_token_here with the one found in your duckdns account.
Grant execution permissions if you haven’t.
1 |
chmod +x auth.sh cleanup.sh |
After you have created the two scripts, you are ready to start the verification process.
1 |
sudo certbot certonly --manual --preferred-challenges dns --manual-auth-hook ./auth.sh --manual-cleanup-hook ./cleanup.sh |
This time it should finish correctly.
You have generated the SSL certificate but the Nginx server doesn’t know where to find it yet.
You could update the config manually but since we started using the script, let’s finish with it.
Launch the openhabian-config tool again and follow the steps until you reach the part where it failed earlier.
This time, the process will find that you already have a certificate and it will ask you if you want to use it (Yes, You want)
That’s it, the problem should be fixed now.
Enjoy!
Thank you ! Didn’t know about this!
Thanks! Let me know if you implement it!
Thank you David! I will try it!
This was very helpful, thank you.
There seems to be a bug in the latest openhabian install, that doesn’t actually create the .htpasswd file, as the -c is out of order. I’m not 100% sure how to file that or patch that. I’ll give that a try.,
Hey John!
Yeah I noticed that after the latest upgrade. I just did passwd openhabian to do it manually.
Let me know if it works for u.
Thanks!
been trying this, didnt work
i get the following:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Unable to find manual-auth-hook command /duckdns/auth.sh in the PATH.
(PATH is /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)
Hi Fix,
Are you using a Dynamic DNS or just the IP?
@fix
Make sure the auth.sh and cleanup.sh files are copied to /usr/bin and have execute permission for all.
Also, it is better to run the certbot script as below with explicit paths to these files i.e.:
# sudo certbot certonly –manual –preferred-challenges dns –manual-auth-hook /usr/bin/auth.sh –manual-cleanup-hook /usr/bin/cleanup.sh
This will ensure that the /etc/letsencrypt/renewal/.duckdns.org.conf file gets created/updated with the correct paths, otherwise you might also find that the auto-renew service fails when it tries to renew the certificate as it will be unable to find the files.
Thank you very much , Very usefull. I had to leave blank in the domain setup and execute the troubleshouting to obtain the certificate.