HOWTO: Install Keybase on openSUSE Tumbleweed with signature verification and update repository

I’m a huge fan of keybase as well as openSUSE Tumbleweed but looking over the installation page, it doesn’t appear that openSUSE is among the supported Linux distributions.

Making it work, however, is only a tiny bit more difficult than setting it up for Fedora (which is to say, it’s not difficult at all). Since I end up doing this rather regularly, I thought I’d throw a HOWTO out there that I can refer back to. If you’re not me, then hey, hopefully I was able to help you out, too!

Note that I run 64-bit openSUSE Tumbleweed, as I assume you probably do, too. These instructions should work for the 32-bit version, however, I haven’t tested them. And, of course, while this works for me, it may not always work and may not work at all for you.

Before We Start - Fixing a few Things

Problem #1 - Missing Dependencies that Cannot be Resolved

Nevermind, they fixed this for me (love those folks!)

Problem #2 - The Package Signature Cannot be Verified

They don’t provide instructions for importing their signing key, so we’ll do this with rpm

# for users of zsh, the following one-liner works - run it and skip the rest
sudo rpm --import =(curl https://keybase.io/docs/server_security/code_signing_key.asc)

# If you're on bash, '=( ... )' isn't supported, but we can do the same with the following:
TMFILE="$(mktemp)"
curl https://keybase.io/docs/server_security/code_signing_key.asc > "$TMFILE"
sudo rpm --import "$TMFILE"
rm "$TMFILE

Installing with zypper

Follow the instructions on the download page for installing under Fedora, however, replace yum with zypper. As of the time of this writing, that command would be:

# Under bash/zsh
sudo zypper in -y https://prerelease.keybase.io/keybase_amd64.rpm
# If you're on the 32-bit version, you'd use:
sudo zypper in -y https://prerelease.keybase.io/keybase_i386.rpm
# ... or install the Windows 95 version (/s)

And, finally . . .

run_keybase
keybase login

Follow the install instructions for logging in for the first time (usually involves running keybase device add on another machine that is already logged in).

Making Upgrades work when zypper up or zypper dup is run

Keybase is updated … sheesh, it seems like daily, sometimes. But you’re running Tumbleweed, so installing 1,000 updates every week is kind of your thing. Unfortunately, the repo for keybase is not installed by default when zypper installs the keybase RPM, so we have to add it manually.

To get started, you should make sure that you do not have a reference to the keybase repo (who knows, maybe they’ve added support since I wrote this!)

sudo zypper lr

You should see something along the lines of …

# | Alias               | Name                        | Enabled | GPG Check | Refresh
--+---------------------+-----------------------------+---------+-----------+--------
1 | openSUSE-20181015-0 | openSUSE-20181015-0         | No      | ----      | ----   
2 | repo-debug          | openSUSE-Tumbleweed-Debug   | No      | ----      | ----   
3 | repo-non-oss        | openSUSE-Tumbleweed-Non-Oss | Yes     | (r ) Yes  | Yes    
4 | repo-oss            | openSUSE-Tumbleweed-Oss     | Yes     | (r ) Yes  | Yes    
5 | repo-source         | openSUSE-Tumbleweed-Source  | No      | ----      | ----   
6 | repo-update         | openSUSE-Tumbleweed-Update  | Yes     | (r ) Yes  | Yes    

That’s from a fresh install that I did on Saturday with nothing added beyond tmux and zsh to the default server configuration pattern.

If you don’t have a keybase repository, let’s add it:

sudo zypper ar -f http://prerelease.keybase.io/rpm/x86_64 keybase
sudo zypper --gpg-auto-import-keys refresh
# Presently you get a warning that the repomd.xml is unsigned; allow this, though it's not a great thing if you have security concerns

Performing an Update

Simple! Next time you do a zypper up or zypper dup, keybase’s repository will be checked and the software will be updated if it is modified.
However, don’t forget to run run_keybase after the software is updated or you’ll be using the previous version

A little while back I was looking for a way to add a handful of users to the authorized_keys file on some test servers.

This server necessarily required the existence of only one account that when troubleshooting was required, would be used to login/troubleshoot. These servers would be rebuilt every morning and it would have probably been fine to share a password and just login with shared credentials, but the security guy in me is allergic to enabling Challenge/Response authentication. The alternative – sharing a public/private keypair among users – is also a huge no-no⁰.

Unfortunately, where public/private keys were in use, they were generally generated by the users themselves – one of the perks of being at a dev shop with a bunch of folks who seriously know what they’re doing is that they have generally done this ‘correctly’, however, we didn’t have a central server that stored a record of the public keys for easy distribution.

Another side-effect of being at a dev shop is that many of the users were Keybase users. Unfortunately, Keybase keys are PGP keys, not SSH keys and the two key formats are not inter-changeable. Worse, still, is that they’re really not designed for the same purpose. In the GnuPG world, a key used for authentication would almost always have a sub-key for that purpose. Having been using my keybase key for login to SSH for a while, I’ve had a script (albiet, one that only works with gpg v1) to automate exporting the public/private keypair, making it easy to get the public key to the server with a simple ssh-copy-id, but what about when I have a few users I want to provision without ever handling their private key? I couldn’t find a good reference for doing that so I figured it out on my own.

Importing a GPG public key without the private key and without installing the keybase client

I wrote a shell script, located here, if you want to skip the details and just run it.

Simply login as the user you wish to add an authorized key to and:

chmod 770 ./authorizePublicKeybaseId.sh # only needed the first time
./authorizePublicKeybaseId.sh <id> # where ID is the keybase ID

It requires GnuPG 2 to execute (at least version 2.1.11) because it relies on a feature added in that version.

The script works by grabbing the public key via keybase.io’s public API (beta) and calling GnuPG 2 with the --export-ssh-key (forced with the “!”) to convert the key from GnuPG public key format to SSH public key format.

Because various distributions’ packagers install gpg in different ways, there’s a few checks to figure out which gpg binary is version 2 (often it’s gpg2) and a check to ensure the v2 binary is at the right minor/patch versions to successfully run the script. I also discovered some odd differences in the way that GnuPG 2 behaves between a few distributions – sometimes returning the 32-bit fingerprint rather than the 64-bit fingerprint, so I take an extra step to get the 64-bit fingerprint with some awk parsing.

Currently, this only handles grabbing the public key and it does so without touching the private key (which is something that requires a lot more delicate handling). I’m working on a script to download/import the private key (as well as password protect both the ssh private key and protect it in the GnuPG database). I’ll post that as soon as I’m comfortable that it’s somewhere resembling “safe”, but for the time being, there are several scripts out there that allow you to do this and I’ve tested a few of them against the method I’m using here. They all have worked.

⁰ I sort of hope I don’t have to explain why, but one big reason is that if one of those employees leaves the company, the shared credential has to be destroyed and removed from every host and a new one has to be issued to all of those users. If one uses