Good Morning from my Robotics Lab! This is Shadow_8472, and today, I believe I finally have the key holding back a number of my projects. I haven’t finished this week’s research as of starting writing, so I have no idea of how it turns out. Let’s get started!
Critical Path
Right now, my immediate long-term goal is getting photo archive pictures scanning, preferably with a custom script to streamline the process. For that, I need a reliable computer for processing photos — my laptop would work, but I’d feel a lot better if I had its long-term memories inside the case instead of hanging out for the world to snag. I would clone them inside with dd, but I’ve been holding out until I can perform a backup to the NAS. And that is where I’ve been stuck for a month or two: authentication to the NAS instead of by individual IP… until recently.
Kerberos
I often work on topics in parallel, switching on the last day if I don’t complete something. Last week, someone brought up Kerberos, an authentication protocol that’s been around since the mid-80’s, and if the Computerfile video, “Taming Kerberos,” is to be believed, it’s resistant to quantum attacks. And here is another video explaining Kerberos while addressing its weak points, something that most explanations overlook.
Named after the three-headed dog of Greek mythology, Cerberus, Kerberos follows a three-part model for authentication: client, host, and a mutually trusted authentication server. In simplified terms, you and the authentication server has two steps, one that uses cryptographic keys so both client and authentication server are sure they know each other, and another that issues tickets, or temporary passes, for desired hosts. Given a ticket, the host then does some final checks before conducting its normal business with the client.
Kerberos has more practical applications than just NAS authentication. It would appear OpenSSH is perfectly happy authenticating with it. I already have around 7 to 9 SSH-enabled devices and I don’t care to manually generate and distribute keys amongst everyone. And then there’s conflicting host keys when not everything is tied down to its own static IP and my Pi 4 I’m now swapping MicroSD cards on. I’ve resolved to just having one machine I SSH into that holds most of the keys I need and then SSH into the appropriate machine from there. In the future, I may even apply this technology for that website I’ve been working towards for almost a year now.
Compiling Kerberos
There are plenty of explanations of how Kerberos works out there. So many to the point where they clogged up my searches for actually finding an implementation of the method to use as a server. I eventually found what I believe to be the preferred download over at MIT. It does, however, come with a warning about exporting cryptographic source code from the US without permission, and that it’s illegal for it to go to a short list of countries or their nationals, though I did see some possible leeway for Canadians.
I intend to set my PackMan ghost-themed Raspberry Pi 3 (Codename: BlinkyPie) up as the host for this authentication server. With a significantly more powerful Pi in the house, it’s no longer my go-to for small scale computing, but since this is a very small scale job, processing speed and Ethernet bandwidth shouldn’t matter so much. I pulled it out of storage in plain sight and set it next to the NAS, near where I’ll need it for another project I’ve been putting off for years now. Of course, I’ll be wanting to lock that thing up tight once I have it going long-term. For now, I’ve set it up with a static IP where such a future system will go — right in there with our other network services.
The source code came in a tar file. I extracted it, but then remembered that it’s good practice to verify the download when possible. MIT provides a PGP signature. I’ve only worked with Shasums before, but it’s a similar idea: protect against corruption and tampering.
The PGP implementation I found to read about is called GPG. I had to look no farther than Blinky’s own Raspian operating system to find it was already included. It’s usually nice when a little tool you learn about is already within arm’s reach. I struggled around with reading the manual, its internal help page, and looking up use-cases online. I found their missing public key, tracked down an instruction set under “documentation” on how to compile from scratch, and was finally able to manually verify the signature for the tarball. Trying to verify the signature in a separate directory failed to produce the key, as expected.
My first attempt at building Kerberos failed. I stepped back to research details in the instruction set I previously glazed over, such as requiring ANSI C compliance.
At this point, I started to get some direct answers from members on the EngineerMan discord server. EngineerMan himself personally explained how ANSI C is just a longer name for the C language, but mostly older standards. He named c89, but said, “you won’t hear people call c18 ansi c though.”
My understanding of the situation is so: Imagine I have a big program I intend to maintain for 50+ years. I can write it to the standards present here in 2020. But if a new standard comes out in the meantime, I can either go through the bother of updating EVERYTHING each time –leaving myself open to any bugs that might crop up as a result– or I can just keep using the 2020 standards. If someone needs to compile it, the newer compiler can always be manually configured to run the older standard. Now just backdate the situation to 1989 or so and October 2020.
I tried recompiling a few times without changes, trying to sift through the overabundant console output. I think it was my third attempt where I stretched my terminal across two screens and beyond that I noticed several messages referencing missing files.
One iteration, I redirected the first phase’s output to a log file using the > operator, but two warnings about missing files went to the console anyway. One was for something called Tcl, and the other for OpenSSL. OpenSSL showed up when I looked for it, but Discord user jeffz popped in and talked me through getting the developer version. Additional packages had to be added, preferring development versions when available.
Eventually, I stabilized the configuration script (I think), at which point I copied the whole build directory to a backup. With help, I worked on brute forcing the actual compilation. Every time, a huge error log would plague me, sometimes with lines so long, it would take four screens to show the full line in tiny text. User yemou on the Nixhub Discord server spotted a tiny typo in the command fragment make CFLAGS=-std=c89. Most, but not all log activity went away after that. Oh, and jeffz pointed out some MIT Kerberos compilation instructions tailored for Debian-based distros.
Installing Kerberos From a Repository
I got close —real close– to successfully compiling. I learned a lot to file away, but when I explored that link jeffz gave me about MIT Kerberos installation on Debian, it went straight to the apt repository. I installed it and promptly messed up the admin-server package configuration.
Initial MIT Kerberos 5 configuration is unforgiving. I tried removing the packages and putting them back, but they found some other remnants to lock on to. I used the page linked above to track down and remove more mentions, but each time I plucked something out, it broke even worse. I saw someone in a similar situation asking for help. I quickly figured out how to purge when dealing with the repository, and was soon greeted with the configuration screen, though it still must have found something because it didn’t ask everything again. I read farther, and found where they were suggesting a clean install. Not what I wanted to hear, but it’s probably for the best.
This is where I sprouted off to work on last week’s topic, where I arranged for a personal master image of Raspberry Pi OS. On taking another look at the install script for Kerberos, I feel like I’m trying to install an engine to a horse and buggy — in theory it could work, but I’m getting asked questions about where the intake manifold or the gas tank are going to go. I’m spending more effort dodging the work of setting up static IP’s than I am just doing the original work.
Kerberos needs to go wait out in the dog house for a while. Who knows? Maybe I’ll revisit it in five years or so and play ball then.
Final Question
While exploring available Kerberos downloads, I happened across a development branch. They warned multiple times against the wrong people using it with decreasingly relevant warnings. They finally skill gated it by giving a set of instructions to keep the hopeless beginners out of trouble. Have you ever run across any skill gates?