This website does not serve any adverts, tracking cookies or other internet annoyances.
Tuesday 23rd April 2019
One of the largest challenges with infrastructure deployment and automation is managing and verifying the SSH server key fingerprints for your servers and devices. Each new server will have its own unique SSH fingerprint that needs to be verified and accepted before your devices (e.g. Ansible control machine, log collector) can securely connect via SSH.
Often, verifying the distributing the fingerprints is a manual process, involving connecting to machines to check and accept the fingerprint, or manually copying lines to your
~/.ssh/known_hosts file. In some cases, people also unfortunately bypass the warnings and accept the fingerprint without checking it, which fundamentally breaks the security model of SSH host authenticity checking.
I have recently solved all of these challenges by implementing a new solution for managing my saved SSH server key fingerprints (known_hosts). I'm storing a verified copy of each fingerprint centrally in a public Git repository, and I can then pull from the repository on all of my machines/devices whenever the key changes. This allows me to securely and semi-automatically distribute the fingerprints with minimal manual work required. Continue reading...
Thursday 21st March 2019
I recently decided to switch back to using my Meizu MX4 Ubuntu Edition that I originally purchased in 2015 (which is what the first article on this blog was about).
Unfortunately, Canonical decided to end development of Ubuntu Touch due to a lack of market interest, but luckily the UBports community took over development, and are running the project successfully to this day as the (soon to be at the time of writing) UBports Foundation. Continue reading...
Tuesday 26th February 2019
I recently re-deployed my entire infrastructure onto two new servers using Ansible, and as part of this I wanted to remove all stored secrets from my public-facing web servers.
Let's Encrypt certificates were no problem as they are generated on the server and can be easily replaced if needed, and I removed the need for an SSH private key for Git by just using the public repo over HTTPS.
The only secrets that posed a challenge were my Tor Hidden Service private keys, both for Onion v3 and the historic Onion v2. The impact of one of these keys breaching would be very high, since the associated hostnames are already widely known and indexed. Because of this, it would absolutely not be appropriate to store them in my Ansible playbooks Git repository, nor would it be ideal to store them locally on my Ansible control machine.
One option would be to manually upload them whenever I deployed a new server, however this goes against the complete automation that I am achieving with Ansible. Instead, I decided to not run Tor on my public web server fleet at all, and instead host the Hidden Services elsewhere, with traffic forwarded to the web server fleet securely over the internet with an Apache reverse HTTP proxy. Continue reading...
Saturday 19th January 2019
For about two years at the time of writing, my website has had a Content Security Policy in order to lock-down and restrict the locations that content such as images and stylesheets can be loaded from. I had used Apache configurations in order to set a more relaxed policy for specific pages that require it, however this solution is not ideal as it becomes challenging to manage when used with larger websites with many different pages, each requiring a different policy.
I have now developed some useful PHP code that allows me to easily set a default policy for the entire website, and then override individual parts of the policy on specific pages where it is required. I've released the code to the public domain under the Unlicense, so you are welcome to use it for your own projects! Continue reading...