openHAB Remote Access: Using a Reverse Proxy

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.

Select openHAB related -> Reverse Proxy to kick-off the installation of the required Packages.

openHAB Remote Access: Reverse Proxy 1

openHAB Remote Access: Reverse Proxy 2

openHAB Remote Access: Reverse Proxy 3

 

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.

openHAB Remote Access: Reverse Proxy 4

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.

openHAB Remote Access: Reverse Proxy 5

 

openHAB Remote Access: Reverse Proxy 6

 

openHAB Remote Access: Reverse Proxy 7

 

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?

openHAB Remote Access: Reverse Proxy 8

 

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.

 

openHAB Remote Access: Reverse Proxy 9

 

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.

openHAB Remote Access: Reverse Proxy 10

 

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.

 

openHAB Remote Access: Reverse Proxy 11

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!

 

openHAB Remote Access: Reverse Proxy 12

 

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.

openHAB Remote Access: Reverse Proxy 13

 

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.

 

openHAB Remote Access: Reverse Proxy 14

 

Adding New Users

You can add or revoke users at any time with a couple of simple commands.

To add a new user:

To remove a user:

 

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.

openHAB Remote Access: Reverse Proxy 15

 

openHAB Remote Access: Reverse Proxy 16

 

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

cleanup.sh

Don’t forget to replace your_token_here with the one found in your duckdns account.

openHAB Remote Access: Reverse Proxy 17

Grant execution permissions if you haven’t.

After you have created the two scripts, you are ready to start the verification process.

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!

This Post Has 10 Comments

  1. nucutza

    Thank you ! Didn’t know about this!

  2. David C.

    Thanks! Let me know if you implement it!

  3. Triantafillos

    Thank you David! I will try it!

  4. John K

    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.,

  5. David C.

    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.

  6. David C.

    Thanks!

  7. fix

    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)

  8. David C.

    Hi Fix,

    Are you using a Dynamic DNS or just the IP?

  9. Jeremy M

    @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.

  10. M.Alonso

    Thank you very much , Very usefull. I had to leave blank in the domain setup and execute the troubleshouting to obtain the certificate.

Leave a Reply