If you’d like to have a simple solution for managing all the secrets you’re using in your Ansible Playbooks, keep reading on. Bitwarden’s Secrets Manager provides an Ansible collection, which makes it very easy to use this particular Secrets Manager in Ansible Playbooks. I’ll show you how to set up a free Secrets Manager account in Bitwarden. Then I’ll walk you through the setup in an example Ansible Playbook.

YouTube Video version

I’ve also recorded a video version of this article. If you prefer a video, you can find it here.

Secrets Manager for Homelab

For a few years, I’ve been managing the configuration of a bunch of self-hosted services using Ansible Playbooks. Each playbook needed at least one secret — the sudo password. Many of them needed to manage more (e.g. SMTP credentials for email notifications). Because I’ve always been paranoid about security, I stored most of those secrets in Ansible Vault, the password for which is stored in only one location — my memory. Therefore, each time I ran any of those playbooks, I’d have to enter two passwords interactively: the sudo password and the Ansible Vault password.

syncoid to TrueNAS

In my homelab, I have 2 NAS systems:

• Linux (Debian)
• TrueNAS Core (based on FreeBSD)

On my Linux box, I use Jim Salter’s sanoid to periodically take snapshots of my ZFS pool. I also want to have a proper backup of the whole pool, so I use syncoid to transfer those snapshots to another machine. Sanoid itself is responsible only for taking new snapshots and pruning old ones you no longer care about. For example, you might set up a policy in sanoid to take a day’s worth of hourly snapshots and a year’s worth of monthly snapshots. That means, that sanoid will take a snapshot every hour, but – if executed with --prune-snapshots will delete all the hourlies (hourly snapshots in sanoid’s lingo) that are older than a day, monthlies that are older than a year and so on.

openpgp-paper-backup

I’ve been using OpenPGP through GnuPG since early 2000’. It’s an essential part of Debian Developer’s workflow. We use it regularly to authenticate package uploads and votes. Proper backups of that key are really important.

Up until recently, the only reliable option for me was backing up a tarball of my ~/.gnupg offline on a set few flash drives. This approach is better than nothing, but it’s not nearly as reliable as I’d like it to be. The main reason is that data on a flash drive degrades over time. You have to remember to periodically plug the flash drive into your computer’s USB port because the electric charge that represents your data wears off with time. I always wanted a more durable medium that I could store both, at home and in a safety deposit box.

Since I’ve started working in Information Security space, I’ve been talking to a lot of people about the topics related to protecting ones’ identity online. Basically, trying to answer the question: What does it take to sufficiently secure my online accounts? Of course, the meaning of sufficiently is very subjective here, but I’ve always kept it vague to gauge what it means to them specifically.

I did make sure to talk people of various backgrounds – from deeply technical all the way to not technical at all. Surprisingly, many of them, even among the quite technical crowd, turned out to be lacking the understanding of some important fundamentals. In particular, it’s not always clear to them, what problems Multi-Factor Authentication (MFA) is targeting and solving. What threats do Password Managers are targeting and solving.

Unattended Upgrades in Debian

Feels like since forever have I been using unattended-upgrades package to automate the Security upgrades on my various Debian Stable based machines.

Default Settings

By default unattended-upgrades will install only Security updates. It also will not send any email reports. That is not surprising – well, you have to have email delivery configured and unattended-upgrades needs to know, what email address to send those reports to.

Tweaking the Config

If you need more than what the defaults give you, it’s easy to modify the config as described in the Debian Wiki. I think the most elegant way of customizing the configuration is described in the README.md of the Debian package source. You basically create /etc/apt/apt.conf.d/52unattended-upgrades-local and put any overrides to the default config you need.

I’ve been wanting to use my brand new NitroKey 3, but TOTP is not supported yet. So, I’m looking to implement it myself, since firmware and tooling are open-source.

NitroKey 3’s firmware is based on Trussed framework. In essence, it’s been designed so that anyone can implement an independent Trussed application. Each such application is like a module that can be added to Trussed-based product. So if I write a Trussed app, I’d be able to add it to NK3’s firmware.

As a Debian Developer I have a discount on using Gandi and I’ve been using it for quite a long time and have been very happy with it. I’ve been using it for registering domains. For example this blog’s domain is managed by my Gandi account.

Using publicly registered domain in private-only setup

In addition to using this DNS registrar for public stuff, like a blog, one can also use it for a domain accessible only within a private network. For example companies, large and small, use this technique – they have a set of subdomains of the domain they normally use, but those are accessible only when an employee is in the office (connected directly to the company’s network) or connected through a corporate VPN.

This post is the third in a three-part series. The remaining two:

• How does Google Authenticator work? (Part 1)
• How does Google Authenticator work? (Part 2)

Part 3 is the last part in this short cycle. Here I’ll explain all the details around Time-based One-Time Password algorithm. I’ll finish up by also elaborating on things common to both, HMAC-Based One-Time Password algorithm:

• QR Codes used to easily transfer secrets from the server to the Authenticator app
• Base32 algorithm – used to store non-printable secret in a URI (effectively stored by the QR Codes mentioned above).

TOTP

One way to avoid the problems with lack of feedback between server and the app would be to shift from using a counter that is increasing with every authentication attempt to a counter based on, for example, a time stamp. This is what TOTP is actually doing.

This post is the the second in a three-part series. The remaining two:

• How does Google Authenticator work? (Part 1)
• How does Google Authenticator work? (Part 3)

Authenticator apps like Google Authenticator use 2 authenticaion protocol centered around What you have paradigm. Those algorithms are:

• HOTP (HMAC-based One Time Password), and
• TOTP (Time-based One Time Password).

They obviously are different, but both are centered around the same basic idea: using a rolling hash value, that is predictable only to the server and the authenticator app. Additionally, both are using HMAC-SHA-1 for generating those hash values.