Let’s Encrypt was officially released to the open public today. That means the Internet can finally get free, trusted SSL/TLS certificates. This quick guide shows how to set up Let’s Encrypt with auto-renewal through a cronjob — using the simp_le client, an alternative client developed by one of the same authors who develop the official client.
Many of us developers or system administrators use OpenSSH’s public key authentication (aka password-less login) on a daily basis. The mechanism works based on public key cryptography: By adding a RSA/DSA public key to the authorized_keys file, the user with the matching private key can login without a password. The mechanism works great for a couple of hundred, thousands and even 100k thousand users (tested, login takes ~2sec).
But what if there are more keypairs, say, a million users, or a more flexible approach is desired? Maybe with an LDAP or a database backend? Think of GitHub and how they do their ssh firstname.lastname@example.org ... login! This blog post shows you how to do that by patching OpenSSH’s AuthorizedKeysCommand option to support an additional fingerprint argument.
Every system administrator, most programmers and countless of command line surfing Linux/Mac users use it every day without thinking twice. Hitting the tab key twice, [TAB][TAB], has become the most common thing in the world. Bash completion is the magic behind the tab key. It’s easy to use, but it’s a pain to write. This tiny post demonstrates how to write scripts for bash completion, with sub-commands and dynamic parameters. A working script is embedded in my open source file sync software Syncany.
These days, ISPs are often forced to block the access to certain sites, because their government considers these sites dangerous and/or illegal. While one could certainly discuss the usefulness of such measures in great detail, this tiny post focuses on the more interesting subject of how to circumvent these blockages. It’s not a lenghty post, and it doesn’t show all the ways there are, but I’ll show two simple ways to circumvent Internet non-DNS-based filters.
The Domain Name System (DNS) is one of the fundamental services of the Internet. By resolving domain names to IP addresses, it makes routing of IP packets possible and thereby lets browsers and other clients connect to remote servers using all kinds of protocols. By blindly connecting to the IP address returned by the DNS server, however, users put a lot of trust into DNS, because by default, DNS responses are not validated or verified.
In this blog post, I’d like to demonstrate how to easily set up a DNS server that allows you to easily forge certain entries manually — thereby allowing you to either block certain domains from your network or to pretend that you are a certain website. This scenario is commonly referred to as DNS forgery or DNS spoofing.
Capturing HTTP and HTTPS traffic on your own machine is quite simple: Using tools like Wireshark or Firebug, sniffing the local connections is only a matter of seconds. Capturing and/or altering the HTTP/HTTPS traffic of other machines in your network (such as your smartphone or other laptops) on the other hand is not so easy. Especially sniffing into SSL-secured HTTPS-connections seems impossible at first. Using mitmproxy, however, makes this possible in a very easy and straight forward way.
This small tutorial shows how to use mitmproxy to transparently sniff into and alter (!) HTTPS connections of your phone or other devices in your network.
I use rsnapshot to backup all of my data to my HTPC and home server (the home partition, office documents and the root file system). While rsnapshot is not as shiny as other backup tools, it is very flexible and effective: rsnapshot is based on rsync and makes hardlink-based backups (like cp -al), i.e. backups that point to the same inode on the disk if a file in consecutive backups is identical (much like SIS in deduplication).
However, rsnapshot is meant to be triggered by cronjobs and is built for always-on server machines rather than for lid-open-lid-close-type machines like laptops: That means that rsnapshot must be scheduled to run at a certain time (no retries!) and is not prone sudden system shutdowns. Furthermore, it does not detect failures and simply leaves unfinished backups as if they were complete. That in turn leads to more disk space being used for the backups, because the last complete backup is not really complete.
I wrote a little helper script to fix exactly this behavior: rsnapshot-once makes sure that (1) rsnapshot is only called if a backup is necessary (once every 24h for ‘daily’, once ever 7 days for ‘weekly’, …) even if rsnapshot-once is called multiple times, and (2) that crashed/interrupted backup runs are rolled-back before starting a new backup run.
I recently built myself a new HTPC. It’s controlled with a Medion X10 remote control using LIRC. For some reason, LIRC doesn’t realize when the USB dongle for my remote control is reconnected (unplug USB, plug it back in). This blog posts demonstrates how to easily fix this using a udev rule. I originally posted this on the XBMC forum.
I recently built myself a new and shiny HTPC for my living room, and because it took lots of time researching the right components, I’d like to share my experiences. I published this post first on the XBMC forum a couple of days ago. Feel free to comment either here or there. Lots of pictures in the post!
Many of the well known websites determine your location based on your IP address and restrict their content or functionalities based on the country you’re in. Some examples are Gmail (Germans get only @googlemail.com-addresses, legal reasons), YouTube (content is restricted by the GEMA), and Pandora (limited to US citizens) to name only a few. To circumvent these restrictions, being able to quickly get an IP address outside of your own country is most helpful.
To do exactly that I wrote a little script that will start your very own US proxy server in one minute using Amazon EC2. In combination with browser plug-ins such as FoxyProxy, the script enables you to route all your web traffic through a proxy on an Amazon-owned machine — with an IP address in the US, Ireland, Singapore, Tokyo or Sao Paulo (location of Amazon data centers).