Creating FIDO2 SSH keys using ssh-keygen

$ ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk
  • -t ecdsa-sk specifies the key type to generate. Alternatively, you can generate Ed25519 keys using -t ed25519-sk.
  • -f ~/.ssh/id_ecdsa_sk specify the output path for the newly generated key.

You can provide a passphrase for your key if you would like to do so. Unlike normal ssh keys, the private key is not that sensitive, as it is useless without the physical security key itself.

ed25519-sk vs ecdsa-sk

Newer YubiKeys (firmware >=5.2.3) and some other FIDO2 keys, support Ed25519 keys. Ed25519 have some advantages over the common ECDSA keys in several aspects:

  • Ed25519 is based on the Curve25519 vs NIST P-256 used for ecdsa-sk. Curve25519 is generally regarded as faster and safer than NIST P-256, see SafeCurves. Furthermore, the underlying signature algorithm (Schnorr vs DSA) is slightly faster for Ed25519
  • EdDSA in general, and Ed25519 in particular, uses deterministic nonce versus random nonce used by ECDSA. This means that ECDSA is prune to catastrophic entropy failure (see the famous fail0verflow PS3 hack as an example). Assuming your key has access to high entropy randomness, that shouldn’t be a problem. However, that assumption might turn out false, like in the case of the reduced initial randomness in the Yubikey FIPS Series.

In the bottom line, if you have access to a key that supports ed25519-sk then it’s preferable to use it. If you don’t, that’s not something to worry about to much. There are probably weaker points in your threat model anyway.

If your FIDO2 key doesn’t support ed25519-sk you will get the following error when trying to generate a key:

Key enrollment failed: requested feature not supported

Moving keys to a new computer

If you want to use the keys on a new computer, you will have to copy over the private key file that you generated. That will normally be ~/.ssh/id_ecdsa_sk or ~/.ssh/id_ed25519_sk, depending on the type of key you generated.

Alternatively, you can generate resident keys which are completely stored on the YubiKey. To generate resident keys, append the -O resident to your ssh-keygen command. Example:

$ ssh-keygen -t ecdsa-sk -O resident

To import the keys to a new device, use the -K option:

$ ssh-keygen -K

This will download all the keys (public and private) from the YubiKey to the current directory. There is no need to manually transfer any key files.

YubiKey Series 5 devices can hold up to 25 resident keys.

Setting SPF Record

SPF allows one to specify which SMTP servers can send emails on behalf of a domain. The SPF record is defined as a DNS TXT record and specifies the list of allowed senders for the domain.

"v=spf1 a ip4:134.209.224.112 include:_spf.mx.cloudflare.net include:_spf.google.com ~all"
  • v=spf1 specifies that this TXT record is indeed an SPF record.
  • a include the IP addresses of the domain, as returned by the A or AAAA records. This is required to let your own server send emails.
  • ip4:134.209.224.112 allows a specific server by IP address to send emails. You can also use netmasks (ie /20) to allow ranges.
  • include:_spf.mx.cloudflare.net allows Cloudflare Email Routing to forward emails for your domain.
  • include:_spf.google.com allow sending emails via Google Workspace/Gmail.
  • ~all This marks every other server not listed so far as insecure/spam, but the email will be accepted. This can be replaced by -all which would tell the recipient to reject emails from unauthorized servers.

References

List obsolete packages using Apt

Apt 2.0 introduced a new feature allowing to use smarter patterns when listing packages. This allows to list all obsolete packages using the specifier ?obsolete or the shorthand ~o.

$ apt list ?obsolete

It will list all locally installed packages and packages.

You can also list all packages not provided by Debian (it will also catch packages once provided by Debian but since then remove from the repositories):

$ apt list --installed "?not(?origin(debian))"

Slack screen sharing under Wayland

To get screen sharing in Slack to properly work under Wayland, you need to explicitly tell Slack to use PipeWire for screen capturing. Copy Slack’s desktop file from /usr/share/applications/slack.desktop to ~/.local/share/applications/slack.desktop and modify the Exec line to look like:

Exec=/usr/bin/slack --enable-features=WebRTCPipeWireCapturer %U

Now restart Slack and screen sharing should work properly.

Unlock LUKS volume with a YubiKey

Update: The dracut configuration has been updated and now udev consistently recognizes the YubiKey in the initramfs.

Unlocking LUKS encrypted drives with a YubiKey has been supported since systemd 248. In Debian, systemd>=250 is required, as the feature has not been enabled in prior versions. This tutorial is geared towards Yubikeys, but it should work with slight modifications with any other FIDO2 token.

YubiKey series 5 and later should support the hmac-secret extension. You can make sure your Yubikey supports the needed hmac-secret extension by querying it with ykman:

$ ykman --diagnose 2>&1 | grep hmac-secret

Backup your LUKS header

In case you mess anything up, you would need a backup of your LUKS header. Remember to save your backup to some external storage, so you can actually access it if anything goes sideways.

# cryptsetup luksHeaderBackup /dev/nvme0n1p3 --header-backup-file /media/guyru/E474-2D80/luks_backup.bin

Set FIDO2 PIN

We would like to set a FIDO2 PIN for the Yubikey, so unlocking the encrypted drive would require both the physical Yubikey and the PIN. You can set the PIN using:

$ ykman fido access change-pin

Enroll the Yubikey

Start by verifying that systemd-cryptenroll can see and can use your YubiKey:

$ systemd-cryptenroll --fido2-device=list
PATH         MANUFACTURER PRODUCT
/dev/hidraw0 Yubico       YubiKey FIDO+CCID

Now, enroll the Yubikey, replacing /dev/nvme0n1p3 with the block device of the LUKS encrypted drive.

$ sudo systemd-cryptenroll /dev/nvme0n1p3 --fido2-device=auto  --fido2-with-client-pin=yes
🔐 Please enter current passphrase for disk /dev/nvme0n1p3: (no echo)
Initializing FIDO2 credential on security token.
👆 (Hint: This might require confirmation of user presence on security token.)
🔐 Please enter security token PIN: (no echo)
Generating secret key on FIDO2 security token.
👆 In order to allow secret key generation, please confirm presence on security token.
New FIDO2 token enrolled as key slot 0.

Modify /etc/crypttab

We need to modify /etc/crypttab in order to tell cryptsetup to unlock the device using the YubiKey. Add fido2-device=auto in the options field of the crypttab entry for your device. For example:

nvme0n1p3_crypt UUID=307a6bef-5599-4963-8ce0-d9e999026c1a none luks,discard,fido2-device=auto

Switch to dracut

Debian’s default initramfs generator, update-initramfs of the initramfs-tools is using the old cryptsetup for mounting encrypted drives. However, cryptsetup doesn’t recognize the fido2-device option. Running update-initramfs will fail with the following error:

$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.15.0-3-amd64
cryptsetup: WARNING: nvme0n1p3_crypt: ignoring unknown option 'fido2-device'

This is unfortunate. The simplest solution is to switch to dracut, a more modern initramfs generator, which among other things relies on systemd to activate encrypted volumes. This solves the issue of the unknown fido2-device.

Before installing dracut, I would highly recommend creating a copy of the existing initramfs in the boot partition in case something goes wrong.

$ sudo apt install dracut

Dracut includes systemd-cryptsetup by default. systemd-cryptsetup depends on libfido for unlocking devices using FIDO2 tokens. At least in Debian, systemd-cryptsetup dynamically loads libfido2.so (as opposed to being dynamically linked), which causes dracut not to have libfido2.so in the initramfs. This causes systemd-cryptsetup to issue the following error upon boot:

FIDO2 tokens not supported on this build.

We fix it by manually adding libfido2.so to the initramfs. Of course, we also need to include libfido2’s dependencies as well. Dracut has a mechanism for automatically adding dependencies for executables, but it doesn’t work on libraries. As a workaround, instead of adding libfido2 directly, we will add an executable that depends on libfido2, which will add libfido2 and its dependencies to the initramfs. We will usefido2-token from the fido2-tools package for this trick.

$ sudo apt install fido2-tools
$ cat << EOF | sudo tee /etc/dracut.conf.d/11-fido2.conf
## Spaces in the quotes are critical.
# install_optional_items+=" /usr/lib/x86_64-linux-gnu/libfido2.so.* "

## Ugly workround because the line above doesn't fetch
## dependencies of libfido2.so
install_items+=" /usr/bin/fido2-token "

# Required detecting the fido2 key
install_items+=" /usr/lib/udev/rules.d/60-fido-id.rules /usr/lib/udev/fido_id "
EOF

Now, recreate the initramfs images:

$ sudo dracut -f

Last remarks

At this point, we are done. Reboot you’re machine and it will prompt you for your YubiKey and allow you to unlock your LUKS encrypted root patition with it. If you don’t have your YubiKey, it will give the following prompt:

Security token not present for unlocking volume root (nvme0n1p3_crypt), please plug it in.

After around 30 seconds, it would time out and display the following message:

Timed out waiting for security device, aborting security device based authentication attempt.

Afterwards, it would allow you to unlock the partition using a password (or a recovery key).

In case you run into any trouble, append rd.break=initqueue to the kernel command line, and dracut will enter a shell before attempting to mount the partitions. You can manually mount the drive using the following command:

# /usr/lib/systemd/systemd-cryptsetup attach root /dev/nvme0n1p3

Exit the emergency shell, and the system will continue its normal boot.

Extend laptop’s battery life using TLP

TLP helps optimize battery usage for laptops. TLP supports setting battery charging threshold, to allow keeping the battery partially charged, which prolongs its life. This can be done creating a new file under /etc/tlp.d/01-battery.conf:

START_CHARGE_THRESH_BAT0=80
STOP_CHARGE_THRESH_BAT0=85

Reload the TLP configuration for the new settings to take effect:

$ systemctl reload tlp.service

You can disable the battery threshold temporarily using:

$ sudo tlp fullcharge

Restoring the thresholds is done using

$ sudo tlp setcharge

Reset PIN for Yubikey after 3 failed attempts

When using a Yubikey as a GPG card, entering the wrong PIN multiple times will result in a disabled state. You can unblock the Yubikey by using the admin PIN.

$ gpg --edit-card
gpg/card> admin
Admin commands are allowed

gpg/card> passwd
gpg: OpenPGP card no. D2760001240102010006096610530000 detected

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? 2

Distortion correction profile for Tamron 18-300mm f/3.5-6.3 Di III-A VC VXD Lens for Sony E

I’ve created a distortion correction profile for Tamron 18-300mm f/3.5-6.3 Di III-A VC VXD Lens for Sony E to be used with Lensfun.

<lensdatabase>
    <lens>
        <maker>Tamron</maker>
        <model>E 18-300mm F3.5-6.3 B061</model>
        <mount>Sony E</mount>
        <cropfactor>1.534</cropfactor>
        <calibration>
            <!-- Taken with Sony A6000 -->
            <distortion model="ptlens" focal="18.0" a="0.02805" b="-0.10668" c="0.06382" />
            <distortion model="ptlens" focal="27.0" a="0.01683" b="-0.04455" c="0.03014" />
            <distortion model="ptlens" focal="38.0" a="-0.01212" b="0.06048" c="-0.07478" />
            <distortion model="ptlens" focal="53.0" a="-0.00924" b="0.05064" c="-0.06029" />
            <distortion model="ptlens" focal="60.0" a="-0.00417" b="0.0245" c="-0.02118" />
            <distortion model="ptlens" focal="86.0" a="-0.00333" b="0.02128" c="-0.02027" />
            <distortion model="ptlens" focal="100.0" a="0.01239" b="-0.03935" c="0.05252" />
            <distortion model="ptlens" focal="129.0" a="-0.00494" b="0.02116" c="-0.01855" />
            <distortion model="ptlens" focal="158.0" a="-0.00539" b="0.01724" c="-0.00662" />
            <distortion model="ptlens" focal="196.0" a="-0.02316" b="0.09408" c="-0.11133" />
            <distortion model="ptlens" focal="241.0" a="0.00321" b="-0.01004" c="0.01943" />
            <distortion model="ptlens" focal="277.0" a="0.01905" b="-0.04979" c="0.03944" />
            <distortion model="ptlens" focal="300.0" a="0.03685" b="-0.12817" c="0.15026" />
        </calibration>
    </lens>
</lensdatabase>

You can use it by saving the above file as lensfun.xml under ~/.local/share/lensfun/.

Enable TRIM on external LUKS encrypted drive

If you use an encrypted external SSD, you should periodically trim it. The first step would be to make sure the external drive itself supports trimming. The next step would be to make sure the LUKS partition on the device supports trimming as well. By default, encrypted filesystems do not support passing discard requests due to some security concerns. For example, crypttab man page states:

WARNING: Assess the specific security risks carefully before enabling this option. For example, allowing discards on encrypted devices may lead to the leak of information about the ciphertext device (filesystem type, used space etc.) if the discarded blocks can be located easily on the device later.

For most users, the benefit of TRIM outweigh those security concerns. The easiest way to enable TRIM is to pass the discard option in /etc/crypttab. For example:

cdisk0 UUID=12345678-9abc-def012345-6789abcdef01 none luks,discard

The problem with the /etc/crypttab approach is that it requires you to pre-configure your external drives. A better approach would be to enable discards at the LUKS configuration, which would apply automatically whenever the drive is used. This can be done in LUKS version 2 headers.

# cryptsetup --allow-discards --persistent refresh luks-643dc0f7-c876-4e37-9207-5c053a75fc70

Where luks-643dc0f7-c876-4e37-9207-5c053a75fc70 is the name of the mapping for the encrypted drive. You can verify that allow_discards is now part of the flag by dumping the LUKS header.

# cryptsetup luksDump /dev/sda4 | grep Flags
Flags:       	allow-discard

Now, you should be able to use fstrim to trim your external SSD with LUKS encryption drive.

Enable TRIM/discard on external SSD

First, find out whether your device already supports TRIM commands.

$ lsblk --discard

Non-zero values in the DISC-GRAN and DISC-MAX indicate support. If it looks like your external SSD doesn’t support trimming, then maybe it supports UNMAP which is equivalent (UNMAP is just in the SCSI command set vs TRIM which is in the ATA command set). Assuming your external drive is /dev/sda

# apt install sg3-utils
# sg_vpd -a /dev/sda | grep -i unmap

If the last command has Unmap command supported (LBPU): 1 it means the drive supports the UNMAP command. If it’s supported, and discard wasn’t supported, it’s likely the kernel didn’t detect the UNMAP support. You can verify it by reading /sys/block/sda/device/scsi_disk/0\:0\:0\:0/provisioning_mode

$ cat /sys/block/sda/device/scsi_disk/0\:0\:0\:0/provisioning_mode 
full

full means no support. As we know our device supports unmap we can manually instruct the kernel about it.

# echo "unmap" >/sys/block/sda/device/scsi_disk/0\:0\:0\:0/provisioning_mode

Now, lsblk --discard should report that the drive supports trimming, and you can use fstrim to trim it.

Making the change permanent

The changes above are ephemeral and will be reverted once you disconnect the drive. If you want to automatically apply those changes whenever your external drive is connected, we need to use udev rules.

Add the following rule to udev under /etc/udev/rules.d/90-usb-discard.rules

ACTION=="add|change", ATTRS{idVendor}=="0b05", ATTRS{idProduct}=="1932", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"

Replace idVendor and idProduct above with the corresponding values for your device, as can be found in the output of lsusb.

Reload the udev rules using

# udevadm control --reload