Ubuntu: Changing the Crypt (Plymouth) Login Screen

So, with all of this customisation of my Ubuntu machine going on, there had to be something else that I could configure, right? Well, there’s a lot, actually, but from the purely aesthetical point of view, the crypt screen was the next logical choice.

For those of you who may not be aware, and haven’t implemented encryption via Yubikey and LUKS, you can encrypt your volume and are forced to enter it on boot to get into the system. Think of it like BitLocker™ for Windows™®, only better.


Oh, yeah, that’s right: I said it…

Anyways, the first thing that you’ll want to do is find a Plymoth theme. There’s actually a site full of them, here, and there’s – arguably – hundreds (if not thousands) more that you could find across the internet.

So, first things first, we download the theme. In my case it was the Paw Ubuntu/Mint Floral theme, just for the sake of proof-of-concept and the aesthetic appeals to me. YYMV. However, this is the them being used in this haphazard “how-to”.

Once the file is downloaded, extract it. (NOTE: Make sure that the script’s name matches the folder name; otherwise, the later regex will fail.) Move the contents of the inner parent to the shared directory on Ubuntu:

$ sudo mv Paw-Ubuntu-Floral /usr/share/plymouth/themes/

Now that it’s copied, we need to tell Ubuntu to build a new boot screen with the one we just copied over. This is fairly easy to do (kind of) in all of three commands:

$ sudo update-alternatives --install /usr/share/plymouth/themes/default.plymouth default.plymouth /usr/share/plymouth/themes/Paw-Ubuntu-Floral/paw-ubuntu-floral.plymouth 100 $ sudo update-alternatives --config default.plymouth
Det finns 2 val för alternativet default.plymouth (som tillhandahåller /usr/share/plymouth/themes/default.plymouth).

  Val          Sökväg                                                                 Prioritet  Status
* 0            /usr/share/plymouth/themes/ubuntu-logo/ubuntu-logo.plymouth               100       automatiskt läge
  1            /usr/share/plymouth/themes/Paw-Ubuntu-Floral/paw-ubuntu-floral.plymouth   100       manuellt läge
  2            /usr/share/plymouth/themes/ubuntu-logo/ubuntu-logo.plymouth               100       manuellt läge

Tryck  för att behålla nuvarande val[*], eller ange urvalsnummer: 1       
update-alternatives: använder /usr/share/plymouth/themes/Paw-Ubuntu-Floral/paw-ubuntu-floral.plymouth för att tillhandahålla /usr/share/plymouth/themes/default.plymouth (default.plymouth) i manuellt läge

$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.15.0-46-generic

If you receive the following error, you probably didn’t verify the file name of the script, like I suggested in the section above:

W: plymouth module (/usr/lib/x86_64-linux-gnu/plymouth//.so) missing, skipping that theme.

If so, go back and change the name of the script and restart this entire process over from the beginning. (Yes, I know, which is why I cautioned you about it, before…)

Alright, assuming all went well, all you need to do, now, is to reboot and you’ll see your newfound plymouth theme when you’re prompted to input your credentials for the disk’s encryption.

Thanks for coming to this NERDTalk™ and happy Ubuntuing!

Ubuntu 18.04 (LTS): Disk Encryption with YubiKey

(WARNING: If you don’t read this, very carefully, you’ll shoot your eye out! If you do, might I suggest Bacon Pancakes to cheer you up? Or Christopher Walken dancing?)

The suggested soundtrack for this post comes from MASTER BOOT RECORD. The genre is called “chiptune” and a big shout-out to my friend, Wes, on keying me into them.

In one of my previous posts, I covered using the YubiKey to lock the machine when it’s removed. I intend to do one on configuring the machine to require the YubiKey for login but that’ll be for another day (if I get around to it). For now, the last remaining piece is to tie the disk’s encryption to the Yubikey, which is what we’ll be doing in this post.

The first thing that we’ll want to do is add the PPA for PrivacyIdea:

sudo add-apt-repository ppa:privacyidea/privacyidea

If your device is configured like mine, adding a PPA will automatically launch apt-get update. If not, then – of course – have apt-get update the list of available packages:

sudo apt-get update

Next, we’ll install the YubiKey-LUKS package that we need to tie the LUKS encryption to the YubiKey.

sudo apt-get install yubikey-luks

Since I’ve already used Slot 2 in the YubiKey for login, I’m going to use Slot 1 for the disk encryption. You’ll need to plug-in your YubiKey for this.

(BE FOREWARNED: You will nuke whatever key is currently in that slot. This is an unrecoverable action.):

ykpersonalize -1 -ochal-resp -ochal-hmac -ohmac-lt64 -oserial-api-visible

Then, we’ll need to add a new key to Slot 7, which will be used when you input your password to the challenge from Yubikey. (Read: It’s not actually your password being stored there.)

sudo yubikey-luks-enroll -d /dev/sda3 -s 7

As soon as you do this, Ubuntu should prompt you to reboot. Do so and verify that your new password works. If it doesn’t, your old password should still work to get into the drive.

Now that we’ve set it up and verified that it’s working, let’s delete the original password because we’re concerned with security, yeah?

First, let’s get a list of the slots and see which one is open:

sudo cryptsetup luksDump /dev/sda3
[sudo] lösenord för [REDACTED]: 
LUKS header information for /dev/sda3

Version:       	1
Cipher name:   	aes
Cipher mode:   	xts-plain64
Hash spec:     	sha256
Payload offset:	4096
MK bits:       	512
MK digest:     	[REDACTED] 
MK salt:       	[REDACTED] 
MK iterations: 	105194
UUID:          	a806d67c-9357-4860-a296-948be2090293

Key Slot 0: ENABLED
	Iterations:         	1683106
	Salt:               	[REDACTED] 
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: ENABLED
	Iterations:         	1583950
	Salt:               	[REDACTED] 
	Key material offset:	3536
	AF stripes:            	4000

Now that we know Slot 0 was the O.G. key holder (because we added to Slot 7 and the rest of the slots are disabled), we can target it for removal.

To do that, we’ll run the following command.

(BE FOREWARNED: You will deleting the only passphrase that doesn’t require the YubiKey to be present in the system. If you haven’t rebooted the machine to verify the passphrase+YubiKey combination, I strongly urge you not to do this step.):

sudo cryptsetup -q luksKillSlot /dev/sda3 0

To verify, let’s dump the LUKS Slots again (redacted for brevity):

Key Slot 0: DISABLED
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: ENABLED

And, now, the disk is only protected by the password+YubiKey combination. So, if the device gets stolen and the YubiKey isn’t in it (say, when I’m travelling), then the device is pretty useless – that is, unless you reformat it and start with new operating system.

Thanks for coming to this NERDTalk™ and I hope it helps you in your security endeavours in the future. 🙂

Ubuntu 18.04LTS: Auto-Locking When YubiKey is Removed

It took me a while to piece this together, so I figured that I would write a handy “how-to”, in order to prevent someone else from losing the man-hours that it took to piecemeal this together.

The first thing that we’ll need to do is to create the monitoring rule. This rule is specifically used to key-off of the event that is trigged when the YubiKey is removed; however, we’ll need some information for that before we can write the rule.

You can use the below command to obtain the device-specific information:

udevadm monitor --environment --udev

With the command running, remove the YubiKey device from the system. I would suggest copying all of the properties that you see in the output to a text file. We’ll use some of these to define your rule.

Right. So, let’s create the rule. Run this command to start the text editor:

sudo nano /etc/udev/rules.d/85-yubikey.rules

In the text editor, you’ll add the rule. Below is mine, for an example:

# Yubikey Udev Rule: running a bash script in case your Yubikey is removed 
ACTION=="remove", ENV{ID_VENDOR_ID}=="1050", ENV{ID_MODEL_ID}=="0401", RUN+="/usr/local/bin/gnome-screensaver-lock"

The most specific piece that you’ll copy, verbatum, is the overloaded “Run” section.

Press Ctrl+X in the text editor window, when you’re done. Press your key for confirmation (‘Y’ in English, ‘J’ in Swedish, etc.). Then press ‘Enter’ (a.k.a.: carriage return) to confirm the path we specified when we started the text editor.

You should now be back at the terminal.

Now that the rule is in place, we need to define the action. We’ve already declared where it will go to fetch the action definition (see the overloaded “Run” declaration above) and now we need to create that file.

Run this command to start the text editor:

sudo nano /usr/local/bin/gnome-screensaver-lock

Add the following code in the editor:

# Double checking if the Yubikey is actually removed
if [ -z "$(lsusb | grep Yubico)" ]
        logger "YubiKey Removed or Changed"
        sessionids=`/bin/loginctl list-sessions | grep <userAccount> | awk '{print $1}'`
        for id in $sessionids
                        logger "Locking session id:" $id
                        /bin/loginctl lock-session $id

(Be sure to change <userAccount> to your actual user account.)

Again, press Ctrl+X to start exiting the text editor. Press the confirmation key. Press the enter key to confirm the path.

The script that we just made must be made an executable for udev to be able to leverage it:

sudo chmod +x /usr/local/bin/gnome-screensaver-lock

Now that we have the rule and the actions defined, we need to tell the udevd service to reload the rules, so it’ll work. Run the following in the terminal:

sudo udevadm control --reload-rules
sudo service udev reload

Now, we should be able to remove the YubiKey device and Ubuntu should auto-lock.

If it doesn’t, you can try to monitor the udev service:

sudo service udev status
 systemd-udevd.service - udev Kernel Device Manager
   Loaded: loaded (/lib/systemd/system/systemd-udevd.service; static; vendor preset: enabled)
   Active: active (running) since Mon 2019-02-25 23:11:28 CET; 4 days ago
     Docs: man:systemd-udevd.service(8)
 Main PID: 482 (systemd-udevd)
   Status: "Processing with 24 children at max"
    Tasks: 1
   CGroup: /system.slice/systemd-udevd.service
           └─482 /lib/systemd/systemd-udevd

mar 02 22:39:58 Tradgardsforeningen mtp-probe[15598]: checking bus 1, device 30: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3"
mar 02 22:39:58 Tradgardsforeningen mtp-probe[15598]: bus: 1, device: 30 was not an MTP device
mar 02 22:43:17 Tradgardsforeningen systemd-udevd[15742]: Process '/usr/local/bin/gnome-screensaver-lock' failed with exit code 2.
mar 02 22:43:17 Tradgardsforeningen systemd-udevd[15749]: Process '/usr/local/bin/gnome-screensaver-lock' failed with exit code 2.
mar 02 22:43:20 Tradgardsforeningen mtp-probe[15759]: checking bus 1, device 31: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3"
mar 02 22:43:20 Tradgardsforeningen mtp-probe[15759]: bus: 1, device: 31 was not an MTP device
mar 02 22:48:00 Tradgardsforeningen mtp-probe[15901]: checking bus 1, device 32: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3"
mar 02 22:48:00 Tradgardsforeningen mtp-probe[15901]: bus: 1, device: 32 was not an MTP device
mar 02 22:49:26 Tradgardsforeningen mtp-probe[16019]: checking bus 1, device 33: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3"
mar 02 22:49:26 Tradgardsforeningen mtp-probe[16019]: bus: 1, device: 33 was not an MTP device

The above snippet is from when the executing script looked quite different and, thus, it was failing to execute. Keep in mind that you may need to define different parameters in your monitoring rule, for example, if your device has a different vendor or model id and the removal isn’t creating the logging event:

mar 02 23:00:15 Tradgardsforeningen root[16941]: YubiKey Removed or Changed

If you can see the event being logged, then verify that you specified the correct username in the script.

If all else fails, there’s Ask Ubuntu. 🙂

Thanks for coming to this TEDTalk and I hope that it helps prevent someone losing the hours that I lost. 🙂

Mass-Configuring OVPN in NetworkManager (on Ubuntu 18.04LTS)

So, I had a pretty large problem to figure out: How to configure 170+ different OVPN (Swedish/English) configurations in NetworkManager, without having to enter my username and password over 170 friggin’, fraggin’ times.

(NOTE: If you’re highly security conscious, then this probably isn’t going to be very palatable for you. You have been warned.)

I use [REDACTED] VPN service and they offer a zip file that you can download with containing multiple OVPN configuration files; a unique file for each server that you can use. After filtering the list down to my targets, I had a resultant list to import into Network Manager.

In order to have NetworkManager leverage ovpn, though, you need to install two packages, first.

sudo apt-get install network-manager-openvpn network-manager-openvpn-gnome

Bes sure to restart NetworkManager, afterwards, so you don’t end-up in a dissonant state.

sudo service network-manager restart

So, how do we do that? Well, it’s not as complicated as one my think and you needn’t go crafting anyting in Python or the like to do so.

for i in <location of your ovpn files>; do sudo nmcli connection import type openvpn file "$i"; done

Now that we have the files imported, we need to modify them. To do this, the easiest way is to use Python to read in the files and write our changes. Modify the script below to include your username and password.

#!/usr/bin/env python
"""Changes the exported OVPN configurations in NetworkManager to contain the username and password and autoconnect.

When mass-importing OVPN configuration files, it's necessary to overcome the hurdle of the prompt for passwords. This
script looks for the exported configuration files in NetworkManager. It writes the password configuration and the
username/password to the file. You will need to restart NetworkManager for the changes to be imported; however, it's
easier/better just to bounce the machine. (sudo init 6)

    sudo python3 ModifyOvpnConfigurations.py

__author__ = "felsokning"
__copyright__ = "Copyright 2019"
__license__ = "MIT"

import os
import re

source_directory = "/etc/NetworkManager/system-connections"
ovpn_files = os.listdir(source_directory)
i = 0
for ovpn in ovpn_files:
    opened_file = open(source_directory + "/" + ovpn, "r+")
    file_content = opened_file.read()
    if file_content.__contains__("mssfix=1450\n"):
        output = re.sub(r"mssfix=1450", r"mssfix=1450\npassword-flags=0", file_content)
        # TODO: Change '*' to be your username
        output2 = re.sub(r"tunnel-mtu=1500", "tunnel-mtu=1500\nusername=*", output)
        output3 = re.sub(r"service-type=org.freedesktop.NetworkManager.openvpn", r"service-type=org."
                                                                                 # TODO: Change '*' to your VPN password
        output4 = re.sub(r"password-flags=1", r"", output3)

        # Indents are important, m'kay? Without them, you do things like overwrite your wireless config files.
        # Take it from me: You do NOT want to do that.

Now that the files are modified, we need to restart NetworkManager to allow the configurations to be re-read on the connection’s instantiation.

sudo service network-manager restart

(Personally, bouncing the machine was more of a formidable option, here, but that’s because I messed-up the initial script – due to indenting – and wiped all of my configuration files; thus, the warning in the script.)

Now that this has been configured, I needed a way to randomly choose which VPN connection to use, so as to not always land on a static connection. To do this, I used Python again and randomised the choice of which VPN server to connect to. (You’ll note that I’m using a pretty large seed and that’s because the default random.random() method isn’t random in a secure manner [read: it’s predictable].)

#!/usr/bin/env python
"""Randomly connections to a random VPN profile (if any are found).

Uses NetworkManager (https://developer.gnome.org/NetworkManager/stable/gdbus-org.freedesktop.NetworkManager.html#) to
enumerate the devices and connections. First, we enumerate the wireless devices to ensure that we have one. Next, we
enumerate the VPN connections and put them into a list. After that, we randomly select one of the VPN connections to
connect to. Once we've accomplished this, we disconnect the current VPN connection (if one is found) and connect to
the randomly chosen VPN connection.


    python NetworkManager_VPN.py

__author__ = "felsokning"
__copyright__ = "Copyright 2019"
__license__ = "MIT"

import os
import random
import time
# Externals
import NetworkManager

# Find all of the VPN connections on the machine.
vpns = list()
current_vpn = None
wireless_device = None
connections = NetworkManager.Settings.ListConnections()
for c in connections:
    if "vpn" in c.GetSettings()['connection']['type']:
        path = c.object_path

# If there are no VPN connections, there's no point in proceeding.
if vpns.__len__() > 0:
    # We find the Wireless Network Interface.
    # If you're running some kind of weird, three wireless network cards situation, then...
    # Change this code to work in your use-case scenario.
    devices = NetworkManager.Device.all()
    for d in devices:
        if "wifi" in d.Driver:
            wireless_device = d

    # Validate that we found a wireless network interface
    if wireless_device is not None:
        # Get the currently active VPN connection.
        # If you're running some kind of weird, three active VPNs scenario, then...
        # Change this code to work in your use-case.
        active = NetworkManager.NetworkManager.ActiveConnections
        for a in active:
            if "vpn" in a.Type:
                current_vpn = a

        # Choose a random one to connect to. We use the far more secure random method, with a larger seed,
        # to try and prevent the random generation from being a predictable pattern (well, to try to make
        # it far less predictable with our sample, at least).
        rand = random.SystemRandom(os.urandom(99999999))
        random_int = rand.randint(0, (vpns.__len__() - 1))
        random_vpn = vpns.__getitem__(random_int)
        new_connection = NetworkManager.Connection(random_vpn)

        # Validate that we have a current VPN connection to disconnect from before we do.
        if current_vpn is not None:

            # Disconnect the old & busted.

            # To prevent collision in NetworkManager, we allow background clean-up before reconnecting.

        # Connect the new hotness.
        print("Connecting to: {}".format(random_vpn))
        NetworkManager.NetworkManager.ActivateConnection(new_connection, wireless_device, "/")

    # No wireless interfaces were found, so let's abort.
        raise Exception("No wireless interfaces were found.")

# No VPN connections were found, so let's abort.
    raise Exception("The hull has been breached and the science is leaking out! "
                    "(We didn't find any valid VPN connections on this machine via NetworkManager.)")

That should just about do it. …but WAIT! That’s not all! If you act now…

I’ve also written a script to remove all of the OVPN configurations from NetworkManager, in case you made a mistake somewhere (I know that I did and this came in pretty useful.)

#!/usr/bin/env python
"""Removes all VPN profiles found in NetworkManager.

Uses NetworkManager (https://developer.gnome.org/NetworkManager/stable/gdbus-org.freedesktop.NetworkManager.html#) to
enumerate the connections that are specifically VPN connections. Then, we delete them, with righteous retribution and


    python3 RemoveVPNs.py

__author__ = "felsokning"
__copyright__ = "Copyright 2019"
__license__ = "MIT"

import NetworkManager

# Find all of the VPN connections on the machine.
vpn_list = list()
connections = NetworkManager.Settings.ListConnections()
for c in connections:
    if "vpn" in c.GetSettings()['connection']['type']:

# We make sure we'e not spinning our wheels and/or calling delete on null.
if len(vpn_list) > 0:
    for v in vpn_list:
        print("Deleting: {}".format(v.object_path))

Now, you should have of the tools you need to mass-configure OVPN on your *nix (debian-based, probably) machine. 🙂

Happy coding!