Antoine Beaupr : Using a Yubikey NEO for SSH and OpenPGP on Debian jessie
I recently ordered two Yubikey devices from Yubico, partly
because of a special offer from Github. I ordered both a
Yubikey NEO and a Yubikey 4, although I am not sure I remember
why I ordered two - you can see their Yubikey product comparison
if you want to figure that out, but basically, the main difference is
that the NEO has support for NFC while the "4" has support for
larger RSA key sizes (4096).
This article details my experiment on the matter. It is partly based
on first hand experience, but also links to various other tutorials
that helped me along the way. Especially thanks to folks on various
IRC channels that really helped me out in understanding
this.
My objective in getting a hardware security token like this was
three-fold:
Not recommended
After experimenting with the device and doing a little more research,
I am not sure it was the right decision to buy a Yubikey. I would not
recommend buying Yubikey devices because they
don't allow changing the firmware, making the device basically
proprietary, even in the face of an
embarrassing security vulnerability on the Yubikey NEO that came
out in 2015. A security device, obviously, should be as open as the
protocols it uses, otherwise it's basically impossible to trust that
the crypto hasn't been backdoored or compromised, or, in this case, is
vulnerable to the simplest drive-by attacks.
Furthermore, it turns out that the primary use case that Github was
promoting is actually not working as advertised: to use the Yubikey on
Github, you actually first need to configure 2FA with another
tool, either with your phone's text messages (SMS) or with something
like Google Authenticator. After contacting Github support, they
explained that the Yubikey is seen as a "backup device", which seems
really odd to me, especially considering the promotion and the fact
that I don't have a "smart" (aka "Google", it seems these days) phone
or the desire to share my personal phone number with Github.
Finally, as I mentioned before, the fact that those devices are
fairly new and the configuration necessary to make them work at all is
completely obtuse, non-standardized or at least not available by
default on arbitrary computers makes them basically impossible to use
on other computers than your own specially crafted gems.
- use 2FA on important websites like Github, to improve the security of critical infrastructure (like my Borg backup software)
- login to remote SSH servers without exposing my password or my private key material on third party computers
- store OpenPGP key material on the key securely, so that the private key material can never be compromised
- PIV (Personnal Identity Verification): basically to run your own Certificate Authority
- OTP (One Time Password): allows sites to request a OTP from a Yubikey server validator. I haven't explored that mode since it requires a third party server and more modifications on the server side.
- OATH (Initiative for Open Authentication): a purely "offline" and more "traditionnal" approach to OTP. In this mode, you can authenticate with only the token given by the key and a shared secret. Maybe i will follow this OATH tutorial eventually.
Not recommended
After experimenting with the device and doing a little more research,
I am not sure it was the right decision to buy a Yubikey. I would not
recommend buying Yubikey devices because they
don't allow changing the firmware, making the device basically
proprietary, even in the face of an
embarrassing security vulnerability on the Yubikey NEO that came
out in 2015. A security device, obviously, should be as open as the
protocols it uses, otherwise it's basically impossible to trust that
the crypto hasn't been backdoored or compromised, or, in this case, is
vulnerable to the simplest drive-by attacks.
Furthermore, it turns out that the primary use case that Github was
promoting is actually not working as advertised: to use the Yubikey on
Github, you actually first need to configure 2FA with another
tool, either with your phone's text messages (SMS) or with something
like Google Authenticator. After contacting Github support, they
explained that the Yubikey is seen as a "backup device", which seems
really odd to me, especially considering the promotion and the fact
that I don't have a "smart" (aka "Google", it seems these days) phone
or the desire to share my personal phone number with Github.
Finally, as I mentioned before, the fact that those devices are
fairly new and the configuration necessary to make them work at all is
completely obtuse, non-standardized or at least not available by
default on arbitrary computers makes them basically impossible to use
on other computers than your own specially crafted gems.
Plugging it in
The Yubikey, when inserted into a USB port, seems to be detected
properly. It shows up both as a USB keyboard and a generic device.
d c 14 17:23:26 angela kernel: input: Yubico Yubikey NEO OTP+U2F as /devices/pci0000:00/0000:00:12.0/usb3/3-2/3-2:1.0/0003:1050:0114.0016/input/input127
d c 14 17:23:26 angela kernel: hid-generic 0003:1050:0114.0016: input,hidraw3: USB HID v1.10 Keyboard [Yubico Yubikey NEO OTP+U2F] on usb-0000:00:12.0-2/input0
d c 14 17:23:26 angela kernel: hid-generic 0003:1050:0114.0017: hiddev0,hidraw4: USB HID v1.10 Device [Yubico Yubikey NEO OTP+U2F] on usb-0000:00:12.0-2/input1
We'll be changing this now - we want to to support OTP, U2F and
CCID. Don't worry about those acronyms now, but U2F is for the web,
CCID is for GPG/SSH, and OTP is for the One Time Passwords stuff
mentionned earlier.
I am using the Yubikey Personalization tool from stretch because
the jessie one is too old, according to Gorzen. Indeed, I found
out that the jessie version doesn't ship with the proper udev
rules. Also, note that we need to run as sudo otherwise we get a
permission denied:
$ sudo apt install yubikey-personalization/stretch
$ sudo ykpersonalize -m86
Firmware version 3.4.3 Touch level 1541 Program sequence 1
The USB mode will be set to: 0x86
Commit? (y/n) [n]: y
To understand better what the above does, see the
NEO composite device documentation.
The next step is to reconnect the key, for the udev rules to kick
in. If you were like me, you enthusiastically plugged in the device
before installing the yubikey-personalization package, and the
udev rules were not present then.
Configuring a PIN
Various operations will require you to enter a PIN when talking to the
key. The default PIN is 123456 and the default admin PIN
is 12345678. You will want to change that, otherwise someone that
gets a hold of your key could do any operation without your
consent. For this, you need to use:
$ gpg --card-edit
> passwd
> admin
> passwd
Be sure to remember those passwords! Of course, the key material on
the Yubikey can be revoked when you loose the key, but only if you
still have control of the master key, or if you have a OpenPGP
revocation certification (which you should have).
Configuring GPG
To do OpenPGP operations (like decryption, signatures and so on), or
SSH operations (like authentication on a remote server), you need to
talk with GPG. Yes, OpenPGP keys are RSA keys that can be used to
authenticate with SSH servers, that's not new and I have already been
doing this with Monkeysphere for a while. Now the challenge is how
to make GPG talk with the Yubikey.
So the next step is to see if gpg can see the key alright, as
described in the Yubikey importing keys howto - you will need first
to install scdaemon and pcscd (according to this howto) for
gpg-agent to be able to talk with the key:
$ sudo apt install scdaemon gnupg-agent pcscd
$ gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
ERR 100663404 Card error <SCD>
Well that failed. At this point, touching the key types a bunch of
seemingly random characters wherever my cursor is sitting - fun but
totally useless still. That was because I failed to reconnect the key:
make sure the udev rules are in place and reconnect the key, the above
should work:
$ gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
D[0000] 01 00 10 90 00 .....
OK
This shows it is running the firmware 1.10, which is not vulnerable to
the infamous security issue.
(Note: I also happened to install opensc and gpgsm because of
this suggestion but I am not sure they are required at all.)
Using SSH
To make GPG work with SSH, you need somehow to start gpg-agent with
ssh support, for example with:
gpg-agent --daemon --enable-ssh-support bash
Of course, this will work better if it's started with your Xsession.
Such an agent should already be started, so you just need to add the ssh
emulation to its configuration file and restart your X session.
echo 'enable-ssh-support' >> .gnupg/gpg-agent.conf
In Debian Jessie, the ssh-agent wrapper will not start if it
detects that you have already one running (for example from
gpg-agent) but if that fails, you can try commenting out
use-ssh-agent from /etc/X11/Xsession.options to keep it from
starting up in your session. (Thanks to
stackexchange for that reference.)
Here I assume you have already created an authentication subkey on
your PGP key. If you haven't, I suggest trying out simply
monkeysphere gen-subkey, which will generate an authentication
subkey for you. You can also do it by hand by following one of the
OpenPGP/SSH tutorials from Yubikey, especially the
more complete one. If you are going to generate a completely new
OpenPGP key, you may want to follow this simpler tutorial here.
Then you need to move your authentication subkey to the Yubikey. For
this, you need to edit the key and use the keytocard command:
$ gpg2 --edit-key anarcat@debian.org
> toggle
> key 2
> keytocard
> save
Here, we use toggle to show the OpenPGP private key material. You
should see a key marked with A for Authentication. Mine was the
second one so I selected it with key 2 which put a star next to
it. The keytocard command moved it to the key and save ensure the
key was removed from the local keyring.
Obviously, backups are essential before doing this, because it's
perfectly possible to loose that key in the process, for example if
you destroy or lose the key or forget the password. It's probably
better to create a completely different authentication subkey for just
this purpose, but that may require reconfiguring all remote SSH hosts,
and you may not want to do that.
Then SSH should magically talk with the GPG agent and ask you for the
PIN! That's pretty much all there is to it - if it doesn't, it means
that gpg-agent is not your SSH agent, and obviously things will fail...
Also, you should be able to see the key being loaded in the agent when
it is:
$ ssh-add -l
2048 23:f3:be:bf:1e:da:e8:ad:4b:c7:f6:60:5e:03:c2:a6 cardno:000603647189 (RSA)
.. that's about it! I have yet to cover 2FA and OpenPGP support,
but that got me going for a while and I'll stop geeking around with
that thing for now. It was fun, for sure, but not sure it's worth it
for now.
Using OATH
This is pretty neat: it allows you to add two factor authentication to a lot of things. For example, PAM has such a module, which I will configure here to allow myself to login to my server from untrusted machines. While I will expose my main password to keyloggers, the OTP password will prevent that from being reused. This is a simplified version of this OATH tutorial.
We install the PAM module with:
sudo apt install libpam-oath
Then, we can hook it into any PAM consumer, for example with sshd:
--- a/pam.d/sshd
+++ b/pam.d/sshd
@@ -1,5 +1,8 @@
# PAM configuration for the Secure Shell service
+# for the yubikey
+auth required pam_oath.so usersfile=/etc/users.oath window=5 digits=8
+
# Standard Un*x authentication.
@include common-auth
We also needed to allow OTP passwords in sshd explicitely, with:
ChallengeResponseAuthentication yes
This will force the user to enter a valid oath token on the server. Unfortunately, this will affect all users, regardless of whether they are present in the users.oath file. I filed bug #807990 regarding this, with a patch.
Also, it means the main password is still exposed on the client machine - you can use the sufficient keyword instead of required to workaround that, but then it means anyone with your key can login to your machine, which is something to keep in mind.
The /etc/users.oath file needs to be created with something like:
#type username pin start seed
HOTP anarcat - 00
00 is obviously a fake, and insecure string. Generate a proper one with:
dd if=/dev/random bs=1k count=1 sha1sum # create a random secret
Then the shared secret needs to be added to the Yubikey:
ykpersonalize -1 -o oath-hotp -o oath-hotp8 -o append-cr -a
You simply paste the random secret you created above, when prompted, and that shared secret will be saved in a Yubikey slot for future use. Next time you login to the SSH server, you will be prompted for a OATH password, you just touch the button on the key and it will be pasted there:
$ ssh -o PubkeyAuthentication=no anarc.at
One-time password (OATH) for anarcat':
Password:
[... logged in!]
Final note: the centralized file approach makes it hard, if not impossible, for users to update their own secret token.. It would be nice if there would be a user-accessible token file, maybe ~/.oath? Filed feature request #807992 about this as well.
d c 14 17:23:26 angela kernel: input: Yubico Yubikey NEO OTP+U2F as /devices/pci0000:00/0000:00:12.0/usb3/3-2/3-2:1.0/0003:1050:0114.0016/input/input127
d c 14 17:23:26 angela kernel: hid-generic 0003:1050:0114.0016: input,hidraw3: USB HID v1.10 Keyboard [Yubico Yubikey NEO OTP+U2F] on usb-0000:00:12.0-2/input0
d c 14 17:23:26 angela kernel: hid-generic 0003:1050:0114.0017: hiddev0,hidraw4: USB HID v1.10 Device [Yubico Yubikey NEO OTP+U2F] on usb-0000:00:12.0-2/input1
stretch because
the jessie one is too old, according to Gorzen. Indeed, I found
out that the jessie version doesn't ship with the proper udev
rules. Also, note that we need to run as sudo otherwise we get a
permission denied:
$ sudo apt install yubikey-personalization/stretch
$ sudo ykpersonalize -m86
Firmware version 3.4.3 Touch level 1541 Program sequence 1
The USB mode will be set to: 0x86
Commit? (y/n) [n]: y
udev rules to kick
in. If you were like me, you enthusiastically plugged in the device
before installing the yubikey-personalization package, and the
udev rules were not present then.
Configuring a PIN
Various operations will require you to enter a PIN when talking to the
key. The default PIN is 123456 and the default admin PIN
is 12345678. You will want to change that, otherwise someone that
gets a hold of your key could do any operation without your
consent. For this, you need to use:
$ gpg --card-edit
> passwd
> admin
> passwd
Be sure to remember those passwords! Of course, the key material on
the Yubikey can be revoked when you loose the key, but only if you
still have control of the master key, or if you have a OpenPGP
revocation certification (which you should have).
Configuring GPG
To do OpenPGP operations (like decryption, signatures and so on), or
SSH operations (like authentication on a remote server), you need to
talk with GPG. Yes, OpenPGP keys are RSA keys that can be used to
authenticate with SSH servers, that's not new and I have already been
doing this with Monkeysphere for a while. Now the challenge is how
to make GPG talk with the Yubikey.
So the next step is to see if gpg can see the key alright, as
described in the Yubikey importing keys howto - you will need first
to install scdaemon and pcscd (according to this howto) for
gpg-agent to be able to talk with the key:
$ sudo apt install scdaemon gnupg-agent pcscd
$ gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
ERR 100663404 Card error <SCD>
Well that failed. At this point, touching the key types a bunch of
seemingly random characters wherever my cursor is sitting - fun but
totally useless still. That was because I failed to reconnect the key:
make sure the udev rules are in place and reconnect the key, the above
should work:
$ gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
D[0000] 01 00 10 90 00 .....
OK
This shows it is running the firmware 1.10, which is not vulnerable to
the infamous security issue.
(Note: I also happened to install opensc and gpgsm because of
this suggestion but I am not sure they are required at all.)
Using SSH
To make GPG work with SSH, you need somehow to start gpg-agent with
ssh support, for example with:
gpg-agent --daemon --enable-ssh-support bash
Of course, this will work better if it's started with your Xsession.
Such an agent should already be started, so you just need to add the ssh
emulation to its configuration file and restart your X session.
echo 'enable-ssh-support' >> .gnupg/gpg-agent.conf
In Debian Jessie, the ssh-agent wrapper will not start if it
detects that you have already one running (for example from
gpg-agent) but if that fails, you can try commenting out
use-ssh-agent from /etc/X11/Xsession.options to keep it from
starting up in your session. (Thanks to
stackexchange for that reference.)
Here I assume you have already created an authentication subkey on
your PGP key. If you haven't, I suggest trying out simply
monkeysphere gen-subkey, which will generate an authentication
subkey for you. You can also do it by hand by following one of the
OpenPGP/SSH tutorials from Yubikey, especially the
more complete one. If you are going to generate a completely new
OpenPGP key, you may want to follow this simpler tutorial here.
Then you need to move your authentication subkey to the Yubikey. For
this, you need to edit the key and use the keytocard command:
$ gpg2 --edit-key anarcat@debian.org
> toggle
> key 2
> keytocard
> save
Here, we use toggle to show the OpenPGP private key material. You
should see a key marked with A for Authentication. Mine was the
second one so I selected it with key 2 which put a star next to
it. The keytocard command moved it to the key and save ensure the
key was removed from the local keyring.
Obviously, backups are essential before doing this, because it's
perfectly possible to loose that key in the process, for example if
you destroy or lose the key or forget the password. It's probably
better to create a completely different authentication subkey for just
this purpose, but that may require reconfiguring all remote SSH hosts,
and you may not want to do that.
Then SSH should magically talk with the GPG agent and ask you for the
PIN! That's pretty much all there is to it - if it doesn't, it means
that gpg-agent is not your SSH agent, and obviously things will fail...
Also, you should be able to see the key being loaded in the agent when
it is:
$ ssh-add -l
2048 23:f3:be:bf:1e:da:e8:ad:4b:c7:f6:60:5e:03:c2:a6 cardno:000603647189 (RSA)
.. that's about it! I have yet to cover 2FA and OpenPGP support,
but that got me going for a while and I'll stop geeking around with
that thing for now. It was fun, for sure, but not sure it's worth it
for now.
Using OATH
This is pretty neat: it allows you to add two factor authentication to a lot of things. For example, PAM has such a module, which I will configure here to allow myself to login to my server from untrusted machines. While I will expose my main password to keyloggers, the OTP password will prevent that from being reused. This is a simplified version of this OATH tutorial.
We install the PAM module with:
sudo apt install libpam-oath
Then, we can hook it into any PAM consumer, for example with sshd:
--- a/pam.d/sshd
+++ b/pam.d/sshd
@@ -1,5 +1,8 @@
# PAM configuration for the Secure Shell service
+# for the yubikey
+auth required pam_oath.so usersfile=/etc/users.oath window=5 digits=8
+
# Standard Un*x authentication.
@include common-auth
We also needed to allow OTP passwords in sshd explicitely, with:
ChallengeResponseAuthentication yes
This will force the user to enter a valid oath token on the server. Unfortunately, this will affect all users, regardless of whether they are present in the users.oath file. I filed bug #807990 regarding this, with a patch.
Also, it means the main password is still exposed on the client machine - you can use the sufficient keyword instead of required to workaround that, but then it means anyone with your key can login to your machine, which is something to keep in mind.
The /etc/users.oath file needs to be created with something like:
#type username pin start seed
HOTP anarcat - 00
00 is obviously a fake, and insecure string. Generate a proper one with:
dd if=/dev/random bs=1k count=1 sha1sum # create a random secret
Then the shared secret needs to be added to the Yubikey:
ykpersonalize -1 -o oath-hotp -o oath-hotp8 -o append-cr -a
You simply paste the random secret you created above, when prompted, and that shared secret will be saved in a Yubikey slot for future use. Next time you login to the SSH server, you will be prompted for a OATH password, you just touch the button on the key and it will be pasted there:
$ ssh -o PubkeyAuthentication=no anarc.at
One-time password (OATH) for anarcat':
Password:
[... logged in!]
Final note: the centralized file approach makes it hard, if not impossible, for users to update their own secret token.. It would be nice if there would be a user-accessible token file, maybe ~/.oath? Filed feature request #807992 about this as well.
$ gpg --card-edit
> passwd
> admin
> passwd
gpg can see the key alright, as
described in the Yubikey importing keys howto - you will need first
to install scdaemon and pcscd (according to this howto) for
gpg-agent to be able to talk with the key:
$ sudo apt install scdaemon gnupg-agent pcscd
$ gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
ERR 100663404 Card error <SCD>
$ gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
D[0000] 01 00 10 90 00 .....
OK
opensc and gpgsm because of
this suggestion but I am not sure they are required at all.)
Using SSH
To make GPG work with SSH, you need somehow to start gpg-agent with
ssh support, for example with:
gpg-agent --daemon --enable-ssh-support bash
Of course, this will work better if it's started with your Xsession.
Such an agent should already be started, so you just need to add the ssh
emulation to its configuration file and restart your X session.
echo 'enable-ssh-support' >> .gnupg/gpg-agent.conf
In Debian Jessie, the ssh-agent wrapper will not start if it
detects that you have already one running (for example from
gpg-agent) but if that fails, you can try commenting out
use-ssh-agent from /etc/X11/Xsession.options to keep it from
starting up in your session. (Thanks to
stackexchange for that reference.)
Here I assume you have already created an authentication subkey on
your PGP key. If you haven't, I suggest trying out simply
monkeysphere gen-subkey, which will generate an authentication
subkey for you. You can also do it by hand by following one of the
OpenPGP/SSH tutorials from Yubikey, especially the
more complete one. If you are going to generate a completely new
OpenPGP key, you may want to follow this simpler tutorial here.
Then you need to move your authentication subkey to the Yubikey. For
this, you need to edit the key and use the keytocard command:
$ gpg2 --edit-key anarcat@debian.org
> toggle
> key 2
> keytocard
> save
Here, we use toggle to show the OpenPGP private key material. You
should see a key marked with A for Authentication. Mine was the
second one so I selected it with key 2 which put a star next to
it. The keytocard command moved it to the key and save ensure the
key was removed from the local keyring.
Obviously, backups are essential before doing this, because it's
perfectly possible to loose that key in the process, for example if
you destroy or lose the key or forget the password. It's probably
better to create a completely different authentication subkey for just
this purpose, but that may require reconfiguring all remote SSH hosts,
and you may not want to do that.
Then SSH should magically talk with the GPG agent and ask you for the
PIN! That's pretty much all there is to it - if it doesn't, it means
that gpg-agent is not your SSH agent, and obviously things will fail...
Also, you should be able to see the key being loaded in the agent when
it is:
$ ssh-add -l
2048 23:f3:be:bf:1e:da:e8:ad:4b:c7:f6:60:5e:03:c2:a6 cardno:000603647189 (RSA)
.. that's about it! I have yet to cover 2FA and OpenPGP support,
but that got me going for a while and I'll stop geeking around with
that thing for now. It was fun, for sure, but not sure it's worth it
for now.
Using OATH
This is pretty neat: it allows you to add two factor authentication to a lot of things. For example, PAM has such a module, which I will configure here to allow myself to login to my server from untrusted machines. While I will expose my main password to keyloggers, the OTP password will prevent that from being reused. This is a simplified version of this OATH tutorial.
We install the PAM module with:
sudo apt install libpam-oath
Then, we can hook it into any PAM consumer, for example with sshd:
--- a/pam.d/sshd
+++ b/pam.d/sshd
@@ -1,5 +1,8 @@
# PAM configuration for the Secure Shell service
+# for the yubikey
+auth required pam_oath.so usersfile=/etc/users.oath window=5 digits=8
+
# Standard Un*x authentication.
@include common-auth
We also needed to allow OTP passwords in sshd explicitely, with:
ChallengeResponseAuthentication yes
This will force the user to enter a valid oath token on the server. Unfortunately, this will affect all users, regardless of whether they are present in the users.oath file. I filed bug #807990 regarding this, with a patch.
Also, it means the main password is still exposed on the client machine - you can use the sufficient keyword instead of required to workaround that, but then it means anyone with your key can login to your machine, which is something to keep in mind.
The /etc/users.oath file needs to be created with something like:
#type username pin start seed
HOTP anarcat - 00
00 is obviously a fake, and insecure string. Generate a proper one with:
dd if=/dev/random bs=1k count=1 sha1sum # create a random secret
Then the shared secret needs to be added to the Yubikey:
ykpersonalize -1 -o oath-hotp -o oath-hotp8 -o append-cr -a
You simply paste the random secret you created above, when prompted, and that shared secret will be saved in a Yubikey slot for future use. Next time you login to the SSH server, you will be prompted for a OATH password, you just touch the button on the key and it will be pasted there:
$ ssh -o PubkeyAuthentication=no anarc.at
One-time password (OATH) for anarcat':
Password:
[... logged in!]
Final note: the centralized file approach makes it hard, if not impossible, for users to update their own secret token.. It would be nice if there would be a user-accessible token file, maybe ~/.oath? Filed feature request #807992 about this as well.
gpg-agent --daemon --enable-ssh-support bash
echo 'enable-ssh-support' >> .gnupg/gpg-agent.conf
$ gpg2 --edit-key anarcat@debian.org
> toggle
> key 2
> keytocard
> save
$ ssh-add -l
2048 23:f3:be:bf:1e:da:e8:ad:4b:c7:f6:60:5e:03:c2:a6 cardno:000603647189 (RSA)
sudo apt install libpam-oath
sshd:
--- a/pam.d/sshd
+++ b/pam.d/sshd
@@ -1,5 +1,8 @@
# PAM configuration for the Secure Shell service
+# for the yubikey
+auth required pam_oath.so usersfile=/etc/users.oath window=5 digits=8
+
# Standard Un*x authentication.
@include common-auth
sshd explicitely, with:
ChallengeResponseAuthentication yes
users.oath file. I filed bug #807990 regarding this, with a patch.
Also, it means the main password is still exposed on the client machine - you can use the sufficient keyword instead of required to workaround that, but then it means anyone with your key can login to your machine, which is something to keep in mind.
The /etc/users.oath file needs to be created with something like:
#type username pin start seed
HOTP anarcat - 00
00 is obviously a fake, and insecure string. Generate a proper one with:
dd if=/dev/random bs=1k count=1 sha1sum # create a random secret
ykpersonalize -1 -o oath-hotp -o oath-hotp8 -o append-cr -a
OATH password, you just touch the button on the key and it will be pasted there:
$ ssh -o PubkeyAuthentication=no anarc.at
One-time password (OATH) for anarcat':
Password:
[... logged in!]
~/.oath? Filed feature request #807992 about this as well.
I'm often using 
it looks like this autumn was not my best blogging time: this is the first
posting in 3 months. anyway, I wanted to give a quick overview about
my work on RC bugs. again nothing exciting, mostly just trying to fix the
ones popping up in the pkg-perl team.
). I want to shine a spotlight on the work that s done in Tanglu, be it ongoing or past work done for the new release.
Why is the new release taking longer than usual?
As you might have noticed, usually a new Tanglu release (Tanglu 4 Dasyatis ) should be released this month. We decided a while ago, however, to defer the release and are now aiming for an release in February / March 2016.
Reason for this change in schedule is 
. Apart from that, there are no teams maintaining other flavors in Tanglu.
Security & Stable maintenance
Thanks to several awesome people, the current Tanglu Stable release (Tanglu 3 Chromodoris ) receives regular updates, even for many packages which are not in the fully supported set.
Tangluverse Tasks
Tasks (not) done in the global Tanglu universe.
HTTPS for community sites
Thanks to our participation in the 
Hello dear readers and attendees,
This is the post that I will be/ will have been referencing during my presentation to the Seattle Central Community College s Byte club on Thursday, December 10th at 1500-1630.
I will begin with a bit of an autobio and find out what kind of students we have in attendance. Please feel free to comment if you d like to keep in touch before or after the presentation. I will discuss some of the bits and pieces of some industry standard platforms which I ve developed, deployed, maintained, managed, co-operated, administered and replaced. We can discuss some of the patterns that work well in the industry, and some that are a bit harder to tame.
Once we have touched most of the areas of specialization represented at the meeting, I will dive in to an AngularJS demo I am developing in github here:
My flight from Athens where I had the pleasure to attend the first
It s been a while since my last what s been happening behind the scenes e-mail so I m here to report on what has been happening within the GNOME Infrastructure, its future plans and my personal sensations about a challenge that started around three (3) years ago when 
