Category Archives: Howto

Requering both an SSH key and a YubiKey

As of OpenSSH 6.2 there is the configuration option AuthenticationMethods, allowing for the requirement of more than one authentication method. For me the obvious combination here is requiring both regular ssh key auth as well as a physical YubiKey, both which need to succeed.

This post is a short description of my personal setup, focusing more on the how than on the whys.

In addition to the obvious requirement of having a YubiKey my setup depends on the following:

  • Running at least OpenSSH 6.2, which is provided by default as of Ubuntu 13.10. Debian wise it might be helpful to know that the Wheezy backports currently contains OpenSSH 6.5.
  • The Yubico PAM module. Assuming recent enough Debian/Ubuntu that module can be found in the libpam-yubico package.
  • An API key from https://upgrade.yubico.com/getapikey/.

Here we have the relevant part of sshd_config, only enforcing the additional requirement for selected users.

### /etc/ssh/sshd_config
...
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM yes
...
Match Group yubiusers
      PasswordAuthentication yes
      AuthenticationMethods publickey,password

Then there is the part about having PAM threat ssh passwords as YubiKey OTPs. Given Debian style /etc/pam.d/ I am modifying /etc/pam.d/sshd to replace the include of /etc/pam.d/common-auth with an include of my own custom /etc/pam.d/yubi-auth.

### /etc/pam.d/sshd
...
# @include common-auth
@include yubi-auth
...
### /etc/pam.d/yubi-auth
auth    required        pam_yubico.so mode=client id=NNN key=sEcREt authfile=/etc/yubimap

(No, the /etc/pam.d/yubi-auth file isn’t globally readable.)

In a more general manner the PAM config change is about replacing the auth … pam_unix.so line with an auth … pam_yubico.so line.

The specified /etc/yubimap holds the mapping between usernames and YubiKeys.

### /etc/yubimap
andreas:ccccccbhkljr
root:ccccccbhkljr

Finally, the result.

andreas@corrino:~$ ssh halleck.arrakis.se
Authenticated with partial success.
andreas@halleck.arrakis.se's password:
...
andreas@halleck:~$

rsyslog loggly remote

Shipping your logs to a central server is usually a good thing to do. For a large number of servers it provides a better overview, and no matter the numbers of servers a secondary log location can be helpful in figuring out why something bad happened to a server.

My two VPS nodes are now using loggly as a remote (TLS) syslog server. I’m even allowed do that for free, as long as I don’t upload more than 200 MB of logs per day, nor want the log data to be retained for more than a week. Not that I would mind paying a bit for a longer retention period. It’s just that their pricing feels a bit steep, given that I currently log less than a megabyte per day.

(Yes, I do realize that I’m not their obvious target audience.)

Already running rsyslog I decided to follow loggly’s rsyslog instructions, which did a pretty good job of explaining the additional configuration needed. The one thing I did miss in those instruction were a discussion on queue setting, which very much will matter when loggly’s servers for one reason or another becomes unavailable. By default rsyslog only queues a limited number of entries in memory, so for additional resilience I explicitly enabled a disk assisted queue, based on the rsyslog reliable forwarding guide.

Want to test the queuing? Just put appropriate iptables rules in place, and then speed up time by using logger(1) to pipe lots and lots of entries into syslog.

All in all, the following loggly specific configuration seems to do the trick for me.

# /etc/rsyslog.d/loggly.conf
$DefaultNetstreamDriverCAFile /etc/ssl/loggly/loggly_full.crt
$DefaultNetstreamDriverCertFile /etc/ssl/loggly/dummy-halleck.crt
$DefaultNetstreamDriverKeyFile /etc/ssl/loggly/dummy-halleck.key

$ActionSendStreamDriver gtls
$ActionSendStreamDriverMode 1
$ActionSendStreamDriverAuthMode x509/name
$ActionSendStreamDriverPermittedPeer *.loggly.com

$ActionQueueType LinkedList
$ActionQueueFileName loggly
$ActionResumeRetryCount -1
$ActionQueueSaveOnShutdown on

*.* @@logs.loggly.com:<assigned port>

If you are running Ubuntu, and Launchpad bug #1075901 have yet to be fully fixed, you might manually need to chown syslog:syslog /var/spool/rsyslog/. While you are at it, also install the needed rsyslog-gnutls package.

Worth mentioning is that loggly provides the option of archiving your logs to a S3 bucket. Given my modest log volumes the cost of doing that ought to be pleasantly close to zero.

Will be very interesting to see how reliable this solution turns out to be. The plan is to setup some semi-automated testing, and hopefully have some results to share in a follow-up post, say in a month or two.

YubiKey NEO and Ubuntu

My Christmas gift to myself this year turned out to be a YubiKey NEO.

The new feature I myself find most interesting is that the NEO can act as an OpenPGP smartcard. While there is a pretty good introduction in the Yubico blog post YubiKey NEO and OpenPGP I ran into some obstacles getting things running under Ubuntu.

First of all it doesn’t seem like the version of the yubikey-personalization  (1.7.0) included in Ubuntu 12.10 recognizes the YubiKey NEO. Without spending to much time on debugging that issue was solved by upgrading to the current yubikey-personalization version, using the Yubico PPA.

Then there was the matter of getting the device permissions right, allowing my non-root user to use/modify the NEO more actively than just having it act as a keyboard (HID), spitting out one time passwords. Turns out that the /lib/udev/rules.d/70-yubikey.rules provided by the current yubikey-personalization (1.11.1) only matches the ATTRS{idProduct} “0010″, which doesn’t apply to the NEO. I solved that by copying the 70-yubikey.rules to /etc/udev/rules.d/, modifying it to instead match ATTRS{idProduct} against “0010|0111″. According to the add udev rules for YubiKey NEO bug report it probably doesn’t hurt to also through the 0110 id into the mix.

Finally I had the fun experience of running into a limitation in the gnome-keyring’s capacity to act as gnupg-agent (Launchpad bug #884856). Any attempt to have GnuPG interact with the NEO smartcard, while using the gnome-keyring gnupg-agent, resulted in a “selecting openpgp failed: unknown command” error. Not finding any cleaner configuration option I resorted to simply removing /etc/xdg/autostart/gnome-keyring-gpg.desktop, resulting in gnome-keyring no longer hijacking the GPG_AGENT_INFO environment variable, instead letting the real gnupg-agent do its thing.

Now I only need to decide to what extent to actually use the OpenPGP smartcard feature. Yet, that’s a whole different blog post.

Tarsnap Nagios checks

While I have been using Tarsnap for a while now it is first recently I have gotten around to make Nagios monitor those backups. Given that I really don’t want to give the nagios user any actual access to my backups, I instead take the approach of having my backup script create a status file containing a Unix timestamp of the most recent backup.

My check_tarsnap Nagios plugin can then use that status file to check that the most recent backup isn’t older than a specified number of hours. For my nightly backups I have the Warning threshold set to 26 hours and the Critical threshold set to 42 hours.

(See the top comment in the plugin source for an example on how to create the status file.)

Managing passwords using GnuPG, Git and Emacs

Like any other security conscious and/or slightly paranoid computer geek I have lots and lots of unique and nontrivial passwords to keep track of.  My solution to this problem involves having one GnuPG encrypted text file per username/password pair.

andreas@stilgar:~/safe$ gpg < example.gpg

You need a passphrase to unlock the secret key for
user: "Andreas Olsson <andreas@arrakis.se>"
4096-bit RSA key, ID 9A943D4A, created 2010-07-11 (main key ID 13CD4F59)
  Here gnupg-agent calls pinentry-gtk2 to prompt me for the passphrase
gpg: encrypted with 4096-bit RSA key, ID 9A943D4A, created 2010-07-11
      "Andreas Olsson <andreas@arrakis.se>"

https://127.0.0.1/

username: sigge
password: sigge

andreas@stilgar:~/safe$

As I need to have access to those passwords on more than one computer I use Git, and a remote repository, to keep my encrypted files in sync. Other options might be to mount a SFTP folder using SSHFS, or to simply put the files in your Dropbox. Yet, if you too decide to go with Git, here is a .gitignore you might want to use.

andreas@stilgar:~/safe$ cat .gitignore
*
!*.gpg
!.gitignore
andreas@stilgar:~/safe$

Thanks to Emacs and EasyPG it is a breeze to  create new GnuPG encrypted text files, as well as to modify existing ones. Just use the file extension .gpg, and EasyPG will do its thing. The first time, when you actually create the file, you will be prompted for which public keys you want to encrypt against.

andreas@stilgar:~/safe$ emacs yet_another_example.gpg

(EasyPG is included in Emacs 23, and don’t need to be installed separately.)

Do note that this method also works when there are multiple people involved. Just make sure that the intended users have access to the share/repository in question, and that their public keys are included when you create the GnuPG files.

Reassembling Das Keyboard

Ok, first some background.

  1. Earlier this year, I bought myself a Das Keyboard Ultimate.
  2. Time passes, and I am still very happy with the keyboard.
  3. Accident happen, forcing me into some serious keyboard cleaning.

According to daskeyboard.com/support it is perfectly safe to remove the small/regular keys (letters, numbers, etc). The larger keys (enter, shift, etc) on the other hand should be left alone, as they apparently are quite hard to get properly back in place.

The mistake I made was to assume that all those blank keys are the same. Trying to reassemble the keyboard I discovered that they actually come in four different heights and angles.

Luckily the friendly people at Das Keyboard Support managed to give me a few pointers. Apparently the keys are “horizontality” arranged. The picture below will hopefully illustrate which key types belong at which lines.

Placement of keys on a Das Keyboard

(The picture is used, and modified, by permission from Das Keyboard Support.)

If you look underneath the keys you will notice that some of them are marked as R1, R2 or R3. Yes, that marking correspond with the key types one, two and three, respectively. The exception being the keys belonging as F, J and numeric 5.

This blog post probably makes a lot more sense if you know that the Das Keyboard Ultimate is completely black, without any inscription on its keys what so ever. Knowing a tiny bit of German probably does not hurt either.

Using the YubiKey

One of the keys I carry around on my keyring is a YubiKey. This post really isn’t about the YubiKey itself, but more about me sharing a few insights I’ve gained on using the key.

  • If you already run a WordPress blog you can easily turn it into an OpenID provider to be used with your YubiKey.  What you need is the OpenID plugin and the YubiKey plugin.
  • If you decide to personalize your YubiKey I can very much recommend the DuckCorp YubikeyHelp, in addition to the official documentation.
  • The new 2.x version of yubikey-val-server-php seems to prefer being part of a group of validation servers, being kept in sync with each other. Failing to figure out how to configure my standalone installation to disregard that synchronization I modified ykval-verify.php (see patch) not to perform those checks.
  • The YubiKey WordPress plugin mentioned earlier is hardcoded into using the official Yubico validation server. Apart from  the validation URL, set in the function yubikey_verify_otp(), there is also the length of the key id. Just look for the numeric value 12 and you will find where the key id is being used.

No, this post is not meant to make sense on its own. You probably need to be at least somewhat familiar with the YubiKey as well as the services provided by Yubico.

ssh-agent without the Gnome keyring

In a default Ubuntu, and probably any other modern Gnome based Linux desktop, the Gnome keyring takes the role of the ssh-agent. If this is not desirable you can tell the keyring not to do that by setting the gconf variable /apps/gnome-keyring/daemon-components/ssh to false.

$ gconftool -s –type bool /apps/gnome-keyring/daemon-components/ssh false

At the next login you should see your environment variable SSH_AUTH_SOCK pointing towards a more proper socket. Note that the real ssh-agent is still started, assuming Ubuntu, thanks to /etc/X11/Xsession.d/90×11-common_ssh-agent.

APT::Install-Recommends

Apparently Ubuntu now has APT::Install-Recommends set to True by default. This happened in version 8.10 (Intrepid) and it results in that packages marked as Recommended are now automatically installed kinda like dependencies.

I guess that change can make sense on a desktop system, where it might be nice to by default provide the user with a few more useful features.  Dealing with servers on the other hand I very much like to be in control of what and what not is installed.

My way of disabling the automatic installation of Recommends is to put this into /etc/apt/apt.conf.d/01ubuntu:

APT
{
Install-Recommends “false”;
};

Disclaimer: I don’t know the APT layout of Ubuntu well enough to know if that is the best place to put those settings. All I can say is that for now it seems to get the job done.

Yes, I have made a mention about it in Launchpad (#316472).

My ~/private Eee folder

Inspired by the Ubuntu project Encrypted Private Directory I decided to set something similar up on my Eee PC. Being a regular FUSE user I based my solution on EncFs and pam-encfs.

First of all we create our folders. These commands should be run as your normal user. The password you give EncFs has to be the same as the one you use to login.

$ mkdir /home/U/.private /home/U/private
$ chmod 700 /home/U/.private /home/U/private
$ encfs /home/U/.private /home/U/private

$ fusermount -u /home/U/private

(By the way, I’m assuming that the user is part of the fuse group, or has proper permissions to /dev/fuse by some other means.)

With your folders in order it’s time to instruct PAM on how to automaticly mount your private folder at login time. My /etc/pam.d/common-auth  and /etc/security/pam_encfs.conf looks like this.

auth    sufficient    pam_encfs.so
auth    required    pam_unix.so nullok_secure use_first_pass

U  /home/U/.private  /home/U/private  –public  nonempty

Using –public will ensure proper file ownership; no matter if encfs is mounted by root (gdm/X) or by your normal user. You might have to restart gdm, sshd, etc before your new PAM settings take effect.

By now the folder /home/U/private/ will be mounted at login time. Everything you put in there will be encrypted into /home/U/.private/.

I guess I shold mention that my Eee is a DebianEee. I have no idea how well this will work on the default Xandros Eee installation.