Switching Blog Platforms soon…

I know I don’t get a lot of traffic, and I know I don’t post much, but I figured I’d give a notice to the void that I will be leaving the WordPress platform. Why? Well…

1.) Cost of using WordPress itself for what I used it for has went up. I may as well mess around with a VPS for super cheap and run a microblogging platform instead. Shout out to https://1984.hosting/ for decent VPSes.

2.) WordPress has reintroduced advertisements to plans that aren’t $15/month, or pay an additional fee on top of what I am already paying. I can’t really support them playing it both ways.

3.) While wordpress analytics are neat, I really don’t need to see that some dude from Europe viewed my post on Wayland that’s a few years old. To be honest this site feels increasingly like vanity- I just have it, it just exists. I should do more here that is meaningful.

We’ll see where it goes, but I don’t expect to renew my WordPress subscription.

Have I Been Pwned – Java Implementation!

Hey all,

So I got bored and decided to learn some Java. I wrote up a little app to determine whether or not your password has been compromised by testing it against the HIBP (https://haveibeenpwned.com/) database of known-compromised passwords. It’s not particularly complex, but it does ensure your password doesn’t actually leave your system by using the k-Anonymity model provided by HIBP in their APIs.

My code’s at https://github.com/Modusmundi/HIBP_Java, take a look!

Adding U2F to your Login in Linux!

So one thing I really appreciate about Yubikeys is that they force the issue of security.  They are a discrete, physical second factor. Don’t have your Yubikey? Good luck getting on to the system. This isn’t to say that somehow the Yubikey (Or similar, U2F-capable devices) will secure everything under the sun, and let’s be real there are always going to be side channel attacks, but the point of any endeavor in security is to delay a sufficiently motivated attacker until they A.) Get caught, or B.) Lose motivation. Traditionally, setting up second factor authentication on end-user boxes has been a bit of a pain, requiring an agent (Such as the old Windows Yubico agent that relied on a HMAC challenge-response setup) some other sort of implementation. Because of the nature of PAM this ties right in, and because it’s using FIDO2 it should be good to use for the foreseeable future.

Installing the plugin

I’m not going to belabor the process of installation of the U2F PAM component- Yubico does a great job outlining the basics here and outlining the details of of what pam_u2f can do here . While the instructions are geared towards Ubuntu, one could realistically use them for anything that relies on apt; heck, if one were so inclined they could roll their own off of the Yubico github, but that’s neither here nor there.

What I do want to do instead is discuss how I have it configured, why I configured it the way I did, and options.

A Word of Caution

So I need to be real with you here- modifying PAM is scary. Modifying PAM without knowing what you are doing can and will get you locked out of a system if you do it all in one shot. Always leave a terminal open that is ready to reverse changes if you mess up a change to, say, sudo or su. There is no faster way to need to run a live instance and rip apart a LUKS-encrypted partition to roll back PAM changes than to YOLO it here.

Be safe.

Pam.d Configuration

If you look at the Yubico developer documents, it’s a pretty straight-forward exercise. You will modify the relevant pam.d files to do what you want them to do- if for instance you want every PAM-related event to require the yubikey, you would modify your common auth file. If you want a more nuanced/sane approach, consider the following files to modify:

“Point of Entry” Scenarios – Places where someone might boot the PC, wake it, etc.
<If you rely on a screensaver and it ties into PAM, this would be a good place to lock up too>

“Ooops I left my computer unlocked” Scenarios

Where you are looking to modify is right after the “@include common-auth” line in these respective files.

An example for how to set this beast up in PAM might be the following-

 auth required pam_u2f.so prompt nodetect cue nouserok authfile=/etc/yubico/u2f_keys 

What this does for us, the consumer, is the following:

  • Prompt for a Yubikey if one isn’t inserted.
  • Prompt for us to press the button.
  • Mitigates revealing information about the authentication stack if a token is inserted but not properly configured.
  • Allows users who are not currently configured to use u2f (Other accounts not yet configured?) to log in.

Assuming you’re slightly more paranoid and want as little as possible revealed about what is going on or why you have a weird looking USB thumb drive in your PC, you can use the following configuration:

 auth required pam_u2f.so authfile=/etc/yubico/u2f_keys 

In this case the Yubikey will simply blink (Like it did during initial configuration), you press the button, and if it is set up to the user it succeeds and lets you in.

Go foward, and be safe.

Recent Stuff I Wrote Elsewhere!

So, I’m still working for IDMWorks, and I recently put out a three-part series on SSSD, how it works, and some things to consider if you decide to implement it.

Part 1 goes into what centralized authentication is

Part 2 talks about why SSSD is overtaking older solutions in the Linux Space:

Part 3 talks about the two real ways to deal with sudoer privileges in Linux when using SSSD:

USB Mis-adventures in 3D Printing…

So a few months back at Converge Detroit (https://www.convergeconference.org/) I ended up winning second place in the CTF they run, and I acquired a 3d printer.  Since then, I’ve been doing a lot of tinkering with a Wanhao i3 PLUS and a recent project of mine has been to replace the internals of it entirely with an SKR Mini v1.1(Link here).  It’s been challenging, to say the least- hardware selection and making sure it fits the form factor, learning about how all of it is really wired together, compiling my own firmware to put on the new mainboard, and so on.  It’s been slow going because real life comes first, but it’s been pretty rewarding because every issue has been solvable so far, and every issue has been explainable by either something in code, or something in the physical properties of what is being set up.

That is, until I tried to hook up an OctoPi (https://octoprint.org/) instance to the printer to start troubleshooting some nagging issues I was having with endstops..  The brave little Raspberry Pi refused to enumerate the printer.  Things I tried included (But weren’t limited to)…

  • Scouring dmesg for anything USB-related after clearing it from boot (Plugging and unplugging did nothing)
  • Using lspci, lsusb and so on to watch for weird enumerations and running down anything that didn’t make sense (Again, dead end).
  • Running ls /dev/tty* to see if I could see anything enumerated.  Nada.

Basically, nothing was showing up.  I was flummoxed.  So I started poking around with the SKR Mini and testing it against other ways to access the board.  It turned out I could access the board and send GCode through Pronterface, and similar tools on Windows.  So I figured- could the USB on the Raspberry Pi 4 be the issue?

It turns out the Pi 4 runs off of a Via Labs VL805 chip for USB.  Looking through recent issues for Raspbian as well as issues for the VL805 chip in general it looks like there has been a history of issues similar to this related to the VL805.  To try and isolate the issue further, I tried Octoprint on an older Raspberry Pi 3, which runs off of a Broadcom BCM2835.  It turns out the Raspberry Pi 3 detected the SKR Mini just fine.

So at this point, I have tested across multiple OSes (Running different drivers), and across multiple chipsets.  Everything points to the VL805 being the root cause, which is unfortunate.  I guess I’ll be opening up an issue on their Github over the next few weeks once I get some time.  We’ll see where it goes.

New Kimchi version soon!

So I know I don’t post often, however if there is one thing I do it’s tinker.  Kimchi, a beautiful and robust KVM management interface done in HTML5, facilitates that- and unfortunately it’s been without a solid release for two years.  A lot of issues have cropped up since then, and I even posted about one of the fixes you have to do in order to get stuff working- fortunately I didn’t run into too many more issues beyond that, but if you look through the Github issues page for it there are a whole mess of issues that got brought up.

However, that’s going to change!  It turns out one of the head people behind it took a break from the codebase and has since come back!


There’s no firm ETA (Which is fair, let’s be real here it’s FOSS), but the fact that it’s still being developed warms my heart.  Wok (And Kimchi, which runs off of it) are great and any forward movement is good movement.

Introducing Paustachio!

So I wrote a thing- basically it performs LDAP queries and gets the counts from them so you don’t have to.  I did it to learn test-driven development; it’s a rework of an old project I did in Powershell using a very specific client (Which was…  Okay but very reliant on a specific technology stack), which was reworked into a fairly rough Python implementation (Which was a mess) and I distilled it into this (Which is less of a mess).

I have eventual plans for it- right now it only supports non-TLS LDAP (Which is terrible) and takes no command-line user input (Which would make it way more useful), but it’s a start.

It’s in Python, which I figure is probably a better choice over the long haul than Java.  We’ll see where it goes.


Netplan for Newbies!

I started working for a firm called IDMWorks, and I am grateful to be a part of the team.  I’m fulfilling a lead technical role with regards to Forgerock and RadiantLogic, and I’m sure I’ll have my hands full over the coming months.

That said, I recently wrote an article for IDMWorks called “Netplan for Newbies” regarding the new network configuration tools being put into Ubuntu’s LTS setup.

You can read the full article here.

Wayland is Painful for VNC.

So in setting up Ubuntu 17.10 on a remote server, you might naturally wish to set up VNC on your box because let’s face it, monitor connectivity is at a premium and command-line wizardry, while amazing, isn’t the best way to go for everyone.

Something to consider is that As of 17.10, the default display server is Wayland. Wayland’s great for a default user experience, but for VNC (As well as other screen sharing apps) it is an absolute trainwreck. In fact, for the upcoming 18.04 LTS release in April XOrg will end up becoming the default display server again- you can read more about the rationale here.

So what’s a VNC user to do? Well, you have two real options.

First option is to straight up remove the Wayland session. There’s info on that here, which I haven’t tried but assume it isn’t far off from working.

The second option is to use a shell that relies on XOrg, such as xfce, and use that as your GUI on the box.  Here is a pretty solid article on how to set that up.

Something you need to keep in mind is that VNC, by default, is really not that secure. With an 8 character password max, several glaring flaws in managing it at scale, and so on- actually, let me just drop this, a link to an old but still incredibly relevant blog post on why VNC can be a minefield.  A good practice with VNC is to force localhost only connections to the service, which requires SSH tunneling.  Please do this, even if in a home environment.
Please.  Think of Bob Barker.

Kimchi can give you heartburn…

So, what you might notice if you try to load up one of the latest OSes as a guest in Kimchi is that you get an error.

“Error KCHIMG0001E while creating template: “physical block size is 2048 bytes, but Linux says it is 512 bytes.”

Thankfully, this is a quick fix and already patched but not yet in stable as of the time of this writing.

Here is where the issue is discussed, and the patch can be found in this commit:


Once you apply the patch appropriately and restart wokd, Kimchi should work appropriately.