Is it possible to turn off or turn on the Openhab webserver from CLI? If so, how?
Why? Because in my situation, it appears to be impossible to secure the OH HTTP/HTTPS interface with authentication. I want OH running so it will do its thing and run its rules, but I dont want the UI exposed to anyone who happens to stumble upon it. It appears to be impossible to run OH behind Apache with other apps also behind Apache (see https://github.com/openhab/openhab-core/issues/150 ) Two proxies on the same box doesnt seem within my abilities.
No because the web server in integral to the operation of OH.
Then set a firewall rule to prevent access from anywhere but localhost.
Can’t run it the way you want to != impossible
What is impossible is being able to run it with a subaddress (i.e. https://my.domain.net/openhab) but it is perfectly possible and relatively easy (at least in nginx which is what I have experience with) to run it on the same proxy on a different port. In other words, you can have the same reverse proxy forward stuff going to https://my.domain.net to whatever apps you have already proxied and https://my.domain.net:8443 to openHAB.
I believe the webserver needs to be separated from OH, as others have asserted. Having a built-in webserver (and SSH server?) seems like a huge security risk. This would free OH developers to focus on support for actual home automation functionality, and let users rely on other more well established widely supported servers for HTTP/HTTPS and SSH.
This is really impossible for me, because it means a drive of over 100 miles each way. The firewall is not configurable from outside.
This bears exploring. Thanks for the suggestion. This would also resolve my SSL cert mismatch, and let me use the built-in Apache authentication. If I am able to do this with Apache, I will try to post back a how-to.
The real problem though is I don’t think it is possible to do that without completely throwing out the REST API itself and since the REST API is how ALL the UIs interact with OH as well as the Cloud Connector app and I’m sure many other internals you are looking at a complete rewrite of massive amounts of ESH, not to mention a complete redesign of the fundamental way users interact with ESH/OH. From that perspective alone I think the suggestion is a non-starter.
And I’ll note that by default the ssh for the karaf server is only accessible from localhost by default. So if someone is messing with your karaf console ssh they have already pwned your machine since it is configured to only accept connections from lo.
I’m not referring to your network firewall. I’m referring to your host-based firewall, i.e. iptables, ufw, Windows Defender Firewall, etc. Configure the host firewall to refuse all connections to the OH ports except from LAN addresses or, to be even more strict, from localhost. Since you are modifying OH and an Apache I assume you have remote access to the servers.
There used to be a tutorial in the Docs for setting up Apache reverse proxy IIRC, but it doesn’t appear to exist any longer. But in either case a how-to would be most welcome.
Others have posted their Apache and nginx configs to the forum, you might find some useful help there as well.
In my twisted mind, this only supports and underscores my argument. I have SSH all setup with certs firewall and all that happy stuff, so OH expects me to SSH to my server, then SSH again into my OH? Surely that doesnt make good sense to you, does it? And the SSH implementation… how do I know to trust it? Is it heavy iron, hardened by years of exposure to the wild wooly world of the Internet? I suspect not. I suspect this is at least one of the major reasons why its ::1 only by default.
The karaf server, is it the one Apache puts out? What version? I wonder when it was last updated? CERT lists several bulletins and at least one recent alert for Karaf. And if it is the Apache version, doesnt it further emphasize how needlessly redundant this design is, since here I am trying to figure out how to run the OH implementation of an Apache server behind my Apache server? Seems awfully Rube Goldberg to me.
It is what it is. I promised in another thread to shut up about this issue, so I need to adhere to my promise and not waste any more of your time. Thanks for your help and attention.
Yes. I don’t know why the Karaf project chose this method for administering the container but they did and lots of people seem to like it.
Why not? It doesn’t bother me. What else would you do to get into a live runtime environment inside the karaf server? It isn’t weird to me to type python to get a python interpreter so it isn’t weird to me ssh to get access to the karaf console.
Well, since it is not exposed outside the local host (unless you deliberatly configure it to) I don’t really have to trust it. It is no more or less safe than accessing any command on a server when actually logged into that server. I don’t worry about how trustworthy python is if it is only accessible on my machine and it isn’t allowed to be accesses off of the machine.
But you can look at the Karaf project and find out what they use.
Given that Karaf is an Apache project and Karaf is used all over the place the answer is probably yes. But once again, unless you tell it to, it isn’t exposed anywhere. You have to actually be logged in before you can access it. It isn’t exposed to anything but localhost. If you can’t trust localhost you have bigger problems than karaf’s ssh server.
Yes.
You would have to look at the release notes, but kai regularly updates karaf so probably a pretty recent one in not the latest in the SNAPSHOT.
In the SNAPSHOT a couple of weeks ago I think.
Karaf has nothing to do with the Apache web server. The Karaf server is an OSGI container. It is an application server. It is not a web server (which is why OH also uses Jetty for its web server). Karaf is used to manage the deplyment and orchestration of bundles of functionality. Each bundle of functionality is independent and could almost be considered an application unto itself. The container allows these different bundles to discover and work together to build up the larger application that is openHAB.
Unless you have worked with similar type systems you may not realize how huge this is and how much simpler it makes everything.
The reason why you have to set up a reverse proxy is because no one has yet volunteered to implement authentication/authorization in Jetty yet. It has nothing to do with karaf.
Maybe I didn’t read this when I setup the reverse proxy on my Apache but also I wasn’t worried about the paths because I went the other direction and put in a sub domain on a virtual host and with SNI enabled I don’t have to bother with opening other ports.
In psuedo set up for Apache I have:
virtualhost lan_IP:443
servername oh.mydomain.org
Proxy stuff with authtype basic enabled forwarded to my internal jetty (OH)
ssl cert settings
And then I can and do host other domains or sub domains with different apps for different things, proxies or whatever.
I’ve enabled letsencrypt so my Apache certificate is nicely signed and also borrowed that certificate and pushed it in to the Jetty keystore so it is happier that end as well.
It doesn’t seem so long ago that networks were thought of as a secure island but as complexity of devices and networks inceases it’s more common practice to think that every device has to maintain it’s own security as best it can so host enabled firewalls are an essential part of that. It doesn’t mean you forget about the perimeter it just gives you more work to do inside!
Everybody has differeing opinions on how to best do security mostly because everybody has different requirements but we all know the only secure computer is the one turned OFF
I finally got mine working the way I wanted, mostly. My main server is on 443, and my OH is on another port, and both are running under my letsencrypt certs being served by Apache2. My only remaining task is to tune the TLS and SSL options to eliminate the lesser strength ones. I work at a DoD site, and they have the browsers there so locked down that I cannot access my own site. It worked for a while, but then they cranked up the browser settings and now I get TLS errors.
I will work on a writeup. Thanks to all on here who have assisted me in my learning. I know that I can be an @$$ sometimes (see posts above) but I really do mean well.
For a private site this is quite a restrictive Apache configuration and should clear any outbound filters for ‘weak security’ filters:
SSLProtocol TLSv1.2
SSLCipherSuite “HIGH:!aNULL:!MD5:!3DES:!CAMELLIA:!AES128”
SSLHonorCipherOrder on
SSLCompression off
To be honest I’d be surprised if it’s those settings though that are locking you down on a DoD site unless your client device is also making weak choices. My guess (and somewhat hope for the security of DoD) would be that if you are using a non standard port (anything other than 443) then you might struggle.
Seeing as you are in a closed client environment for your site (just you and maybe a partner etc) you should also be able to rely on SNI so you can virtual host your ‘main server’ alongside OH on the same standard 443 port with different domains or just sub domains. Any recent version of Apache will do it, just treat it like you would a normal port 80 virtual host, use a different sub domain with ServerName appropriately set:
<VirtualHost *:443>
ServerName oh.mydomain.co.uk
ProxyRequests Off
<Proxy *
Order deny,allow
Allow from all
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /etc/apache2/wwwpasswd
Require user openhab
</Proxy>
ProxyPass / http://<local-OH-IP>
ProxyPassReverse / http://<local-OH-IP>
SSLEngine on
SSLProtocol TLSv1.2
SSLCipherSuite "HIGH:!aNULL:!MD5:!3DES:!CAMELLIA:!AES128"
SSLHonorCipherOrder on
SSLCompression off
....
