| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| computing:cockpit [2026/03/29 19:23] – oemb1905 | computing:cockpit [2026/03/30 16:49] (current) – oemb1905 |
|---|
| ------------------------------------------- | ------------------------------------------- |
| |
| This tutorial covers how to set up Cockpit on Debian. The approach here assumes that Cockpit will be installed on bare metal being used in production, with only ssh exposed. This tutorial assumes you already have a sufficiently hardened and provisioned VPS/VM w/ a LAMP stack and some associated A/AAAA records ready to go. If not, go read [[http://example.com|Apache Survival]] first and come back. If you are ready to go, then this tutorial will cover: | === Introduction === |
| | This tutorial covers how to set up Cockpit on Debian. The approach here assumes that Cockpit will be installed on bare metal being used in production, with only ssh exposed. This tutorial assumes you already have a sufficiently hardened and provisioned VPS/VM w/ a LAMP stack and some associated A/AAAA records ready to go. If not, go read [[https://wiki.haacksnetworking.org/doku.php?id=computing:apachesurvival|Apache Survival]] first and come back. If you are ready to go, then this tutorial will cover: |
| |
| * Unordered List ItemInstallation of Cockpit + Preferred Packages | * Installation of Cockpit + Preferred Packages |
| * Setup of Apache Reverse Proxy; including setup for "with" and "without" 80/443 exposed/listening | * Setup of Apache Reverse Proxy; including setup for "with" and "without" 80/443 exposed/listening |
| * Localhost w/ FoxyProxy | * Localhost w/ FoxyProxy |
| * Official Cockpit Flatpak | * Official Cockpit Flatpak |
| |
| Introduction | === Install Cockpit & Configure Apache === |
| Let's install cockpit and then create an apache virtual host for it. After that, we will cut the cert, then swap the vhost configs with the reverse proxy config. Let's enable TLS modules and headers. | Let's install cockpit and then create an apache virtual host for it. After that, we will cut the cert, then swap the vhost configs with the reverse proxy config. Let's enable TLS modules and headers. |
| |
| This instructs Cockpit's internal web socket system to trust the domain/origin and the web socket reverse proxy that we configured in apache. Restart the server or minimally restart cockpit+apache. Once they are restarted and their status healthy, navigate to ''domain.com'' in a browser and it should redirect to TLS and show the Cockpit landing page. If not, trace over the steps above and fix your work before proceeding. | This instructs Cockpit's internal web socket system to trust the domain/origin and the web socket reverse proxy that we configured in apache. Restart the server or minimally restart cockpit+apache. Once they are restarted and their status healthy, navigate to ''domain.com'' in a browser and it should redirect to TLS and show the Cockpit landing page. If not, trace over the steps above and fix your work before proceeding. |
| |
| Topic 2 - Access and Hardening | === Discussion on Access to Cockpit === |
| |
| There's a lot of debate about whether production servers that run virtualized services (VMs, containers, etc.) should be publicly exposed. The most common choice, however, is retaining ssh access and locking everything else down. That is, 80/443 will be closed. At first, this might seem counter-intuitive ... why would we close the ports for the reverse proxy we just set up? The answer is easy ... run everything through ssh! So, let's close down the host's ports: | There's a lot of debate about whether production servers that run virtualized services (VMs, containers, etc.) should be publicly exposed. Now, if you fully trust your server and Cockpit's web auth, no need to continue. For most folks, however, retaining ssh access and locking everything else down is usually the go to ... meaning that 80/443 will be closed. At first, this might seem counter-intuitive ... why would we close the ports for the reverse proxy and/or web service we just set up? The answer is easy ... run everything through ssh and access it "locally"! So, let's close down the host's ports: |
| |
| sudo apt install ufw | sudo apt install ufw |
| {{ :computing:screenshot_from_2026-03-29_13-22-21.png?direct |}} | {{ :computing:screenshot_from_2026-03-29_13-22-21.png?direct |}} |
| |
| | 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 |}} |
| | |
| | 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 ]] |
| | |
| | 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. |
| |
| --- //[[alerts@haacksnetworking.org|oemb1905]] 2025/02/15 14:32// | --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/03/29 19:23// |
