Note-to-Self on mhemeryck

unifi terraform

Thu, 16 Dec 2021 00:00:00 +0000

Last week, I did write about resetting my unifi cloud key.

The main reason I did gain a renewed interest in the cloud key was because I wanted to add some more fixed IPs to my home network. One of the nice things about the unifi controller software is that it provides a single dashboard interface to manage everything network-related.

On the downside, the interface is overall quite limited. While it does offer DHCP (the fixed IPs) in this fashion, it does not offer built-in DNS (e.g. for naming dedicated hosts on the home network).

Additionally, I also don’t really like these point-and-click interfaces which are hard to put under version control except for a full snapshot. Coming from a software development background and with the current infrastructure-as-code movement, I wanted to look into an alternative.

infrastructure-as-code and HashiCorp terraform

Nowadays, if you want to run some kind of software service, all the major cloud providers do provide web APIs to manage the (virtual) infrastructure for you. Managing infrastructure at this point becomes another software problem for interacting with these APIs, thus the term infrastructure-as-code.

One platform that has become increasingly popular in that regard has been HashiCorp’s terraform. It provides an abstraction layer for all of these different cloud provider and offers an ecosystem for easily adding more modules.

Additionally, the format is declarative, meaning that the tool will manage the life cycle of the components you describe. As an example, adding a resource means just declaring it in the configuration file and running it through the terraform CLI tool. At that point, the resource becomes managed by terraform. Destroying the resource is done by removing the entry from the configuration file and once again applying. Essentially, the configuration file will always reflect the state of the resources being managed and vice versa.

unifi-terraform

What does any of that have to do with my tiny homelab setup? Enter unifi-terraform, which is a community provided terraform module that interacts with the API of the unifi cloud key. This way, I could manage all the required fixed IPs.

As I mentioned in my previous post, I did have some trouble getting started though, so let’s walk a bit through the steps I had taken.

terraform configuration file

The first step is creating a main.tf file containing the actual configuration. I’m not going to elaborate too much on this here, see the terraform docs for that.

Generally, my configuration file looked like this (redacted).

terraform {
required_providers {
unifi = {
source = "paultyng/unifi"
version = "0.34.0"
}
}
}
provider "unifi" {
username = var.username # These are in a variables file
password = var.password
api_url = var.api_url
}
resource "unifi_site" "sitename" {
description = "Default"
}
resource "unifi_user_group" "default" {
name = "Default"
}
# the network / DHCP config
resource "unifi_network" "lan" {
name = "LAN"
purpose = "corporate"
dhcp_dns = [
"192.168.1.21",
"1.1.1.1",
"8.8.8.8",
"9.9.9.9",
]
dhcp_enabled = true
dhcp_start = "192.168.1.20"
dhcp_stop = "192.168.1.254"
domain_name = "lan"
igmp_snooping = true
subnet = "192.168.1.0/24"
}
# WLAN
resource "unifi_wlan" "wlan" {
name = "wlan"
security = "wpapsk"
passphrase = var.passphrase_wifi_wlan
network_id = unifi_network.lan.id
user_group_id = unifi_user_group.default.id
wlan_band = "5g"
multicast_enhance = true # chromecast
# default group ID
ap_group_ids = [
var.ap_group_id
]
# enable WPA2/WPA3 support
wpa3_support = true
wpa3_transition = true
pmf_mode = "optional"
}
...
# Devices
resource "unifi_device" "my-router" {
name = "my-router"
}
...
# Users: network clients
resource "unifi_user" "my_client" {
name = "my-client"
mac = "d9:6e:3d:12:8f:53"
fixed_ip = "192.168.1.10"
network_id = unifi_network.lan.id
}
...
resource "unifi_user" "floating_client" {
name = "floating"
mac = "bc:e4:26:db:df:e4"
}

At the top of this file the required_provider is mentioned, i.e. the module that contains the client code to talk to the unifi cloud key API. The provider block contains the data used for the provider to do the actual connection (essentially username / password and a URL to connect to).

There’s a couple of interesting resources in there:

unifi_site: just the physical location – I guess this makes more sense if you have multiple locations to manage
unifi_user_group: this is relevant if you want to separate out specific access for e.g. WiFi clients.
unifi_network: main (wired) network parameters, including e.g. the DHCP settings
unifi_wlan: wireless network configuration. Helpful if you want push in passwords
unifi_device: the unifi hardware such as switches, routers and wireless access points. I actually don’t have anything in particular to manage here, but I guess if you want to have specific port profiles for a switch, this would be the way to link to it
unifi_user: the clients on the network. It’s at this point that I can actually fix the IPs.

Have a look at unifi-terraform for more resources that can be managed.

terraform import

At this point, you could in theory start creating all of the resources by applying it (with terraform apply). In reality, these resources are likely already recognized and managed by the cloud key itself. The way around that is by importing the resources via terraform import {resource_name} {resource_id}

The {resource_name} is just the name as you did provide it in the main configuration file, e.g. unifi_user.my_client The {resource_id} is an ID that’s used in the API of the cloud key. This was for me the point for which it all broke down since I couldn’t find any good documentation of this API.

cloud key API

Fortunately, I did find some pointer into the cloud key API in a blog post from the original module author. Another real help to me has been this unifi PHP client code which also lists most of the endpoints.

I did distill all my findings into this cloud key postman collection.

Let’s walk through some of the API calls, built using httpie.

login: `POST {host}/api/login`

printf '{
 "username": "foo",
 "password": "bar"
}'| http --follow --timeout 3600 POST 'https://cloudkey.lan:8443/api/login' \
 Content-Type:'application/json' \
 Cookie:'csrf_token=abc; unifises=dfcwZvHcpBwc5LTlOzgxYSlsutpC6F2b'
HTTP/1.1 200
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: Access-Control-Allow-Origin,Access-Control-Allow-Credentials
Connection: keep-alive
Content-Length: 30
Content-Type: application/json;charset=UTF-8
Date: Thu, 16 Dec 2021 20:55:24 GMT
Keep-Alive: timeout=60
Set-Cookie: unifises=19uFvBLta4optBuzwV4QyVip5TbdR0t6; Path=/; Secure; HttpOnly
Set-Cookie: csrf_token=Z1dK47sp8NsjfpdbgHNyVNgYewNYIodd; Path=/; Secure
X-Frame-Options: DENY
vary: Origin

{
 "data": [],
 "meta": {
 "rc": "ok"
 }
}

This call will perform the login on the login endpoint and set a cookie for subsequent calls. Note that all other calls will need this cookie and that it will expire.

self: `GET {host}/api/s/{site}/self`

http --follow --timeout 3600 GET 'https://cloudkey.lan:8443/api/s/default/self' \
 Cookie:'csrf_token=cNHfNcA1zQoMW9wzFvCmGwEEo22irJ6D; unifises=dfcwZvHcpBwc5LTlOzgxYSlsutpC6F2b'
HTTP/1.1 200
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: Access-Control-Allow-Origin,Access-Control-Allow-Credentials
Connection: keep-alive
Content-Encoding: gzip
Content-Type: application/json;charset=UTF-8
Date: Thu, 16 Dec 2021 20:58:28 GMT
Keep-Alive: timeout=60
Transfer-Encoding: chunked
X-Frame-Options: DENY
vary: accept-encoding,origin,accept-encoding

{
 "data": [
 {
 ...
 "site_id": "{site_id}",
 "site_name": "default",
 ...
 }
 ],
 "meta": {
 "rc": "ok"
 }
}

This just lists some generic information about the site (location), e.g. the site_id to be imported.

devices: `GET {host}/api/s/{site}/stat/device`

http --follow --timeout 3600 GET 'https://cloudkey.lan:8443/api/s/default/stat/device' \
 Cookie:'csrf_token=cNHfNcA1zQoMW9wzFvCmGwEEo22irJ6D; unifises=dfcwZvHcpBwc5LTlOzgxYSlsutpC6F2b'
...
{
 "meta": {
 "rc": "ok"
 },
 "data": [
 {
 "_id": "5ea4395234309a00041ffa6e",
 "adopted": true,
 "anon_id": "d5416fde-c2ad-4558-9aa0-4b4024c441de",
 "antenna_table": [
 {
 "default": true,
 "id": 4,
 "name": "Combined",
 "wifi0_gain": 3,
 "wifi1_gain": 3
 }
 ],
 ...
 }
 ]
}

This endpoint is interesting to get the IDs of the devices to import.

users: `GET {host}/api/s/{site}/rest/user`

http --follow --timeout 3600 GET 'https://cloudkey.lan:8443/api/s/default/rest/user' \
 Cookie:'csrf_token=cNHfNcA1zQoMW9wzFvCmGwEEo22irJ6D; unifises=dfcwZvHcpBwc5LTlOzgxYSlsutpC6F2b'
...

{
 "meta": {
 "rc": "ok"
 },
 "data": [
 {
 "_id": "9dfeee213c227000f47aade2",
 "mac": "48:98:e3:f6:21:a5",
 "site_id": "5dffdda64c2370010eb91fa0",
 ...
 },
 ]
}

This was the most important endpoint for my purposes: it lists the resource ID under _id and makes it possible to import it.

Practically, this means

terraform import unifi_user.my_client 9dfeee213c227000f47aade2

At this point, the client should be managed by terraform.

Refer to the cloud key postman collection for more resources. Note that I only really looked into the read-only endpoints (the GET operations) since I would have terraform do the actual operations (POST, PATCH).

Closing thoughts

I was really pleased to see that after some crawling of the cloud key API I was able to get the unifi resources managed with terraform. At this point, I can manage my unifi configuration under source control, most notably the DHCP fixed IPs and some firewall rules. This only scratches the surface of what is now possible at this point though.

Since terraform also has modules for various DNS providers such as powerdns, coredns and even pihole I could start thinking of managing the fixed IPs and the host names from a single spot. The same local network DNS could then be used by my local kubernetes to register service names into.

Since it’s supposedly infrastructure-as-code, I could also start thinking of integrating everything in CI/CD flow, where the terraform code is first validated and then automatically applied. This in turn would mean I’d need to find a way to either self-host a source control / CI/CD platform (thinking of gitlab) or find some way to safely tunnel out to a cloud-based platform with (thinking github actions + wireguard).

Another change I’d like to make, is to use a remote state back-end instead of the local file storage.

… but that’s for another time!

cloud key reset

Wed, 08 Dec 2021 00:00:00 +0000

After my last password issues post, I still had some places for which I didn’t have an easy approach to reset the login. For my local network, I still use a unifi cloud key gen 1, to keep an overview of the network.

Cloud key

The ubiquiti unifi cloud key is a small client device on the local network, specifically running the ubiquiti unifi controller software. The controller software is there to e.g. provision new (ubiquiti) hardware, to configure the network (switch ports, VLANs, firewalls, …) but also to allow remote management from a web interface or phone app.

Note that you actually don’t need dedicated hardware to run the controller software. You can just as well run the software from your own local computer or instead use the dockerized controller software. Having it on a dedicated device though means that it is always available, doing logging and monitoring in the background and providing an entry point for remote access. Additionally, the cloud key does indeed mainly run the controller software, but it also has onboard firmware to set manage the controller software for you.

On the upside, I think the unifi experience is overall quite nice and graphically slick. Despite being considered a prosumer kind of brand, some features I would consider as basic are missing though (built-in DHCP / DNS, VPN termination, …)

In the end, I still like the unifi products since they do have somewhat more enhanced features yet mostly “just work”. There was a time when I was running my own openWrt-enabled router, but the reality just is that after the initial setup, this is just something I barely feel the need to touch (and maintain).

Factory reset

As mentioned above, the cloud key hardware runs both the main unifi controller software as well as its own firmware to manage said software. The login for the controller software is done via my ui.com account. Retrieving that one was as simple as resetting this account.

The controller firmware management however is also password-protected and being a good citizen, I obviously changed it from its default of ubnt / ubnt. Even though I still had access to the controller software, I figured it’d be better to have full access to the firmware management as well. The rationale is that the times when you often need this is in case of some breaking issue – in which event you want to have immediate access.

The cloud key has an SD-card, so I figured that it would run from there (pretty much how a raspberry pi does). After checking the SD card contents though, they only seemed to contain the regularly scheduled backups.

Checking the cloud key gen1 pdf docs showed me that there is simple factory reset button. After grabbing a backup snapshot of the controller software, I did decide on just triggering the factory reset.

Sure enough, the firmware management did now work with the default credentials (prompting me to change it straight after that).

Let’s Encrypt certificates setup

I want to be able to also access the cloud key on a regular URL even if it’s only from my local network. Also, by default the cloud key controller software will use an HTTPS version (which is good), but it obviously has no built-in way to provide a valid certificate (not so good).

A side-effect of this factory reset was that I had now lost this setup in where the cloud key itself regularly pulls in an updates Let’s Encrypt SSL certificate. In the past, I had followed this nicely detailed blog post on cloud key SSL certificates with Let’s Encrypt.

To summarize the steps for myself for future reference:

Fixed IP for the cloud key: this actually easy to do from the unifi controller software (running on the cloud key)
DNS entry for this fixed IP: I use pihole’s built-in dnsmasq for this. This means that all devices on my local network will be able to resolve the host for the cloud key
Set up a job on the cloud key to regularly pull in updated SSL certificates

`acme.sh` Let’s Encrypt cloud key bot setup

The way Let’s Encrypt works is that you can request a certificate for your own domain name. Afterwards, the Let’s Encrypt server will verify with you whether or not you actually own the domain for which you did request the SSL certificate. This can be done in a multitude of ways, but the most common ones are:

HTTP-based: on the service you expose, you host some kind of secret that was given to you before by Let’s Encrypt
DNS-based: on the DNS provider on which you host the domain, you provide an txt kind of record which Let’s Encrypt, again containing the secret Let’s Encrypt had provided before

For my home network case, I am obliged to use the DNS-based approach, since my own service isn’t exposed on the wide internet for Let’s Encrypt to call back to. It’s a nice approach to be able to get valid SSL certificates for a machine on a local network. Additionally, a lot of tooling is readily available to automate all details for you, such as certbot or cert-manager.

Essentially, these steps are completely taken from the aforementioned post. Since I wouldn’t like to lose these and since I have some minor differences due to using digital ocean as DNS provider, I detail them here again for myself.

Installing the bot:

curl https://get.acme.sh | sh

Installing a hook script to run on certificate renewal in /root/.acme.sh/cloudkey-renew-hook.sh

#!/bin/bash
# Renew-hook for ACME / Let's encrypt
echo "** Configuring new Let's Encrypt certs"
cd /etc/ssl/private
rm -f /etc/ssl/private/cert.tar /etc/ssl/private/unifi.keystore.jks /etc/ssl/private/ssl-cert-snakeoil.key /etc/ssl/private/fullchain.pem

openssl pkcs12 -export -in /etc/ssl/private/cloudkey.crt -inkey /etc/ssl/private/cloudkey.key -out /etc/ssl/private/cloudkey.p12 -name unifi -password pass:aircontrolenterprise

keytool -importkeystore -deststorepass aircontrolenterprise -destkeypass aircontrolenterprise -destkeystore /usr/lib/unifi/data/keystore -srckeystore /etc/ssl/private/cloudkey.p12 -srcstoretype PKCS12 -srcstorepass aircontrolenterprise -alias unifi

rm -f /etc/ssl/private/cloudkey.p12
tar -cvf cert.tar *
chown root:ssl-cert /etc/ssl/private/*
chmod 640 /etc/ssl/private/*

echo "** Testing Nginx and restarting"
/usr/sbin/nginx -t
/etc/init.d/nginx restart ; /etc/init.d/unifi restart

This will modify the retrieved certificates in such a way that they can be used by the unifi controller software.

Export the proper API keys to the environment. In my case, I am using the digitalocean DNS provider. This changes the line in the .bashrc file to adapt to something like

export DO_API_KEY=<key>

The first certificate retrieval line changes to

acme.sh --force --issue --dns dns_dgon -d <YOUR_DOMAIN> --pre-hook "touch /etc/ssl/private/cert.tar; tar -zcvf /root/.acme.sh/CloudKeySSL_`date +%Y-%m-%d_%H.%M.%S`.tgz /etc/ssl/private/*" --fullchainpath /etc/ssl/private/cloudkey.crt --keypath /etc/ssl/private/cloudkey.key --reloadcmd "sh /root/.acme.sh/cloudkey-renew-hook.sh"

The crontab entry becomes:

0 0 * * * /root/.acme.sh/acme.sh --renew --apache --renew-hook /root/.acme.sh/cloudkey-renew-hook.sh -d <YOUR_DOMAIN>

At this point, everything should be back up and running and the cloud key should be accessible from the custom domain with a valid certificate!

Closing thoughts

This post serves mainly as a note-to-self after needing to go through some steps to manually recover my cloud key setup.

At this point, the cloud key is just back running as before. Going through this process again made me realize some points of improvement.

Firstly, in the past I did run the controller software as part of my home k3s cluster, but I ended up not doing that since it cost me a lot of resources and I basically did not want to manage that. However, I still have some plans to upgrade the cluster setup itself at which point it might come interesting again to run it there. The added value would be that I could manage the certificate renewal using cert-manager instead of via a cron job. The downside of the cron job on the cloud key is that it gets wiped for firmware upgrades.

Secondly, I am also not completely happy with the manual host name management. I first need to configure a static IP manually in the controller software and then also manually configure pihole / dnsmasq. It seems there is a unifi terraform provider that would be able to handle the IP management – but I haven’t been able yet to get that working with the cloud key (perhaps it does not work for the gen 1?). DNS configuration can be done via API using e.g. powerdns or coredns, which is another route to explore. Services running on the kubernetes cluster could then also register their host names using external-dns

Thirdly, it would also be nice that any of the host names I set for my local network are actually accessible in a similar manner over a wireguard VPN.

A final small change would be for me to change DNS provider from digital ocean to hetzner cloud since I have everything else there.

Still a lot of home lab ideas, so little time, let’s see what’s next!

Password troubles

Wed, 01 Dec 2021 00:00:00 +0000

Last Saturday, my new phone arrived in the mail. As a techie, I was naturally delighted to get my new treat up and running. Both my old and my new phone are Android phones and I was surprised to see how (shockingly) easy it was to migrate all my stuff. Not all settings were migrated directly though; mostly passwords would need to be set up again.

Since I did use gnu pass + GPG for my password management as described in my previous password management post earlier this year, I figured this would be quite easy to do!

Unfortunately, the whole endeavor ended with me losing my current GPG sub keys and (again) all my passwords.

Recap

But first, let’s explain the setup again.

GPG

I have a main GPG public / private key pair, valid indefinitely, stored offline. From these, I generate 3 sub key pairs valid for the coming year:

encryption key: encrypt / decrypt stuff, notably passwords
signing key
authentication key: to be used for SSH.

`pass`

pass is essentially a wrapper around GPG. It manages a folder in your home folder containing an encrypted file using a previously defined GPG encryption key. Typically, that’s the GPG encryption sub key mentioned earlier.

pass also wraps around git, meaning you can have remote (encrypted) versioned backup of your password storage using git.

Chrome integration: browserpass

Chrome has an extension called browserpass which essentially allows you to fill in passwords by calling pass. Apart from the passwords, it’s also possible to store the usernames (or any extra data, really) as part of the secret in pass, which browserpass will fill in for you. I’m using the extension for chrome, but I suppose there are similar integrations for other browsers as well.

Android integration: openkeychain + password store

My phone setup is quite similar:

openkeychain for the keys (gpg)
password store for the passwords (pass)

Since pass has the possibility to sync the full password store based on git, it’s actually quite easy to keep my laptop and phone in sync.

yubikey

The yubikey provides a suite of different cryptographic operations (e.g. U2F), but in this case, I use to also physically contain aforementioned GPG private sub keys.

For example, in the case of password management:

encrypt a new password: insert a new password with pass pass insert <passname>. pass will use the public key to encrypt the password
decrypt the password: you’d need the private key to decrypt. Since the private key is never on my laptop, I need to insert my yubikey to decrypt.

For SSH authentication, I use something similar where the GPG agent provides the SSH process an SSH private key, based on the GPG authentication sub key, which lives on the yubikey.

Having the GPG sub keys not physically on the laptop is safer but means you can’t afford losing the yubikey. To mitigate this risk of losing the yubikey (and the GPG sub keys on them), I would save an offline backup of the sub keys prior to copying them to the yubikey.

So, at this point, when there’s a backup, nothing can go wrong anymore, right?

The problem

Well, no.

In my previous password management post, the issue was that I did drop my old GPG decryption key before decrypting the passwords.

In this case, multiple things went wrong.

First of all the openkeychain app on my new phone did not directly recognize my yubikey. After trying a second time, it indicated there were no GPG keys on the yubikey. Checking on my laptop indeed revealed the yubikey had no more GPG keys. Even more, at this point, it looked like the yubikey had been pretty much wiped to factory state.

Next step is checking out the offline backup. I did find the sub keys again that I had saved for this very purpose. Re-importing them did however not result in being able to decrypt again.

To verify what had happened, I did start from a live OS boot (i.e. tails) and tried a clean setup with all my private keys.

What it showed me was something like this (redacted):

~ gpg -K
/$HOME/.gnupg/pubring.kbx
----------------------------------
sec rsa4096 2016-06-24 [SC]
1B477ADA04B47A5CE61AEDE01AA36833BC86F0F1
uid [ultimate] Martijn ... <user@mail.com>
ssb rsa4096 2016-06-24 [E]
ssb> rsa4096 2021-03-09 [E] [expires: ...]
ssb> rsa4096 2021-03-09 [S] [expires: ...]
ssb> rsa4096 2021-03-09 [A] [expires: ...]

The bracket > in front of ssb means that it’s a stub of a sub key. A stub is what is left over on the key ring after the private key has been moved to the key card (the yubikey). Apparently, instead of making a backup of the key, I had made a back-up of the stub …

The key issue is that the gpg keytocard operation is a destructive one. If you move the private key to the card, only the stub is left, never to be retrieved again. To make a proper back-up of the private key (sub key or full key), do it before you move it over to the key card!

Closing thoughts

Since this was the second time in a relatively short time I had principally lost all my logins, I really felt like giving up altogether on this solution for password management.

However, the whole gpg + pass + git + yubikey combo still is quite appealing to me. It fits in the true Unix philosophy of “having each program do one thing well”. I also like the fact I’m myself in complete control of the data instead of relying on a remote cloud provider, specifically if it is about sensitive data.

Ultimately, after a couple of days of re-requesting logins, I’m back to before, this time with a proper backup (fingers crossed!).

Bootstrapping a pi4

Sun, 21 Feb 2021 00:00:00 +0000

I’ve recently bought myself a raspberry pi 400, a small form factor keyboard with a raspberry pi 4 4GB RAM built into it. In hindsight, there are probably very few scenarios in which such a computer makes actually makes sense to me, but it still looks quite nice. I first took it for a spin using the raspberry pi OS that was on the SD card that came along with the set, but while I can acknowledge that it works quite OK out of the box, it just looks so ugly. Henceforth, I did decide on installing arch for ARM on it. Since I did notice that I need to rethink every time again what are the best tools to install on a fresh install, this is a write-up of the most important tools I would always install.

The key 2 tools are:

pass password manager
yadm yet-another-dotfile-manager

The rationale behind it is the following: I use pass to be able to get easy access to all my passwords and logins, yadm manages all the other dotfiles for me.

Arch

For a “regular” arch install, see the arch installation guide. In this case, the installation was a bit atypical since it was for an ARM platform, see arch for ARM for this (I did use the ARMv7 installation guide).

Other noteworthy steps in the installation …

arch linux arm: noisy boot

Terminal would show all of the kernel audit messages; add audit=0 to command line options /boot/cmdline.txt

Remove noisy welcome message

rm /etc/motd

Helpers

Some helpers to install with the subsequent steps:

pacman -Syu --noconfirm zsh sudo which vim git openssh libfido2
pacman -S --noconfirm --needed base-devel

Add a user

touch /etc/skel/.zshrc
groupadd sudo
useradd -m $USER -g $GROUP -G sudo -s /usr/bin/zsh
echo "%sudo ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/$USER

Update password

passwd $USER

Install `pikaur`

git clone https://aur.archlinux.org/pikaur.git
cd pikaur
makepkg -fsri

Some more helpers

Some more helpers I’d always like to keep around

pikaur -S --noconfirm ctags oh-my-zsh-git ripgrep fzf bat tmux

git default config

Since we’ll be using git, you’ll need to define some initial config

git config --global user.email <email>
git config --global user.name "<name>"
git config --global init.defaultBranch master
git config --global pull.rebase true

`gpg`

Import stubs from yubikey

Install and enable smart card reader:

pikaur -S ccid
systemctl enable pcscd
systemctl start pcscd

Fetch keys from card

gpg --edit-card
> fetch
> quit

Get the key id

KEYID=$(gpg --with-colons --fingerprint | awk -F: '$1 == "fpr" {print $10;}' | head -n1)

Update the trust of the key

gpg --edit-key $KEYID
> trust
> 5
> quit

Enable ssh-agent using gpg-agent (temporarily; the final zshrc file will contain the proper setup)

export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"

Tell the gpg-agent to prompt on the current TTY:

gpg-connect-agent updatestartuptty /bye

`pass`

Install pass

pikaur -S pass

Init pass

pass init $KEYID
pass git remote add origin git@gitlab.com:<repo>
pass git pull
pass git reset --hard origin/master

`yadm`

pikaur -S yadm
yadm clone git@gitlab.com:<repo>

At this point, I have all the minimum tools I would use for my daily work.

UI

Even though I would spend most of my life on the command line, I also a graphical environment to work in.

I’m not going to delve to deeply into that, since I mostly prefer vanilla gnome3 for that, combined with gdm for a login manager.

Closing thoughts

My initial goal was to find a way of completely automating my initial installs, but in the end I figured this wasn’t what I really needed, because:

distro-specific: I don’t always run on the same distro, so not everything is portable
other requirements: for unattended installs (servers), I don’t want / need to copy all my secrets on there (albeit encrypted or not)
outdated: for my daily driver install, I have no need to often keep on reprovisioning my install. By the time I would have a need to reprovision, a lot of the setup has probably changed, so it makes more sense to (vaguely) document some of the basic steps instead of a fully automated machine image.

Updating GPG subkeys

Tue, 09 Jul 2019 00:00:00 +0000

This is just a list of things to consider when updating my GPG subkeys (encryption, signing, authentication) for the particular setup I use on a daily basis:

one master key without any expiry date to generate and revoke subkeys
I use pass as my password manager.
1. the basic idea is that it’s a command-line password manager that uses gpg under the hood for encrypting / decrypting the passwords.
2. the passwords are encrypted with an encryption subkey
3. pass allows managing its history with git, linking the storage on a remote gitlab / github server.
the subkeys are only stored on my yubikey
the subkeys are always valid for a period of one year
the yubikey I use also has NFC, which makes it possible to use it on my android phone as well

I recently needed to go through this process and did forget to re-encrypt …

The main steps are:

generate new subkeys
pass: re-encrypt with both sets of keys available
move the new keys to the card
backup the master key again and remove all keys from the local machine

Generate the new subkeys

First, put the master key back on the local machine, such that we can generate new subkeys.

If you’re really paranoid, you should consider something like tails to have a safe live OS for doing all these operations.

Add the key again:

gpg --import priv.asc

where priv.asc obviously is the backup of your master key.

Start generating new subkeys for that master key:

gpg --edit-key <foo@bar.com>

You will now get a prompt for doing operations on the master key. Go for addkey

gpg>addkey

Note: in case you didn’t have your master key, this will not work.

You can now add your signing and encryption keys; some parameters I’d like to use:

4096b size
1y expiration date
RSA for both encryption / signing

don’t forget to call save in the end.

You can now list all the keys:

gpg -K

Re-encrypt all passwords

This is really important (I messed up big time here): before you remove any older keys, make sure that they are re-encrypted with the new subkey!

List the fingerprint of the new subkey you’d like to use for re-encrypting:

gpg --fingerprint --fingerprint <foo@bar.com>

Re-encrypt:

pass init <fingerprint subkey>

Optionally, already push them out

pass git push

Push the new subkeys to the card

Again edit the key

gpg --edit-key <foo@bar.com>

Select the subkey

key <N>

where N is the count in the list of keys (visually not that obvious)

Add the key to the card

keytocard

select the slot to save to (encryption for encryption, signing for signing …)

and save

Remove the keys from the local computer again

First, make a backup of everything again; see gpg backup tutorial

Export your private key:

gpg -a --export-secret-keys <foo@bar.com> > priv.asc

Export public key:

gpg -a --export <foo@bar.com> > pub.asc

Optionally, already push it out to a key server:

gpg --send-keys <fingerprint>

Now, delete everything (best to unplug the key card):

gpg --delete-secret-key <fingerprint>

Plug the key card back in and sync

gpg --card-status

Check the keys are available albeit from the key card:

gpg -K

MQTT over TLS

Mon, 12 Nov 2018 00:00:00 +0000

MQTT is a popular lightweight protocol for use in home automation. If features a central broker where each of the clients can communicate with in a pub / sub fashion.

Since I’ve been toying around with some home automation setups, I was curious how to secure it with TLS.

Mosquitto

The most commonly used broker implementation I have come across is mosquitto and is quite straightforward to setup on most *nix flavors. In my setup, I wanted to run it on Raspberry Pi, which I could leave running at my local home network. Since it runs raspbian, installing it was as simple as:

~ sudo apt-get install mosquitto

TLS setup: keys and certificates

Doing the TLS setup requires a number of key and certificate files. The official mosquitto-tls man page fortunately lists all of them and how to generate them.

Note that for the final setup, not all of these files are required; these are the files we do need:

ca.crt: Certificate Authority certificate: the “central” authority certifying ownership of the public key
server.key: server private key, linked to the certificate.
server.crt: certificate from the server (MQTT broker), signing the server key pair, by the CA.

File layout on the broker

On my setup, most of these folders were already available after install, so I figured to actually use them.

~ tree /etc/mosquitto
/etc/mosquitto
├── ca_certificates
│   ├── ca.crt
│   └── README
├── certs
│   ├── README
│   ├── server.crt
│   └── server.key
├── conf.d
│   ├── README
│   └── tls.conf
└── mosquitto.conf

`mosquitto.conf`

This is pretty the same config that was also provided by the built-in; just to show:

~ cat /etc/mosquitto/mosquitto.conf
# Place your local configuration in /etc/mosquitto/conf.d/
#
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example
pid_file /var/run/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
# This include assures that our own custom config gets loaded
include_dir /etc/mosquitto/conf.d

`tls.conf`

Actual TLS specific config, pointing to all the files that were added.

~ cat /etc/mosquitto/conf.d/tls.conf
port 8883
cafile /etc/mosquitto/ca_certificates/ca.crt
keyfile /etc/mosquitto/certs/server.key
certfile /etc/mosquitto/certs/server.crt
tls_version tlsv1

Reload the setup

The package installer also conveniently creates the required (systemd) service for us. Simply restart the service now:

sudo systemctl restart mosquitto.service

With the broker running the new config, testing can easily be done with the mosquitto built-in mosquitto_pub / mosquitto_sub commands. Obviously, all clients that want to use this config now need the CA file.

On a client: subscribe:

~ mosquitto_sub --cafile ca.crt -h raspberrypi.lan -t test

Note: the host name should correspond to the host name in the certificate.

Client publish

On a client: publish

~ mosquitto_pub --cafile ca.crt -h raspberrypi.lan -t test -m "hi there"

In the window running the subscribe, the message should now appear.

Here, the clients do not verify themselves though, they just use the certificate to encrypt traffic over TLS.

Note-to-Self on mhemeryck

unifi terraform

infrastructure-as-code and HashiCorp terraform

unifi-terraform

terraform configuration file

terraform import

cloud key API

login: POST {host}/api/login

self: GET {host}/api/s/{site}/self

devices: GET {host}/api/s/{site}/stat/device

users: GET {host}/api/s/{site}/rest/user

Closing thoughts

cloud key reset

Cloud key

Factory reset

Let’s Encrypt certificates setup

acme.sh Let’s Encrypt cloud key bot setup

Closing thoughts

Password troubles

Recap

GPG

pass

Chrome integration: browserpass

Android integration: openkeychain + password store

yubikey

The problem

Closing thoughts

Bootstrapping a pi4

Arch

arch linux arm: noisy boot

Helpers

Add a user

Install pikaur

Some more helpers

git default config

gpg

pass

yadm

UI

Closing thoughts

Updating GPG subkeys

Generate the new subkeys

Re-encrypt all passwords

Push the new subkeys to the card

Remove the keys from the local computer again

MQTT over TLS

Mosquitto

TLS setup: keys and certificates

File layout on the broker

mosquitto.conf

tls.conf

Reload the setup

Client subscribe

Client publish

login: `POST {host}/api/login`

self: `GET {host}/api/s/{site}/self`

devices: `GET {host}/api/s/{site}/stat/device`

users: `GET {host}/api/s/{site}/rest/user`

`acme.sh` Let’s Encrypt cloud key bot setup

`pass`

Install `pikaur`

`gpg`

`pass`

`yadm`

`mosquitto.conf`

`tls.conf`