Ansible Part 1: DevOps for the Non-Dev

I’ve written about and trained folks on various DevOps tools through the years, and although they’re awesome, it’s obvious that most of them are designed from the mind of a developer. There’s nothing wrong with that, because approaching configuration management programmatically is the whole point. Still, it wasn’t until I started playing with Ansible that I felt like it was something a sysadmin quickly would appreciate.

Part of that appreciation comes from the way Ansible communicates with its client computers—namely, via SSH. As sysadmins, you’re all very familiar with connecting to computers via SSH, so right from the word “go”, you have a better understanding of Ansible than the other alternatives.

With that in mind, I’m planning to write a few articles exploring how to take advantage of Ansible. It’s a great system, but when I was first exposed to it, it wasn’t clear how to start. It’s not that the learning curve is steep. In fact, if anything, the problem was that I didn’t really have that much to learn before starting to use Ansible, and that made it confusing. For example, if you don’t have to install an agent program (Ansible doesn’t have any software installed on the client computers), how do you start?

Getting to the Starting Line

The reason Ansible was so difficult for me at first is because it’s so flexible with how to configure the server/client relationship, I didn’t know what I was supposed to do. The truth is that Ansible doesn’t really care how you set up the SSH system; it will utilize whatever configuration you have. There are just a couple things to consider:

  1. Ansible needs to connect to the client computer via SSH.
  2. Once connected, Ansible needs to elevate privilege so it can configure the system, install packages and so on.

Unfortunately, those two considerations really open a can of worms. Connecting to a remote computer and elevating privilege is a scary thing to allow. For some reason, it feels less vulnerable when you simply install an agent on the remote computer and let Chef or Puppet handle privilege escalation. It’s not that Ansible is any less secure, but rather, it puts the security decisions in your hands.

Next I’m going to list a bunch of potential configurations, along with the pros and cons of each. This isn’t an exhaustive list, but it should get you thinking along the right lines for what will be ideal in your environment. I also should note that I’m not going to mention systems like Vagrant, because although Vagrant is wonderful for building a quick infrastructure for testing and developing, it’s so very different from a bunch of servers that the considerations are too dissimilar really to compare.

Some SSH Scenarios

1) SSHing into remote computer as root with password in Ansible config.

I started with a terrible idea. The “pros” of this setup is that it eliminates the need for privilege escalation, and there are no other user accounts required on the remote server. But, the cost for such convenience isn’t worth it. First, most systems won’t let you SSH in as root without changing the default configuration. Those default configurations are there because, quite frankly, it’s just a bad idea to allow the root user to connect remotely. Second, putting a root password in a plain-text configuration file on the Ansible machine is mortifying. Really, I mentioned this possibility because it is a possibility, but it’s one that should be avoided. Remember, Ansible allows you to configure the connection yourself, and it will let you do really dumb things. Please don’t.

2) SSHing into a remote computer as a regular user, using a password stored in the Ansible config.

An advantage of this scenario is that it doesn’t require much configuration of the clients. Most users are able to SSH in by default, so Ansible should be able to use credentials and log in fine. I personally dislike the idea of a password being stored in plain text in a configuration file, but at least it isn’t the root password. If you use this method, be sure to consider how privilege escalation will take place on the remote server. I know I haven’t talked about escalating privilege yet, but if you have a password in the config file, that same password likely will be used to gain sudo access. So with one slip, you’ve compromised not only the remote user’s account, but also potentially the entire system.

3) SSHing into a remote computer as a regular user, authenticating with a key pair that has an empty passphrase.

This eliminates storing passwords in a configuration file, at least for the logging in part of the process. Key pairs without passphrases aren’t ideal, but it’s something I often do in an environment like my house. On my internal network, I typically use a key pair without a passphrase to automate many things like cron jobs that require authentication. This isn’t the most secure option, because a compromised private key means unrestricted access to the remote user’s account, but I like it better than a password in a config file.

4) SSHing into a remote computer as a regular user, authenticating with a key pair that is secured by a passphrase.

This is a very secure way of handling remote access, because it requires two different authentication factors: 1) the private key and 2) the passphrase to decrypt it. If you’re just running Ansible interactively, this might be the ideal setup. When you run a command, Ansible should prompt you for the private key’s passphrase, and then it’ll use the key pair to log in to the remote system. Yes, the same could be done by just using a standard password login and not specifying the password in the configuration file, but if you’re going to be typing a password on the command line anyway, why not add the layer of protection a key pair offers?

5) SSHing with a passphrase-protected key pair, but using ssh-agent to “unlock” the private key.

This doesn’t perfectly answer the question of unattended, automated Ansible commands, but it does make a fairly secure setup convenient as well. The ssh-agent program authenticates the passphrase one time and then uses that authentication to make future connections. When I’m using Ansible, this is what I think I’d like to be doing. If I’m completely honest, I still usually use key pairs without passphrases, but that’s typically because I’m working on my home servers, not something prone to attack.

There are some other considerations to keep in mind when configuring your SSH environment. Perhaps you’re able to restrict the Ansible user (which is often your local user name) so it can log in only from a specific IP address. Perhaps your Ansible server can live in a different subnet, behind a strong firewall so its private keys are more difficult to access remotely. Maybe the Ansible server doesn’t have an SSH server installed on itself so there’s no incoming access at all. Again, one of the strengths of Ansible is that it uses the SSH protocol for communication, and it’s a protocol you’ve all had years to tweak into a system that works best in your environment. I’m not a big fan of proclaiming what the “best practice” is, because in reality, the best practice is to consider your environment and choose the setup that fits your situation the best.

Privilege Escalation

Once your Ansible server connects to its clients via SSH, it needs to be able to escalate privilege. If you chose option 1 above, you’re already root, and this is a moot point. But since no one chose option 1 (right?), you need to consider how a regular user on the client computer gains access. Ansible supports a wide variety of escalation systems, but in Linux, the most common options are sudo and su. As with SSH, there are a few situations to consider, although there are certainly other options.

1) Escalate privilege with su.

For Red Hat/CentOS users, the instinct might be to use su in order to gain system access. By default, those systems configure the root password during install, and to gain privileged access, you need to type it in. The problem with using su is that although it gives you total access to the remote system, it also gives you total access to the remote system. (Yes, that was sarcasm.) Also, the su program doesn’t have the ability to authenticate with key pairs, so the password either must be interactively typed or stored in the configuration file. And since it’s literally the root password, storing it in the config file should sound like a horrible idea, because it is.

2) Escalate privilege with sudo.

This is how Debian/Ubuntu systems are configured. A user in the correct group has access to sudo a command and execute it with root privileges. Out of the box, this still has the problem of password storage or interactive typing. Since storing the user’s password in the configuration file seems a little less horrible, I guess this is a step up from using su, but it still gives complete access to a system if the password is compromised. (After all, typing sudo su - will allow users to become root just as if they had the root password.)

3) Escalate privilege with sudo and configure NOPASSWD in the sudoers file.

Again, in my local environment, this is what I do. It’s not perfect, because it gives unrestricted root access to the user account and doesn’t require any passwords. But when I do this, and use SSH key pairs without passphrases, it allows me to automate Ansible commands easily. I’ll note again, that although it is convenient, it is not a terribly secure idea.

4) Escalate privilege with sudo and configure NOPASSWD on specific executables.

This idea might be the best compromise of security and convenience. Basically, if you know what you plan to do with Ansible, you can give NOPASSWD privilege to the remote user for just those applications it will need to use. It might get a little confusing, since Ansible uses Python for lots of things, but with enough trial and error, you should be able to figure things out. It is more work, but does eliminate some of the glaring security holes.

Implementing Your Plan

Once you decide how you’re going to handle Ansible authentication and privilege escalation, you need to set it up. After you become well versed at Ansible, you might be able to use the tool itself to help “bootstrap” new clients, but at first, it’s important to configure clients manually so you know what’s happening. It’s far better to automate a process you’re familiar with than to start with automation from the beginning.

I’ve written about SSH key pairs in the past, and there are countless articles online for setting it up. The short version, from your Ansible computer, looks something like this:

# ssh-keygen
# ssh-copy-id -i .ssh/
# ssh

If you’ve chosen to use no passphrase when creating your key pairs, that last step should get you into the remote computer without typing a password or passphrase.

In order to set up privilege escalation in sudo, you’ll need to edit the sudoers file. You shouldn’t edit the file directly, but rather use:

# sudo visudo

This will open the sudoers file and allow you to make changes safely (it error-checks when you save, so you don’t accidentally lock yourself out with a typo). There are examples in the file, so you should be able to figure out how to assign the exact privileges you want.

Once it’s all configured, you should test it manually before bringing Ansible into the picture. Try SSHing to the remote client, and then try escalating privilege using whatever methods you’ve chosen. Once you have configured the way you’ll connect, it’s time to install Ansible.

Installing Ansible

Since the Ansible program gets installed only on the single computer, it’s not a big chore to get going. Red Hat/Ubuntu systems do package installs a bit differently, but neither is difficult.

In Red Hat/CentOS, first enable the EPEL repository:

sudo yum install epel-release

Then install Ansible:

sudo yum install ansible

In Ubuntu, first enable the Ansible PPA:

sudo apt-add-repository spa:ansible/ansible
(press ENTER to access the key and add the repo)

Then install Ansible:

sudo apt-get update
sudo apt-get install ansible

Configuring Ansible Hosts File

The Ansible system has no way of knowing which clients you want it to control unless you give it a list of computers. That list is very simple, and it looks something like this:

# file /etc/ansible/hosts


blogserver ansible_host= wikiserver ansible_host=


mysql_1 ansible_host= pgsql_1 ansible_host=

The bracketed sections are specifying groups. Individual hosts can be listed in multiple groups, and Ansible can refer either to individual hosts or groups. This is also the configuration file where things like plain-text passwords would be stored, if that’s the sort of setup you’ve planned. Each line in the configuration file configures a single host, and you can add multiple declarations after the ansible_host statement. Some useful options are:


The Ansible Vault

I also should note that although the setup is more complex, and not something you’ll likely do during your first foray into the world of Ansible, the program does offer a way to encrypt passwords in a vault. Once you’re familiar with Ansible and you want to put it into production, storing those passwords in an encrypted Ansible vault is ideal. But in the spirit of learning to crawl before you walk, I recommend starting in a non-production environment and using passwordless methods at first.

Testing Your System

Finally, you should test your system to make sure your clients are connecting. The ping test will make sure the Ansible computer can ping each host:

ansible -m ping all

After running, you should see a message for each defined host showing a ping: pong if the ping was successful. This doesn’t actually test authentication, just the network connectivity. Try this to test your authentication:

ansible -m shell -a 'uptime' webservers

You should see the results of the uptime command for each host in the webservers group.

In a future article, I plan start to dig in to Ansible’s ability to manage the remote computers. I’ll look at various modules and how you can use the ad-hoc mode to accomplish in a few keystrokes what would take a long time to handle individually on the command line. If you didn’t get the results you expected from the sample Ansible commands above, take this time to make sure authentication is working. Check out the Ansible docs for more help if you get stuck.

If you’d like more direct training on Ansible (and other stuff) from yours truly, visit me at my DayJob as a trainer for CBT Nuggets. You can get a full week free if you head over to and sign up for a trial!

The 4 Part Series on Ansible includes:
Part 1 – DevOps for the Non-Dev
Part 2 – Making Things Happen
Part 3 – Playbooks
Part 4 – Putting it All Together

Have a Plan for Netplan

Ubuntu changed networking. Embrace the YAML.

If I’m being completely honest, I still dislike the switch from eth0, eth1, eth2 to names like, enp3s0, enp4s0, enp5s0. I’ve learned to accept it and mutter to myself while I type in unfamiliar interface names. Then I installed the new LTS version of Ubuntu and typed vi /etc/network/interfaces. Yikes. After a technological lifetime of entering my server’s IP information in a simple text file, that’s no longer how things are done. Sigh. The good news is that while figuring out Netplan for both desktop and server environments, I fixed a nagging DNS issue I’ve had for years (more on that later).

The Basics of Netplan

The old way of configuring Debian-based network interfaces was based on the ifupdown package. The new default is called Netplan, and although it’s not terribly difficult to use, it’s drastically different. Netplan is sort of the interface used to configure the back-end dæmons that actually configure the interfaces. Right now, the back ends supported are NetworkManager and networkd.

If you tell Netplan to use NetworkManager, all interface configuration control is handed off to the GUI interface on the desktop. The NetworkManager program itself hasn’t changed; it’s the same GUI-based interface configuration system you’ve likely used for years.

If you tell Netplan to use networkd, systemd itself handles the interface configurations. Configuration is still done with Netplan files, but once “applied”, Netplan creates the back-end configurations systemd requires. The Netplan files are vastly different from the old /etc/network/interfaces file, but it uses YAML syntax, and it’s pretty easy to figure out.

The Desktop and DNS

If you install a GUI version of Ubuntu, Netplan is configured with NetworkManager as the back end by default. Your system should get IP information via DHCP or static entries you add via GUI. This is usually not an issue, but I’ve had a terrible time with my split-DNS setup and systemd-resolved. I’m sure there is a magical combination of configuration files that will make things work, but I’ve spent a lot of time, and it always behaves a little oddly. With my internal DNS server resolving domain names differently from external DNS servers (that is, split-DNS), I get random lookup failures. Sometimes ping will resolve, but dig will not. Sometimes the internal A record will resolve, but a CNAME will not. Sometimes I get resolution from an external DNS server (from the internet), even though I never configure anything other than the internal DNS!

I decided to disable systemd-resolved. That has the potential to break DNS lookups in a VPN, but I haven’t had an issue with that. With resolved handling DNS information, the /etc/resolv.conf file points to as the nameserver. Disabling systemd-resolved will stop the automatic creation of the file. Thankfully, NetworkManager itself can handle the creation and modification of /etc/resolv.conf. Once I make that change, I no longer have an issue with split-DNS resolution. It’s a three-step process:

  1. Do sudo systemctl disable systemd-resolved.service.
  2. Then sudo rm /etc/resolv.conf (get rid of the symlink).
  3. Edit the /etc/NetworkManager/NetworkManager.conf file, and in the [main] section, add a line that reads DNS=default.

Once those steps are complete, NetworkManager itself will create the /etc/resolv.conf file, and the DNS server supplied via DHCP or static entry will be used instead of a entry. I’m not sure why the resolved dæmon incorrectly resolves internal addresses for me, but the above method has been foolproof, even when switching between networks with my laptop.

Netplan CLI Configuration

If Ubuntu is installed in server mode, it is almost certainly configured to use networkd as the back end. To check, have a look at the /etc/netplan/config.yaml file. The renderer should be set to networkd in order to use the systemd-networkd back end. The file should look something like this:

  version: 2
  renderer: networkd
      dhcp4: true

Important note: remember that with YAML files, whitespace matters, so the indentation is important. It’s also very important to remember that after making any changes, you need to run sudo netplan apply so the back-end configuration files are populated.

The default renderer is networkd, so it’s possible you won’t have that line in your configuration file. It’s also possible your configuration file will be named something different in the /etc/netplan folder. All .conf files are read, so it doesn’t matter what it’s called as long as it ends with .conf. Static configurations are fairly simple to set up:

  version: 2
  renderer: networkd
      dhcp4: no
        addresses: [,]

Notice I’ve assigned multiple IP addresses to the interface. Netplan does not support virtual interfaces like enp3s0:0, rather multiple IP addresses can be assigned to a single interface.

Unfortunately, networkd doesn’t create an /etc/resolv.conf file if you disable the resolved dæmon. If you have problems with split-DNS on a headless computer, the best solution I’ve come up with is to disable systemd-resolved and then manually create an /etc/resolv.conf file. Since headless computers don’t usually move around as much as laptops, it’s likely the /etc/resolv.conf file won’t need to be changed. Still, I wish networkd had an option to manage the resolv.conf file the same way NetworkManager does.

Advanced Network Configurations

The configuration formats are different, but it’s still possible to do more advanced network configurations with Netplan:


  version: 2
  renderer: networkd
      dhcp4: yes
        - enp2s0
        - enp3s0
        mode: active-backup
        primary: enp2s0

The various bonding modes (balance-rractive-backupbalance-xorbroadcast802.3adbalance-tlb and balance-alb) are supported.


  version: 2
  renderer: networkd
      dhcp4: yes
        - enp4s0
        - enp3s0

Bridging is even simpler to set up. This configuration creates a bridge device using the two interfaces listed. The device (br0) gets address information via DHCP.

CLI Networking Commands

If you’re a crusty old sysadmin like me, you likely type ifconfig to see IP information without even thinking. Unfortunately, those tools are not usually installed by default. This isn’t actually the fault of Ubuntu and Netplan; the old ifconfig toolset has been deprecated. If you want to use the old ifconfig tool, you can install the package:

sudo apt install net-tools

But, if you want to do it the “correct” way, the new “ip” tool is the proper way to do it. Here are some equivalents of things I commonly do with ifconfig:

Show network interface information.

Old way:


New way:

ip address show

(Or you can just do ip a, which is actually less typing than ifconfig.)

Bring interface up.

Old way:

ifconfig enp3s0 up

New way:

ip link set enp3s0 up

Assign IP address.

Old way:

ifconfig enp3s0

New way:

ip address add dev enp3s0

Assign complete IP information.

Old way:

ifconfig enp3s0 net mask broadcast

New way:

ip address add broadcast
 ↪dev enp3s0

Add alias interface.

Old way:

ifconfig enp3s0:0

New way:

ip address add dev enp3s0 label enp3s0:0

Show the routing table.

Old way:


New way:

ip route show

Add route.

Old way:

route add -net dev enp4s0

New way:

ip route add dev enp4s0

Old Dogs and New Tricks

I hated Netplan when I first installed Ubuntu 18.04. In fact, on the particular server I was installing, I actually started over and installed 16.04 because it was “comfortable”. After a while, curiosity got the better of me, and I investigated the changes. I’m still more comfortable with the old /etc/network/interfaces file, but I have to admit, Netplan makes a little more sense. There is a single “front end” for configuring networks, and it uses different back ends for the heavy lifting. Right now, the only back ends are the GUI NetworkManager and the systemd-networkd dæmon. With the modular system, however, that could change someday without the need to learn a new way of configuring interfaces. A simple change to the renderer line would send the configuration information to a new back end.

With regard to the new command-line networking tool (ip vs. ifconfig), it really behaves more like other network devices (routers and so on), so that’s probably a good change as well. As technologists, we need to be ready and eager to learn new things. If we weren’t always trying the next best thing, we’d all be configuring Trumpet Winsock to dial in to the internet on our Windows 95 machines. I’m glad I tried that new Linux thing, and while it wasn’t quite as dramatic, I’m glad I tried Netplan as well!

If you’re interested in learning from me directly, my day job is a Linux trainer at CBT Nuggets. There’s TONS of training available, on Linux, Cisco, Microsoft, etc., and you get a full week free when you sign up. It’s like drinking from the firehose of tech knowledge!

Password Managers. Yes You Need One.

If you can remember all of your passwords, they’re not good passwords.

I used to teach people how to create “good” passwords. Those passwords needed to be lengthy, hard to guess and easy to remember. There were lots of tricks to make your passwords better, and for years, that was enough.

That’s not enough anymore.

It seems that another data breach happens almost daily, exposing sensitive information for millions of users, which means you need to have separate, secure passwords for each site and service you use. If you use the same password for any two sites, you’re making yourself vulnerable if any single database gets compromised.

There’s a much bigger conversation to be had regarding the best way to protect data. Is the “password” outdated? Should we have something better by now? Granted, there is two-factor authentication, which is a great way to help increase the security on accounts. But although passwords remain the main method for protecting accounts and data, there needs to be a better way to handle them—that’s where password managers come into play.

The Best Password Manager

No, I’m not burying the lede by skipping to all the reviews. As Doc Searls, Katherine Druckman and myself discussed in Episode 8 of the Linux Journal Podcast, the best password manager is the one you use. It may seem like a cheesy thing to say, but it’s a powerful truth. If it’s more complicated to use a password manager than it is to re-use the same set of passwords on multiple sites, many people will just choose the easy way.

Sure, some people are geeky enough to use a password manager at any cost. They understand the value of privacy, understand security, and they take their data very seriously. But for the vast majority of people, the path of least resistance is the way to go. Heck, I’m guilty of that myself in many cases. I have a Keurig coffee machine, not because the coffee is better, but because it’s more convenient. If you’ve ever eaten a Hot Pocket instead of cooking a healthy meal, you can understand the mindset that causes people to make poor password choices. If the goal is having smart passwords, it needs to be easier to use smart passwords than to type “password123” everywhere.

The Reason It Might Work Now

Mobile devices have become the way most people do most things online. Heck, Elon Musk said that we’ve become cybernetic beings, it’s just that the bandwidth to our cybernetic components is really slow (that is, typing on our phones). It’s always been possible to have some sort of password management app on your phone, but until recently, the operating systems didn’t integrate with password managers. That meant you’d have to go from one app into your password manager, look up the site/app, copy the password, switch back to the app, paste the password, and then hope you got it right. Those days are thankfully in the past.

Both recent Android systems and iOS (Apple, not Cisco) versions allow third-party password managers to integrate directly into the data entry system. That means when you’re using a keyboard to type in a login or password, in any app, you can pull in a password manager and enter the data directly with no app switching. Plus, if you have biometrics enabled, most of the time you can unlock your password database with a fingerprint or a view of your face. (For those concerned about the security of biometric-only authentication, it can, of course, be turned off, but remember how important ease of use is for most people!)

So although password managers have been around for years and years, I truly believe it’s only with the advent of their integration into the main operating system of mobile devices that people will actually be able to use them widely. Not all Linux users will agree with me, and not all people in general will want their passwords available in such an easy manner. For the purpose of this article, however, a mobile option is a necessity.

A Tale of Two Concepts

Remember when “the cloud” was a buzzword that didn’t really mean anything specific, but people used it all the time anyway? Well, now it very clearly means servers or services run on computers you don’t own, in data centers you don’t control. The “cloud” is both awesome and terrible. When it comes to storing password data, many people are rightfully concerned about cloud storage. When it comes to password managers, there are basically two types: the kind that stores everything in a local database file and those that store the database in the cloud.

The cloud-based storage isn’t as unsettling as it seems. When the database is stored on the “servers in the sky”, it’s encrypted before it leaves your device. Those companies don’t have access to your actual passwords, just the highly encrypted database that holds them—as long as you trust the companies to be honest about such things. For what it’s worth, I do think the major companies are fairly trustworthy about keeping their grubby mitts off your actual passwords. Still, with the closed-source options, a level of trust is required that some people just aren’t willing to give. I’m going to look at password managers from both camps.

The Contenders

I picked five(-ish) password managers for this review. Please realize there are dozens and dozens of very usable, very secure, password managers for Linux. Some are command-line only. Some are just basic PGP encryption of text files containing user name/password pairs. Today’s review is not meant to be all-encompassing; it’s meant to be helpful for average Linux users who want to handle their passwords better than they currently do. I say five(-ish), because one of the entries has multiple versions. The list is:

  1. KeePass/KeePassX/KeePassXC: this is the one(-ish) that has multiple variations on the same theme. More details later.
  2. 1Password.
  3. LastPass.
  4. Bitwarden.
  5. Browser.

I highlight each of these in this article, in no particular order.

Your Browser’s Password Database

Most people don’t consider using their browser as a password manager a good idea. I’m one of those people. Depending on the browser, the version and the settings you choose, your passwords might not even be encrypted. There is also the problem of using those passwords in other apps. Granted, if you use Chrome, your Android phone likely will be able to access the passwords for you to use in other apps, but I’m simply not convinced the browser is the best place to store your passwords.

I’m sure the password storage feature of modern browsers is more secure than in the past, but a browser’s main function isn’t to secure your passwords, so I wouldn’t trust it to do so. I mention this option because it’s installed by default with every browser. It’s probably the most widely used option, and that breaks my heart. It’s too easy to click “save my password” and conveniently have your password filled in the next time you visit.

Is using the browser’s “save password” function better than using nothing at all? Maybe. It does allow people to use different passwords, trusting the browser to remember them. But, that’s about it. I’m sure the latest browsers have the option to secure the passwords a bit, but it’s not that way by default. I know this, because when I sit at my wife’s computer, I simply start her browser (Chrome), and all her passwords are filled in for me when I visit various websites. They’ve almost made it too easy to use poor security practices. The only hope is to have better options that are even easier—and I think we actually do. Keep reading!

The KeePass Kraziness

First off, these password managers are the ones that use a local, non-cloud-based database for storing passwords. If the thought of your encrypted passwords living on someone else’s servers offends your sensibilities, this is probably the best choice for you. And it is a really good choice, whichever flavor you pick.

The skinny on the various programs that share similar names is that originally, there was KeePass. It didn’t have a Linux version, so there was another program, KeePassX, that used an identical (and fully compatible) database. KeePassX runs natively on Linux, along with the other major OSes. To complicate issues, KeePass then released a Linux version, which runs natively, but it uses Mono libraries. It runs, and it runs fine, but Mono is a bit kludgy on Linux, so most folks still used KeePassX. Then KeePassXC came around, because the KeePassX program was getting a little long in the tooth, and it hadn’t been updated in a long time. So now, there are three programs, all of which work natively on Linux, and all of which are perfectly acceptable programs to use. I prefer KeePassXC (Figure 1), but only because it seems to be most actively developed. The good news is, all three programs can use the exact same database file. Really. If there is a single ray of sunshine on a messy situation, it’s that.


Figure 1. KeePassXC has a friendly, native Linux interface.

KeePass(X/XC) Features:

  • Local database file, with no syncing mechanism.
  • Database can be synced by a third party (such as Dropbox).
  • Supports master password and/or keyfile unlocking.
  • Very nice password generator (Figure 2).
  • Secure localhost-only browser integration (KeePassHTTP).

KeePass(X/XC) Pros:

  • No cloud storage.
  • Command-line interface included.
  • 2FA abilities (YubiKey).
  • Open source.
  • No “premium” features, everything is free.

KeePass(X/XC) Cons:

  • No cloud storage (yes, it’s a pro and a con, depending).
  • Brand confusion with multiple variations.
  • Requires third-party Android/iOS app for mobile use.
  • More complicated than cloud-based alternatives (file to sync/copy).

Figure 2. The KeePassXC password generator is awesome. I don’t even use KeePassXC for my password manager, but I still like the generator!

The KeePass family of password managers is arguably the most open-source-minded option of those I cover here. Depending on the user, to handle syncing/copying the database rather than depending on an unknown third party to store the data has a traditional Linux feel. For those folks who are most concerned about their data integrity, a KeePass database is probably the best option. Thankfully, due to third-party tools like KeePass2Droid (for Android) and MiniKeePass/KyPass for iOS, it’s possible to use your database on mobile devices as well. In fact, most apps handle syncing your database for you.


I didn’t know the Bitwarden password manager even existed until we did a Twitter poll asking what password managers LJ readers used. I have to admit, it’s an impressive system, and it ticks almost all the “feel good” boxes Linux users would want (Figure 3). Not only is it open source, but also the non-premium offering is a complete system. Yes, there is a premium option for $10/year, but the non-paid version isn’t crippled in any way.


Figure 3. Bitwarden is very well designed, and with its open-source nature, it’s hard to beat.

Bitwarden does store your data in its own cloud servers, but since the software is open source, you can examine the code to make sure the company isn’t doing anything underhanded. Bitwarden also has its own apps for Android/iOS and extensions for all major browsers. There’s no need to use a third-party tool. In fact, it even includes command-line tools for those folks who want to access the database in a text-only environment.

Bitwarden Features:

  • Open-source.
  • Cloud-based storage.
  • Decent password generator.
  • Native apps for Linux, Windows, Mac, Android and iOS.
  • Browser extensions for all major browsers.
  • Options to store logins, secure notes, credit cards and so on.

Bitwarden Pros:

  • One developer for all apps.
  • Open-source!
  • Cloud-based access.
  • Works offline if the “cloud” is unavailable.
  • Free version isn’t crippled.
  • Browser plugin works very well.

Bitwarden Cons:

  • Database is stored in the cloud (again, it’s a pro and a con, depending).
  • Some 2FA options require the Premium version.

Bitwarden Premium Version:

  • $10/year.
  • Additional 2FA options.
  • 1GB encrypted storage.

I’ll admit, Bitwarden is very, very impressive. If I had to pick a personal favorite, it probably would be this one. I’m already using a different option, and I’m happy with it, but if I were starting from scratch, I’d probably choose Bitwarden.


1Password is a widely used program for password management. But honestly, I’m not sure why. Don’t get me wrong; it works well, and it has great features. The problem is that I can’t find any features it has over the alternatives, and there isn’t a free option at all.

There’s also no native Linux application, but the 1PasswordX browser extension works well under Linux, and it’s user-friendly enough to use for things other than browser login needs. Still, although I don’t begrudge the company for charging a fee for the service, the alternatives offer significant services for free, and that’s hard to beat. Finally, 1Password utilizes a “secret key” that’s required on each device to log in. Although it is an additional layer of security, in practice, it’s a bit of a pain to install on each device.

1Password Features:

  • Cloud-based storage.
  • Non-login data encryption (Figure 4).
  • Printable “emergency kit” for recovering account.
  • Cross-platform browser extension.
  • Offline access.

1Password Pros:

  • Easy-to-use interface.
  • Very good browser integration.

1Password Cons:

  • $3/month, no free features.
  • Secret-key system can be cumbersome.
  • No native Linux app.
  • Proprietary, closed-source code.

1Password Premium Features:

  • All features require a monthly subscription.

Figure 4. 1Password has a great interface, and it stores lots of data.

If there weren’t any other password managers out there, 1Password would be incredible. Unfortunately for the 1Password company, there are other options, several of which are at least as good. I will admit, I really liked the browser extension’s interface, and it handled inserting login information into authentication fields very well. I’m not convinced it’s enough for the premium price, however, especially since there isn’t a free option at all.


Okay, first I feel I should admit that LastPass is the password manager I use (Figure 5). As I mentioned previously, if I were to start over from scratch, I’d probably choose Bitwarden. That said, LastPass keeps getting better, and its integration with browsers, mobile devices and native operating systems is pretty great.


Figure 5. I seldom use anything other than LastPass’s browser extension, unless I’m on my mobile device, but the app looks very similar.

LastPass offers a free tier and a paid tier. Not too long ago, you had to pay for the premium service ($2/month) in order to use it on a mobile device. Recently, however, LastPass opened mobile device syncing and integration into the completely free offering. That is significant, because it brings the free version to the same level as the free version of Bitwarden. (I suspect perhaps Bitwarden is the reason LastPass changed its free tier, but I have no way of knowing.)

LastPass Features:

  • Cloud-based storage.
  • Native apps for Linux, iOS and Android.
  • 2FA.
  • Offline access.
  • Cross-platform browser extension.

LastPass Pros:

  • Cloud-based storage.
  • Very robust free offering.
  • Smoothest browser-based password saving (in my experience).

LastPass Cons:

  • Data stored in the cloud (yes, it’s a pro and a con, depending).
  • Rumored to have poor support (I’ve never needed it).
  • Proprietary, closed-source code.

LastPass Premium:

  • $2/month.
  • Gives 1GB online file storage.
  • Provides the ability to share passwords.
  • Enhanced 2FA possibilities.
  • Emergency access granting (Figure 6).

Figure 6. This is sort of a “deadman’s” switch for emergency access. It allows you to give emergency access to someone, with the ability to revoke that access before it actually happens. Pretty neat!

LastPass is the only option I can give an opinion on based on extended experience. I did try each option listed here for a few days, and honestly, each one was perfectly acceptable. LastPass has been rock-solid for me, and even though it’s not open source, it does work well across multiple platforms.

The Winner?

Honestly, with the options available, especially those highlighted today, it’s hard to lose when picking a password manager. I sort of picked the top managers, and gave an overview of each. There are other, more obscure password managers. There are some options that are Linux-only. I decided to look at options that would work regardless of what platform you find yourself on now or even in the future. Once you pick a solution, migrating is a bit of a pain, so starting with something flexible is ideal.

If you’re concerned about someone else controlling your data (even if it’s encrypted), the KeePass/KeePassX/KeePassXC family is probably your best bet. If you don’t mind trusting others with your data-syncing, LastPass or Bitwarden probably will be ideal. I suppose if you don’t trust “free” products, or if you just really like the layout of 1Password, it’s a viable option. And I guess, in a pinch, using browser password management is better than nothing. But please, be sure the data is encrypted and password-protected.

Finally, even if none of these options are something you’d use on a daily basis, consider recommending one to someone you care about. Keeping track of passwords in a secure, sync-able database is a huge step in living a more secure online lifestyle. Now that mobile devices are taken seriously in the password management world, password managers make sense for everyone—even your non-techie friends and family.


[NOTE: This post was originally posted on the Linux Journal website. Since Linux Journal is now defunct, and authors own their content, I’m reposting here.]

Today, I Broke My Brain

Some days suck. Today, for instance.

I don’t talk much about mental illness. Not because of any stigma against it, or because I’m ashamed of having and handling mental illness, but rather because I just don’t have much to say on the issue. My car accident (see link above) sparked some serious brain issues for me, including anxiety, depression, OCD, and some symptoms that I’m not even sure what to call.

Today is a bad day.

I don’t have many bad days anymore. I’ve been on a medication for over a decade that works well to keep my brain in check. I’ve lived through enough rough times, that I can look back and see patterns, and know I’m not actually going crazy, and that this too will pass. That doesn’t make today better, really, but it does give me hope that tomorrow will be.

Today, I went grocery shopping with Donna. The store was busy. And really, that was it. My brain broke. For me, that means I was overwhelmed, for no really good reason. It manifests for me in a pretty predictable fashion:

  • I look scared and bewildered.
  • I can’t discern when people are talking to me over the din of background noise.
  • I stutter. (That’s really the one that gives it away to my loved ones. I can fake ’em out a bit usually, but stuttering is hard to hide)
  • I get confused easily. This is mainly due to the background noise thing.
  • I get VERY frustrated with myself, my stupid brain, my inability to be an effective family member, and my inability to pull myself out of it.
  • My hands shake.
  • I get odd facial twitches.
  • The worst part is, inside my head, I’m perfectly fine. I can think, I can reason — but it’s like I’m trying to function with 1,000 people screaming directions at me, and a layer of cotton between me and life.

I’ll be fine tomorrow. Really I will. And my family is incredibly supportive. They aren’t frustrated with me. They might be frustrated FOR me, but that’s different altogether. (It’s also not pity, for which I’m grateful) Unfortunately, Sunday night is our young adult ministry, and it means we’re feeding 20-30 college-aged people, along with coordinating music and discussion. I won’t be any help, which means Donna will have to do twice the amount of work. And THAT is the most frustrating part. Being a burden. (If Donna reads this, she’ll insist I’m not a burden, and I get it, she’s not upset with me. But really, it’s a burden we share, but a burden nonetheless)

ANYWAY, I post lots of silly photos. I share funny anecdotes. I smile a lot on the Internet. In my attempt to be as real as possible, I figured it only fair to share that sometimes I have bad days too. And that’s OK. Just think good thoughts at my wife. She totally deserves it today.

An Open Letter to the Singers in My Life

This letter is a response to my eldest daughter mentioning that she doesn’t post videos of herself singing, because she doesn’t want to post them just to get “likes” and puff herself up. She’s worried about posting them for the wrong reason, and doesn’t want to be “that” person. While I respect that…

Dear Singers I Love,

You know how sometimes you’re having a bad day, or life is just stepping on your face so hard it feels like you’re under water? I live with singers, and I know that when life kicks you in the head like that, you sing. You sing hard. There’s something magical about music, in that you can dump your pain, fear, heartache, and worries into it. That’s true of any art (in my opinion), but music is particular in its ability to rinse away those feelings. If you’re a singer, you know what I mean.

Here’s the rub: We don’t all have that singing ability. I don’t say that out of jealousy (much, lol), but rather to enlighten you. When you sing, your music not only washes away that pent up pain in your life, but it actually has a similar effect on others who hear it. Really. The more you put your soul into music, the more that music has pointy, jagged edges that rub off the painful crusty bits on the rest of us, which we can’t seem to expel on our own. We just don’t have that same magic.

You know how people tell you that you have a gift, and you should share it with others? I know that sounds like polite banter, or kind words to compliment your skill. I assure you, it’s quite literal. Your ability to make magical, soul-cleansing music is a gift. It’s a gift that others not only appreciate, but desperately need. When you share your music, you’re sharing that gift.

Certainly, there’s an ego-swelling potential when you share your music, and when people give you “likes” and praise. But please know that dealing with that difficult line between joy and arrogance is a burden I think you should consider suffering. When those of us without your gift give you “likes” and praise, it’s more than just complimenting your skill. It’s complimenting and appreciating your sharing. That gift you have benefits others in an oddly similar way that it benefits you.

I’m sorry that it often takes such pain to create such beauty. I’m embarrassed to ask you to share your coping mechanism with the rest of us. But please, when I tell you that you have a gift and you should share it with others — it’s so much more than asking for you to share your pleasant voice. I’m asking you to share your ability to cleanse souls.