Running Splunk forwarder on a FreeBSD 14 host

Few months ago I discovered that Splunk did not bother updating its forwarder to support FreeBSD 14. It’s a real PITA for many users, including myself. After asking around for support about that problem and seeing Splunk quietly ignoring the voice of its users, I’ve decided to try and run the Linux version on FreeBSD.

Executive summary: it works great on both FreeBSD 14 and 13, but with some limitations.

A user like me has few options:

  1. (re)check if you really need a local log forwarder (for everything that is not handled by syslog), if you don’t, just ditch the Splunk forwarder and tune syslogd to send logs to a Splunk indexer directly
  2. find an alternate solution that suits you: very hard is you have a full Splunk ecosystem or if, like me, you really are addicted to Splunk
  3. Run the Linux version on FreeBSD: needs some skills but works great so far

Obviously, I’m fine with the latest.


You will run a proprietary Linux binary on a totally unsupported environment: you are on your own & it can break anytime, either because of FreeBSD, or because of Splunk.

You will run the Splunk forwarder inside a chroot environment: your log files will have to be available inside the chroot, or Splunk won’t be able to read them. Also, no ACL residing on your FreeBSD filesystem will be available to the Linux chroot, so you must not rely on ACLs to grant Splunk access to your log files. This latest statement is partially wrong. You can rely on FreeBSD ACLs but it might require some tweaks on the user/group side.

How to

Below you’ll find a quick&dirty step by step guide that worked for me. Not everything will be detailed or explained and YMMV.

First step is to install a Linux environment. You must activate the Linux compatibility feature. I’ve used both Debian and Devuan successfully. Here is what I’ve done for Devuan:

zfs create -o mountpoint=/compat/devuan01 sas/compat_devuan01 
curl -OL
mv ceres /usr/local/share/debootstrap/scripts/daedalus
curl -OL
mv devuan-archive-keyring.gpg /usr/local/share/keyrings/
ln -s /usr/local/share/keyrings /usr/share/keyrings
debootstrap daedalus /compat/devuan01

This last step should fail, it seems that it’s to be expected. Following that same guide:

chroot /compat/devuan01 /bin/bash
dpkg --force-depends -i /var/cache/apt/archives/*.deb
echo "APT::Cache-Start 251658240;" > /etc/apt/apt.conf.d/00chroot

Back on the host, add what you need to /etc/fstab:

# Device        Mountpoint              FStype          Options                      Dump    Pass#
devfs           /compat/devuan01/dev      devfs           rw,late                      0       0
tmpfs           /compat/devuan01/dev/shm  tmpfs           rw,late,size=1g,mode=1777    0       0
fdescfs         /compat/devuan01/dev/fd   fdescfs         rw,late,linrdlnk             0       0
linprocfs       /compat/devuan01/proc     linprocfs       rw,late                      0       0
linsysfs        /compat/devuan01/sys      linsysfs        rw,late                      0       0

and mount all, then finish install:

mount -al
chroot /compat/devuan01 /bin/bash
apt update
apt install openrc

Make your log files available inside the chroot:

mkdir -p /compat/debian_stable01/var/hostnamedlog
mount_nullfs /var/named/var/log /compat/debian_stable01/var/hostnamedlog
mkdir -p /compat/debian_stable01/var/hostlog
mount_nullfs /var/log /compat/debian_stable01/var/hostlog

Note: /var/named/var/log and /var/log are ZFS filesystems. You’ll have to make the nullfs mounts permanent by adding them in /etc/fstab.

Now you can install the Splunk forwarder:

chroot /compat/devuan01 /bin/bash
ln -sf /usr/share/zoneinfo/Europe/Paris /etc/localtime
useradd -m splunkfwd
export SPLUNK_HOME="/opt/splunkforwarder"
echo /opt/splunkforwarder/lib >/etc/ 
apt install curl
dpkg -i splunkforwarder_package_name.deb
/opt/splunkforwarder/bin/splunk enable boot-start -systemd-managed 0 -user splunkfwd

Note: splunk enable boot-start -systemd-managed 0 activates the Splunk service as an old-school init.d service. systemd is not available in the context of a Linux chroot on FreeBSD.

Now from the host, grab your config files and copy them in your Linux chroot:

cp /opt/splunkforwarder/etc/system/local/{inputs,limits,outputs,props,transforms}.conf /compat/devuan01/opt/splunkforwarder/etc/system/local/

Then edit /compat/devuan01/opt/splunkforwarder/etc/system/local/inputs.conf accordingly: in my case it means I must replace /var/log by /var/hostlog and /var/named/var/log by /var/hostnamedlog.

Go back to your Devuan and start Splunk:

chroot /compat/devuan01 /bin/bash
service splunk start

To do

I still need to figure out how to properly start the service from outside the chroot (when FreeBSD boots). No big deal.

Related posts

Borgbackup: it’s complicated

As I wrote in a previous article, I'm using Borgbackup to back up some servers and workstations. And most of the time it's going OK. Unfortunately, when it's not OK, it can be very (very) hard to recover. Spoiler alert: one of my backup repositories had a problem, it took me 16 days and 1131 connections to the repository to fix it.

Few weeks ago, I've noticed that the Borg repository for the backups of my MacBook Pro was holding way too many backups. The pruning process was not doing its job properly. So I’ve started to investigate, and discovered that every attempt to prune older backups failed.
Trying to check the repository failed too: every single time the connection was reset. Apparently the remote server was dropping the SSH connection after a while (between 20 and 90 minutes). Client-side the error message was Connection closed by remote host.
I started to wonder if the problem was the very large number of backups, so I tried to delete backups manually. Some of them were easy to delete but most of the older backups needed delete --force and even delete --force --force, which is pretty bad.
Basically, I destroyed two years worth of backups, but it was still impossible to check and repair the repository. Also, the use of --force and --force --force makes it impossible to reclaim the space until you repair the repository.

Digging in the (mis)direction of a connection problem I’ve tried everything I could. It failed every single time:

  • tune ClientAliveInterval and ClientAliveCountMax server-side
  • tune ServerAliveInterval and ServerAliveCountMax client side
  • using and not using multiplexed ssh connections
  • moving the client to another physical network
  • using caffeinate to launch the borg command
  • using Amphetamine
  • upgrading ssh on the client
  • upgrading borg
  • giving mosh a try (nope)
  • running ssh with -vvv
  • using ktrace server-side to find the cause

None of this helped at all. Not to find a cause, not to make it work properly.
Eventually I stumbled upon this blog post: Repair Badly Damaged Borg Repository.

The repair method described failed too:
- step check --repair --repository-only worked
- but check --repair --archives-only died with the same Connection closed by remote host.
As a workaround attempt I’ve scripted a loop that would do check --repair --archives-only on every archive individually (~630).
After 3 full days and more than 600Go transferred from the repo to the client, every archives were checked and none was faulty.
Next step was to attempt check --repair again on the whole repository. About 15 hours later the output was

2851697 orphaned objects found!
Archive consistency check complete, problems found.

Full working solution for me:

borg check -p --repair --repository-only LOGIN@HOST:/path/to/repo
borg -p list LOGIN@HOST:/path/to/repo | awk '{print $1}' > listborg
cat listborg | while read i; do 
	borg -vp check --repair --archives-only LOGIN@HOST:/path/to/repo::$i
borg -p check --repair LOGIN@HOST:/path/to/repo

Final step was to reclaim space on the server with compact:

$ borg compact -p --verbose path/to/repo/
compaction freed about 376.22 GB repository space.

Boy that was painful!

I’m pretty sure it’s not really an ssh issue. Something is causing the connection to drop but I have ssh connections opened for days between that client and that server, so I guess ssh is not the problem here. Also, borgbackup’s github is loaded with issues about failing connections. In the end it boils down to:
- borg repositories can break badly without warning
- repairing a repo might not worth the bandwidth/CPU/IOs

Related posts

Moving to Borgbackup

I used to have a quite complicated backup setup, involving macOS Time Machine, rsync, shell scripts, ZFS snapshots, pefs, local disks, a server on the LAN, and a server 450 km away. It was working great but I've felt like I could use a unified system that I could share across every systems and that would allow me to encrypt data at rest.
Pure ZFS was a no-go: snapshot send/receive is very nice but it lacks encryption for data at rest (transfer is protected by SSH encryption) and macOS doesn't support ZFS. Rsync is portable but does not offer encryption either. Storing data in a pefs vault is complicated and works only on FreeBSD.
After a while, I've decided that I want to be able to store my encrypted data on any LAN/WAN device I own and somewhere on the cloud of a service provider. I've read about BorgBackup, checked its documentation, found a Borg repository hosting provider with a nice offer, and decided to give it a try.

This is how I've started to use Borg with hosting provider BorgBase.

Borg is quite simple, even though it does look complicated when you begin. BorgBase helps a lot, because you are guided all along from ssh key management to creation of your first backup. They will also help automating backups with a almost-ready-to-use borgmatic config file.

Borg is secure: it encrypts data before sending them over the wire. Everything travels inside an SSH tunnel. So it's perfectly safe to use Borg in order to send your backups away in the cloud. The remote end of the SSH tunnel must have Borg installed too.

Borg is (quite) fast: it compresses and dedup data before sending. Only the first backup is a full one, every other backup will send and store only changed files or part of files.

Borg is cross-plateform enough: it works on any recent/supported macOS/BSD/Linux.

Borg is not for the faint heart: it's still command line, it's ssh keys to manage, it's really not the average joe backup tool. As puts it: "You're here because you're an expert".

In the end, the only thing I'm going to regret about my former home-made backup system was that I could just browse/access/read/retrieve the content of any file in a backup with just ssh, which was very handy. With Borg this ease of use is gone, I'll have to restore a file if I want to access it.

I won't detail every nuts and bolts of Borg, lots of documentation exists for that. I would like to address a more organizational problem: doing backups is a must, but being able to leverage those backups is often overlooked.
I backup 3 machines with borg: A (workstation), B (home server), C (distant server). I've setup borgmatic jobs to backup A, B and C once a day to BorgBase cloud. Each job uses a dedicated SSH key and user account, a dedicated Repository key, a dedicated passphrase. I've also created similar jobs to backup A on B, A on C, B on C (but not Beyoncé).
Once you are confident that every important piece of data is properly backed up (borg/borgmatic job definition), you must make sure you are capable of retrieving it. It means even if a disaster occurs, you have in a safe place:

  • every repository URIs
  • every user accounts
  • every SSH keys
  • every repository keys
  • every passphrases

Any good password manager can store this. It's even better if it's hosted (1password, dashlane, lastpass, etc.) so that it doesn't disappear in the same disaster that swallowed your data. Printing can be an option, but I would not recommend it for keys, unless you can encode them as QRCodes for fast conversion to digital format.

You must check from time to time that your backups are OK, for example by restoring a random file in /tmp and compare to current file on disk. You must also attempt a restoration on a different system, to make sure you can properly access the repository and retrieve files on a fresh/blank system. You can for example create a bootable USB drive with BSD/Linux and borg installed to have a handy recovery setup ready to use in case of emergency.

Consider your threat model, YMMV, happy Borg-ing.

Related posts

Recherche Administratrice/teur Systèmes en alternance

Au sein du Service Opérations de la DSI de l'Université Lyon 2, nous cherchons un ou une Administrateur/trice Systèmes en alternance pour nous aider à relever des défis au quotidien.
Lieu de travail : campus de Bron (arrêt de tram T2 Europe Université).

  • Vous habitez la région Lyonnaise ;
  • Vous êtes motivée par les enjeux de la gestion d’un parc de plus de 400 serveurs Linux RedHat/CentOS (70%), Windows, FreeBSD ;
  • Les problématiques d’une ferme de virtualisation multi-site avec balance de charge, PRA, sauvegardes croisées ne vous font pas peur ;
  • Les infrastructures à fort enjeu de disponibilité, les outils d’automatisation, de monitoring et les SIEM vous intéressent ;
  • Vous êtes passionnée par les problématiques système et souhaitez évoluer dans un environnement riche et varié ;
  • Vous êtes curieuse, très rigoureuse et vous avez le sens du service.

Si vous vous reconnaissez dans ce profil, contactez-moi !

terminal - édition d'un script shell

Édition d'un script shell dans le terminal

Related posts

Install Fast Incident Response (FIR) on FreeBSD

FIR login screen FIR is a web application designed by CERT Société Générale. It's coded in Python and uses Django.

Installation as documented uses Nginx and pip, two tools I'm not using. I already run several Apache servers, and I do prefer relying on pkg for software installation. For me, pip is more a developer tool: very convenient with virtualenv but not what I would use for production.
If you want to use pip, just go with the official documentation :)

So on a FreeBSD 11.2-RELEASE server, you need to install all required packages. Be careful, py27-MySQLdb uses mysql56-server, not mysql57-server, and FIR works with Python 2.7, not 3.x (as far as I can say).

$ sudo pkg install gettext mysql56-server py27-pip py27-virtualenv git apache24 uwsgi py27-MySQLdb py27-django py27-cssselect py27-django-filter py27-djangorestframework py27-flup6 py27-gunicorn py27-lxml py27-markdown py27-pymongo py27-pyquery py27-dateutil py27-pytz py27-six py27-django-treebeard py27-markdown2 py27-bleach py27-python-gettext

Add those lines to /etc/rc.conf:


The requirement list includes dj-database-url and whitenoise, but I was not able to find them in FreeBSD's packages. I've just ignored them and everything seems to work fine.
If needed, sudo pip install… should do the trick.

Follow the documentation:
- configure MySQL
- install FIR without virtualenv (in /usr/local/www for example)
- create and tune
- create installed_apps.txt (you do want the plugins)
- create tables in the db
- create the admin user
- populate the db
- collect static files

On FreeBSD we run uwsgi as a service, under uwsgi UID. So chown must reflect that:

$ sudo chown uwsgi logs/errors.log uploads
$ sudo chmod 750 logs/errors.log uploads

Skip the uWSGI section of the documentation. Instead, create config file for uwsgi with this content:

$ cat /usr/local/etc/uwsgi/uwsgi.ini
chdir = /usr/local/www/FIR
module = fir.wsgi

You can now start the service:

$ sudo service uwsgi start

Then, skip the nginx part, and go configure Apache:

- load proxy_module and proxy_uwsgi_module in httpd.conf
- add the following to the relevant part of Apache configuration:

ProxyPass /FIR unix:/tmp/uwsgi.sock|uwsgi://usr/local/www/FIR
Alias /files/ /usr/local/www/FIR/files/
Alias /static/ /usr/local/www/FIR/static/
<Directory /usr/local/www/FIR/static>
	Require all granted
<Directory /usr/local/www/FIR/files>
	Require all granted

Restart Apache: you're all set, point your browser to https://your-server/FIR/

Related posts

Self-hosted password manager: installing Passbolt on FreeBSD

Arthur Duarte CC-BY-SA-4.0

Arthur Duarte CC-BY-SA-4.0

Password managers, or password safes, are an important thing these days. With the constant pressure we (IT people) put our users under to setup a different password for every single registration/application/web site, it's the best, if not only, way to keep track of these secrets. On one hand, the isolated client-side software can be really powerful and/or well integrated with the OS or the software ecosystem of the user, but it lacks the modern touch of "cloud" that makes your data available anywhere and anytime. On the other hand, a full commercial package will come with client for every device you own, and a monthly fee for cloud synchronization, but you have absolutely no control over your data (just imagine that tomorrow the company you rely on goes bankrupt).
Better safe than sorry: I don't rely on cloud services. It comes at a cost, but it's quite rewarding to show the world another way exists.
Disclaimer: I don't give a sh*t about smartphones, so my needs are computer-centric.

In order to store passwords, and more generally speaking "secrets", in such a way that I can access them anywhere/anytime, I've tried Passbolt. Passbolt is an OpenSource self-hosted password manager, written in PHP/Javascript with a database back end. Hence, install and config are not for the average Joe. On the user side it's quite clean and surprisingly stable for alpha software. So once a LAMP admin has finished installing the server part, any non-skilled user can register and start storing passwords.

Enough chit-chat, let's install.

My initial setup was a vanilla FreeBSD 10.3 install, so I've had to make everything. I won't replay every single step here, especially on the configuration side.


pkg install apache24
pkg install mod_php56
pkg install php56-gd
pkg install pecl-memcached
pkg install mysql57-server
pkg install pecl-gnupg
pkg install git
pkg install php56-pdo_mysql
pkg install sudo
pkg install php56-openssl
pkg install php56-ctype
pkg install php56-filter

Everything else should come as a dependency.


Apache must allow .htaccess, so you'll have to put an AllowOverride All somewhere in your configuration. You must also load the Rewrite module. Also, go now for SSL (letsencrypt is free and supported). Non-SSL install of Passbolt are for demo purpose only.
Apache will also need to execute gnupg commands, meaning the www user needs an extended $PATH. The Apache startup script provided on FreeBSD sources Apache environment variables from /usr/local/sbin/envvars and this very file sources every /usr/local/etc/apache24/envvars.d/*.env, so I've created mine:

$ cat /usr/local/etc/apache24/envvars.d/path.env

You also need to tune your MySQL server. If you choose the 5.7, you must edit it's configuration. Just add the following line into [mysqld] section of /usr/local/etc/mysql/my.cnf:


This is due to a bug in Passbolt and could be useless in a not to distant future.

Install recipe:

You can now follow the install recipe at
Generating the GPG key is quite straightforward but you have to keep in mind that Apache's user (www) will need access to the keyring. So if you create this key and keyring with a different user, you'll have to mv and chown -R www the full .gnupg directory somewhere www can read it (outside DocumentRoot is perfectly fine).

Use git to retrieve the application code into appropriate path (according to your Apache config):

cd /usr/local/www
git clone

Edit php files as per the documentation.

Beware the install script: make sure you chown -R www the whole passbolt directory before using cake install.
On FreeBSD you won't be able to use su to run the install script, because www's account is locked. You can use sudo instead:

sudo -u www app/Console/cake install --no-admin

Same for the admin account creation:

sudo -u www app/Console/cake passbolt register_user -u -f Pat -l Pro -r admin

Follow the end of the install doc, and you should be ok. Install the Firefox passbolt extension into your browser, and point to your server.

I'm pretty happy with passbolt so far. I'll have to install a proper production server, with SSL and all, but features are very appealing, the passbolt team is nice and responsive, and the roadmap is loaded with killing features. Yeah BRING ME 2FA \o/.

Related posts

Monter un serveur d’authentification multifacteur 3/3

insertedDans deux articles précédents j'ai présenté la création d'un serveur de validation YK-VAL et d'un serveur de clé YK-KSM permettant de créer une infrastructure d'authentification double facteur basée sur Yubico OTP.

Dans ce dernier article je vais détailler quelques étapes importantes pour connecter un client, toujours en FreeBSD 10.3. Dans ce contexte, le client est en fait un service authentifié (un serveur sshd par exemple).


À ce stade, posséder une Yubikey dont vous pourrez configurer un des slots est impératif. Il est aussi pertinent de télécharger sur votre poste le Yubikey Personalization Tool. Et il vous faut bien évidemment une machine sous FreeBSD 10.x qui servira de serveur sshd.

Générer une clé d'API

La validation d'une authentification par OTP Yubico requière que l'utilisateur fournisse un OTP reconnu, c'est à dire que sa Yubikey soit enregistrée dans le YK-KSM, et que l'OTP envoyé soit valide. Il est aussi nécessaire que la connexion entre le client (ici sshd+pam) et le serveur YK-VAL soit "authentifiée" par une clé d'API.

Dans l'idéal, chaque client individuel doit disposer de sa propre clé d'API, c'est plus sûr. Et même si cela peut occasionner des lourdeurs, cela permet de révoquer une clé d'API sans mettre par terre l'ensemble des clients.

La première étape pour ajouter un client dans l'infrastructure est donc de créer une clé d'API. Pour cela, il faut se connecter sur le serveur YK-VAL, et lancer la commande suivante :

ykval-gen-clients --urandom --notes "client de test 1"

Cette commande vous donne en résultat une clé d'API, associée au client "1". La clé d'API et les informations connexes sont injectées dans la base de données du serveur YK-VAL.

Enregistrer une Yubikey

Chaque Yubikey compatible Yubico OTP dispose de deux slots de configuration. Le premier est réglé par défaut sur Yubico OTP, mais il est impossible d'en extraire la clé privée de chiffrement (configuration d'usine). Cette clé est enregistrée dans le YK-KSM des serveurs, donc elle est opérationnelle si vous souhaitez l'utiliser pour vous authentifier sur des services qui s'appuient sur le cloud de Nous souhaitons nous appuyer sur notre propre infrastructure privative, donc cette clé n'est pas utilisable.
Si vous souhaitez conserver cette clé initiale, vous devrez créer une nouvelle clé privée sur le slot 2 de votre Yubikey (et je vous y encourage). Si vous êtes sûr de ne pas en avoir l'usage, vous pouvez simplement écraser le slot 1 de la Yubikey avec votre nouvelle clé privée. Sachez que l'écrasement d'un slot est irréversible : la clé privée fournie par Yubico sera définitivement perdue.

Ceci posé, vous pouvez connecter votre Yubikey à votre machine, et lancer le Yubikey Personalization Tool.
Dans l'interface, choisissez le premier onglet en haut à gauche "Yubico OTP", et cliquez sur "Quick".
La fenêtre ci-dessous est affichée :
- choisissez le slot 1 (écrasement de la configuration d'usine) ou le slot 2 (vierge)
- décochez la case "Hide values"
- copiez précieusement les chaînes de caractères des trois champs, ainsi que le serial number au format décimal ("Dec") qui se trouve au milieu à droite de la fenêtre.

Yubico Personalization Tool

Il s'agit ensuite d'enregistrer ces informations dans la base de données du YK-KSM. Dans le cadre de ces tests, j'ai simplement injecté la clé à la main dans MySQL :

INSERT INTO yubikeys VALUES (4263215,"vvgrneginvdf","","578fba7ca791","fd69d1ecc644f36dde9dfc742cf2e3fa","00000000","",1,1);

Les champs sont dans l'ordre d'apparence : le numéro de série "Dec" de votre clé physique, la date de création (non renseignée), la "Public Identity" de votre clé de chiffrement, la "Private Identity" de votre clé de chiffrement, et enfin la "Secret Key". Les champs suivants sont "lockcode", "creator" (vide), "active" et "hardware". Laissez-les simplement comme présenté ci-dessus.

Dès que vous avez procédé à l'insertion, vous pouvez tester que la clé est bien reconnue par le serveur YK-KSM. Générez un OTP avec votre clé en appuyant un court instant sur le bouton si vous utilisez le slot 1, ou 2-3 secondes si vous utilisez le slot 2 (placez au préalable votre curseur dans un document txt).
Ensuite tapez la commande suivante sur le serveur YK-KSM :

curl 'http://localhost/wsapi/decrypt?otp=vvgrneginvdfddffbdhgefnrdtgcrnntccchndebhdiv'

ou vvgrneginvdfddffbdhgefnrdtgcrnntccchndebhdiv est l'OTP que vient de générer votre clé.
Vous obtiendrez alors la réponse suivante :

OK counter=0001 low=8250 high=45 use=02

Vous pouvez ensuite tester que votre Yubikey passe bien la validation de bout en bout. À partir d'un terminal sur YK-VAL, lancez la commande suivante :

ykclient --url "" --apikey VI5eTtCSAjdmp473G3rWFq+pL1k= 1 vvgrneginvdfihrudhtffnjigivctkujtfjlkiniideg --debug

L'argument --apikey doit être suivi de la clé d'API que vous avez générée plus haut. Elle est suivit d'un espace, puis du numéro d'ID du client que vous avez inséré (et donné dans la sortie de la commande ykval-gen-clients). À la suite de ce client ID, on injecte un OTP, et éventuellement l'argument --debug.

Si tout va bien, vous devez obtenir dans la sortie :

  validation URL:
  client id: 1
  token: vvgrneginvdfihrudhtffnjigivctkujtfjlkiniideg
  api key: VI5eTtCSAjdmp473G3rWFq+pL1k=
Verification output (0): Success

Configuration du client

Pour brancher un serveur sshd sur une infrastructure d'authentification double facteur, le plus simple est en général d'utiliser un plugin PAM. Sur FreeBSD, on peut en quelques secondes installer le nécessaire :

pkg install pam_yubico

Ce plugin s'appuie sur deux choses : l'URL de votre service YK-VAL, et une liste qui associe les logins des utilisateurs avec une clé ("Public Identity").
Vous pouvez créer le fichier qui associe l'uid UNIX à la "Public Identity" très simplement :

cat "patpro:vvgrneginvdf" >> /etc/yubikey

Puis dans /etc/pam.d/sshd il faut ajouter la directive qui permettra à PAM de faire la requête vers YK-VAL. La ligne suivante doit être ajoutée :

auth      required      /usr/local/lib/security/ mode=client authfile=/etc/yubikey id=1 key=VI5eTtCSAjdmp473G3rWFq+pL1k= url=

juste au dessus de la ligne :

auth      required     no_warn try_first_pass

authfile pointe vers votre fichier associant uid et clé OTP, id est la Client ID créée lors de l'ajout du client sur YK-VAL, key est la clé d'API associée à ce client. Pour finir, url est l'adresse du service de vérification sur YK-VAL. On peut tout à fait inscrire le nom du serveur YK-VAL dans l'URL à la place de son adresse IP, néanmoins en cas d'avarie du DNS il est souhaitable que l'authentification continue de fonctionner.

Dernière étape : la configuration du serveur sshd. Il s'agit assez simplement de modifier /etc/ssh/sshd_config pour s'assurer que les paramètres suivants sont actifs :

PasswordAuthentication no
ChallengeResponseAuthentication yes

Relancez ensuite sshd avec la commande service sshd restart et tentez la connexion à partir d'une machine sur laquelle votre Yubikey est connectée :

$ ssh patpro@
YubiKey for `patpro': 
Password for
Last login: Fri May  6 21:33:58 2016 from
FreeBSD 10.3-RELEASE (GENERIC) #0 r297264: Fri Mar 25 02:10:02 UTC 2016

Welcome to FreeBSD!



Pour réaliser cette infrastructure privative d'authentification double facteur et les articles qui en découlent, je me suis appuyé sur les sources suivantes :

yubikey-ksm, principes et installation.
yubikey-val, principes et installation.
Building a local Yubikey server infrastructure (sur Linux).
yubico-pam, README.
YubiKey on FreeBSD HOWTO, aspect "client" uniquement, utilisant en plus pam_per_user.

Related posts

Monter un serveur d’authentification multifacteur 2/3

Dans un article précédent, j'ai présenté les étapes nécessaires à l'installation du serveur de validation YK-VAL de Yubico sur FreeBSD 10.3. Ce serveur s'intègre dans l'infrastructure d'authentification double facteur Yubico selon le schéma ci-dessous.
proposition d'infrastructure YK-VAL YK-KSM

D'autres modèles sont possibles bien évidemment, comme celui qui consiste à mettre les services YK-VAL et YK-KSM sur la même machine.
La suite des opérations consiste à créer le serveur YK-KSM en suivant la documentation officielle de Yubico, et les informations ci-après.

Serveur de clés YK-KSM

Pour assurer la sécurité lors des manipulations de clés, ce serveur est supposé n'utiliser que des fichiers chiffrés via OpenPGP/GnuPG. Aussi, l'outil ykksm-import nécessite-t-il qu'une clé GnuPG soit utilisée pour chiffrer les clés en amont, à leur création sur le poste de l'administrateur par exemple. Il est néanmoins tout à fait possible de ne pas utiliser les commandes ykksm-gen-keys et ykksm-import pour faire fonctionner l'infrastructure d'auth double facteur. Il suffit alors de fournir les clés à la main en les injectant directement dans la table MySQL ad-hoc.

Les étapes supplémentaires liées à OpenPGP n'étant pas complexes à mettre en œuvre, je les présente tout de même.
Il s'agit donc dans un premier temps d'installer gnupg, et de créer une clé maîtresse. Cette clé est utilisée sur le poste qui servira à générer les clés Yubico (ici le serveur lui-même), et sur le serveur YK-KSM pour les déchiffrer au moment de les injecter dans la base de données.

Pour une raison qui m'échappe, le fonctionnement de pinentry-tty est assez hasardeux à l'intérieur d'une Jail, donc si vous souhaitez, comme moi initialement, faire l'installation du service YK-KSM dans une Jail, passez votre chemin, vous gagnerez du temps :)

La partie GnuPG est assez simple :

pkg install gnupg
gpg2 --full-gen-key

Et suivez l'exemple de la doc Yubico. Une fois que votre clé GnuPG est créée, vous pouvez passer à l'installation du service YK-KSM proprement dite.

pkg install git help2man p5-DBI mysql56-server p5-DBD-mysql apache24 mod_php56 php56-xml php56-curl php56-hash php56-pdo_mysql php56-mcrypt
git clone git://
cd yubikey-ksm

L'utilisation de GIT n'est pas obligatoire, on peut aussi bien télécharger le à partir de github, comme je l'ai fait pour YK-VAL.
Tout comme pour ce dernier, le Makefile est inexploitable en l'état, j'ai donc eu recours à quelques bricoles pour générer l'environnement adéquat avant d'installer les fichiers à la main :

for DIR in $(awk '/prefix = / {print $3}' Makefile); do
	[ -d $DIR ] || mkdir -p $DIR

La commande awk '/prefix = / {print $1"="$3}' Makefile nous donne une série de variables, à laquelle j'ajoute DESTDIR, que l'on fourni ensuite à bash :


Cette fois-ci, les commandes ykksm-* utilisables dans le shell sont codées en Perl avec un shebang compatible Linux, pas FreeBSD. On peut faire un lien symbolique de /usr/local/bin/perl vers /usr/bin/perl ou on peut corriger les scripts avant de les installer :

sed -i'.old' 's,/usr/bin/perl,/usr/local/bin/perl,' ykksm-import
sed -i'.old' 's,/usr/bin/perl,/usr/local/bin/perl,' ykksm-gen-keys
sed -i'.old' 's,/usr/bin/perl,/usr/local/bin/perl,' ykksm-export
sed -i'.old' 's,/usr/bin/perl,/usr/local/bin/perl,' ykksm-checksum

Puis on lance la copie des différents éléments :

cp .htaccess ${DESTDIR}${phpprefix}/.htaccess
cp ykksm-decrypt.php ${DESTDIR}${phpprefix}/ykksm-decrypt.php
cp ykksm-utils.php ${DESTDIR}${phpprefix}/ykksm-utils.php
cp ykksm-gen-keys ${DESTDIR}${binprefix}/ykksm-gen-keys
cp ykksm-import ${DESTDIR}${binprefix}/ykksm-import
cp ykksm-export ${DESTDIR}${binprefix}/ykksm-export
cp ykksm-checksum ${DESTDIR}${binprefix}/ykksm-checksum
cp ykksm-config.php ${DESTDIR}${etcprefix}/ykksm-config.php
cp ykksm-gen-keys.1 ${DESTDIR}${manprefix}/ykksm-gen-keys.1
cp ykksm-import.1 ${DESTDIR}${manprefix}/ykksm-import.1
cp ykksm-export.1 ${DESTDIR}${manprefix}/ykksm-export.1
cp ykksm-checksum.1 ${DESTDIR}${manprefix}/ykksm-checksum.1
cp ykksm-db.sql ${DESTDIR}${docprefix}/ykksm-db.sql
cp Makefile ${DESTDIR}${docprefix}/
cp doc/* ${DESTDIR}${docprefix}/

L'étape suivante est l'installation de la base de données. Suivez simplement les instructions de l'étape 3 de la doc Yubico.

J'ai traité l'étape 4 différemment de ce qui est proposé. J'ai préféré tout mettre dans le fichier .htaccess :

<IfModule mod_php5.c>
  php_value include_path ".:/etc/yubico/ksm:/usr/share/yubikey-ksm"

RewriteEngine on
RewriteRule ^([^/\.\?]+)(\?.*)?$ $1.php$2 [L]

L'étape 5 se traite exactement de la même manière que pour YK-VAL. Et l'étape 6 se fait simplement en créant les liens symboliques à la main.

À l'étape 7, tout comme pour YK-VAL, on renseigne le mot de passe MySQL dans le fichier de configuration ykksm-config.php.

Ensuite, sous réserve que votre serveur web soit lancé, il ne vous reste qu'à tester que tout fonctionne. Comme indiqué dans la doc, le résultat attendu est une erreur de clé inconnue, ce qui est tout à fait normal.

Fabrication de clés et import dans la base de données

Les vraies clés seront ajoutées ultérieurement. Mais vous pouvez néanmoins tester l'ajout de clés bidons via ykksm-gen-keys et ykksm-import.

La fabrication de 5 clés se fait comme ceci (doc officielle) :

ykksm-gen-keys --urandom 1 5 | gpg -a --encrypt -r 67A59965 -s > keys.txt

où 67A59965 est l'ID de la clé GnuPG fabriquée un peu plus haut.

Ensuite l'import des clés se fait de cette manière (doc officielle) :

ykksm-import --verbose --database 'DBI:mysql:dbname=ykksm;host=localhost' --db-user ykksmimporter --db-passwd mot-de-passe-mysql < keys.txt

Dans un troisième et dernier article il sera question de la partie vraiment intéressante : comment provisionner de vraies clés, et comment brancher un Client YK (un serveur sshd par exemple) sur votre nouvelle infrastructure d'authentification double facteur.

Related posts