| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| computing:cockpit [2026/10/10 02:56] – oemb1905 | computing:cockpit [2026/10/10 03:05] (current) – oemb1905 |
|---|
| This adjusted script briefly opens up 80 every 30 days to see if the cert needs renewal. After it checks, it closes the port back up. At this point, one might realize, what value is Let's Encrypt even providing here? If 80/443 are closed and you are running everything through ssh. As I mentioned above, the addition of TLS removes browser complaints and provides an easy to remember domain for access, but/and, if I make a mistake or ufw fails, etc., then Cockpit faces the public with not only TLS, but with the location restrictions stated above. This ensures that Cockpit is triple protected: ssh tunnel, ufw, and apache locations. To access the Cockpit web interface, we first ssh into the host with the ''-D'' flag: | This adjusted script briefly opens up 80 every 30 days to see if the cert needs renewal. After it checks, it closes the port back up. At this point, one might realize, what value is Let's Encrypt even providing here? If 80/443 are closed and you are running everything through ssh. As I mentioned above, the addition of TLS removes browser complaints and provides an easy to remember domain for access, but/and, if I make a mistake or ufw fails, etc., then Cockpit faces the public with not only TLS, but with the location restrictions stated above. This ensures that Cockpit is triple protected: ssh tunnel, ufw, and apache locations. To access the Cockpit web interface, we first ssh into the host with the ''-D'' flag: |
| |
| ssh -D 8090 root@domain.com #note the 8090 because so many containers/services use 8080 | ssh -D 8090 root@domain.com |
| |
| Once you are logged in, configure your Firefox's network settings to use SOCKS5 proxy with localhost and port 8090. You can now enter domain.com into your browser and your Cockpit instance will just work. If you check from elsewhere (other IPs), it won't work because 80/443 are closed (or your IPs are not approved). It's using the reverse proxy but accessing it locally (via the ssh tunnel), which is automatically trusted by apache. If changing Firefox's network settings proves inconvenient or cumbersome, you can setup a proxy with the foxyproxy addon for Firefox: | Once you are logged in, configure your Firefox's network settings to use SOCKS5 proxy with localhost and port 8090. //Using 8090 or something non-standard is helpful as containers and/or other services might already be bound to 8080//. You can now enter domain.com into your browser and your Cockpit instance will just work. If you check from another location, it won't work because 80/443 are closed (or your IPs are not approved). It's using the reverse proxy but accessing it locally (via the ssh tunnel), which is automatically trusted by apache. If changing Firefox's network settings proves inconvenient or cumbersome, you can setup a proxy with the foxyproxy addon for Firefox: |
| |
| {{ :computing:screenshot_from_2026-03-29_13-22-21.png?direct |}} | {{ :computing:screenshot_20261009_205620.png?direct&800 |}} |
| |
| Of course, you could have skipped the apache configuration entirely and just run the ssh proxy and accessed Cockpit via localhost:9090 and/or 127.0.0.1:9090 but then you have to edit Firefox's developer settings to allow "localhost hijacking" or Firefox will get confused over which 'local' host is intended? Especially with reverse proxies, some internal web service assets will be originating from localhost (since they are behind the reverse proxy lol) and thus Firefox gets confused. There are also associated security concerns. However, if you want to avoid the apache part and just ssh with SOCKS, set the following to true: | Of course, you could have skipped the apache configuration entirely and just run the ssh proxy and accessed Cockpit via localhost:9090 and/or 127.0.0.1:9090 but then you have to edit Firefox's developer settings to allow "localhost hijacking" or Firefox will get confused over which 'local' host is intended? Especially with reverse proxies, some internal web service assets will be originating from localhost (since they are behind the reverse proxy lol) and thus Firefox gets confused. There are also associated security concerns. However, if you want to avoid the apache part and just ssh with SOCKS, set the following to true: |
| {{ :computing:screenshot_from_2026-03-29_13-28-00.png?direct |}} | {{ :computing:screenshot_from_2026-03-29_13-28-00.png?direct |}} |
| |
| Set this value to true and you can then access Cockpit via localhost:9090 without any issues. Before doing this, however, be aware of the risks/dangers of this approach. Just search "localhost hijacking" if you need to read up on it. I personally use the reverse proxy with apache, which although overkill, also results in avoiding this flag / dev mode hack. Other solutions involve binding Cockpit to a local IP and then proxying into the host and accessing via that IP:9090, or simply using the Cockpit flatpak, which connects via ssh and runs the Cockpit web socketing system internally, and even allows folks to connect to instances without Cockpit installed and get that familiar form factor: | Set this value to true and you can then access Cockpit via localhost:9090 without any issues. Before doing this, however, be aware of the risks/dangers of this approach. Just search //localhost hijacking// if you need to read up on it. I personally use the reverse proxy with apache, which although overkill, also results in avoiding this flag / dev mode hack. Other solutions involve binding Cockpit to a local IP and then proxying into the host and accessing via that IP:9090, or simply using the Cockpit flatpak, which connects via ssh and runs the Cockpit web socketing system internally, and even allows folks to connect to instances without Cockpit installed and get that familiar form factor: |
| |
| * [[https://cockpit-project.org/faq.html|Using Cockpit ]] | * [[https://cockpit-project.org/faq.html|Using Cockpit ]] |
| |
| I use the flatpak in addition to maintaining the reverse proxy method above. In my experience, the flatpak is noticeably slower than the reverse proxy via Firefox. They both work reliably, just much more spinning and refreshing needed in the flatpak. | In conclusion, this tutorial allows for secure web browser access with no browser barf or work arounds. The cert renews on schedule and briefly opens port 80 during that process. If something goes wrong, TLS is ready and secure if ufw or location packages fail. Additionally, since ssh is open by default, one can also simply use the official Cockpit flatpak. However, it's nice to not have to rely on the flatpak and this tutorial solves that. |
| |
| --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/05/10 00:29// | --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/10/10 02:57// |
