Systemd : logs et saisie de la passphrase de la clé privée associée à un certificat x509 utilisé par Apache
mardi 11 août 2015 à 13:19GuiGui's Show - Liens
Je rencontre deux problèmes avec systemd (enfin avec le systemd d'autrui, je suis pas assez maso pour être passé à cette techno du futur sur mes machines) sous Debian Jessie :
* systemd n'affiche pas les logs détaillés des services lancés au boot (exemple : [OK] SSH, [OK] Apache httpd server,...)
Solutions :
* Solution 1 : apt-get install sysvinit-core puis reboot mais c'est trop facile. :))))
SOIT
* Solution 2 : virer le « quiet » dans cmdline du noyau. Attention : ça ne semble pas fonctionner partout...
* Si la clée privée associé à un certificat x509 utilisé par un VirtualHost Apache nécessite un mot de passe, Apache httpd le demande bien lors du boot mais getty s'intercalle et le prompt de login apparaît sans avoir le temps de saisir la passphrase pour Apache.
Notons que systemd prévoit les demandes de passphrase au boot, que c'est intégré pour luks (partition système chiffrée) mais que ce n'est pas encore au point pour Apache. Voir : https://wiki.freedesktop.org/www/Software/systemd/PasswordAgents/ .
Notons que l'usage de la directive de configuration Apache « SSLPassPhraseDialog », que l'on place dans /etc/apache2/mods-available/ssl.conf car elle est commune à tous les VirtualHosts, et que l'on fait pointer sur un script qui fait appel à systemd-ask-password ne résoud pas le problème : la demande de passphrase apparaît mais getty prend la main trop vite... Voir ici pour des exemples de cette manip' : https://bugzilla.redhat.com/show_bug.cgi?id=707917
Solutions :
* Solution 1 : virer la passphrase. Si vous avez correctement corrigé le Perfect Forward Secrecy, alors les échanges passés sont en sécurité en cas de vol de votre clé privée. Si vous avez appliqué les bonnes permissions (root:root, 400), alors d'autres parties de votre système seront largement compromises si jamais on vous dérobe votre clé privée (car ça implique que le voleur était root donc game over complet). Mais c'est un contournement du problème un peu trop facile. :))))
SOIT
* Solution 2 : apt-get install sysvinit-core puis reboot mais c'est trop facile. :))))
SOIT
* Solution 3 : décaler le lancement des getty pour laisser le temps de saisir la passphrase. Notons que, contrairement à ce qui se produit avec sysvinit, cette solution ne bloque pas le lancement des autres services (SSH, mails, DNS,... en fonction de l'ordre de lancement), ce qui est super pratique en cas de reboot imprévu (vous recevez encore vos mails, par exemple) ou en cas de problème pour saisir la passphrase (SSH est fonctionnel).
* a) Ajouter « After=apache2 » dans l'unit getty (/etc/sytemd/system/getty.target.wants/getty@tty1.service ». Mais c'est sale : ce n'est pas à l'unit getty de s'adapter...
SOIT
* b) apache2 n'a pas d'unit systemd mais un initscript (/etc/init.d/apache2). Systemd parse les entêtes LSB. On peut donc ajouter « X-Start-Before: getty@tty1 » puis demander à systemd de re-parser et interprété les données LSB : systemctl daemon-reload. On peut vérifier la bonne génération : systemctl show apache2 | grep -i before doit afficher « Before=getty@tty1.service multi-user.target graphical.target shutdown.target ».
(Permalink)
Je rencontre deux problèmes avec systemd (enfin avec le systemd d'autrui, je suis pas assez maso pour être passé à cette techno du futur sur mes machines) sous Debian Jessie :
* systemd n'affiche pas les logs détaillés des services lancés au boot (exemple : [OK] SSH, [OK] Apache httpd server,...)
Solutions :
* Solution 1 : apt-get install sysvinit-core puis reboot mais c'est trop facile. :))))
SOIT
* Solution 2 : virer le « quiet » dans cmdline du noyau. Attention : ça ne semble pas fonctionner partout...
* Si la clée privée associé à un certificat x509 utilisé par un VirtualHost Apache nécessite un mot de passe, Apache httpd le demande bien lors du boot mais getty s'intercalle et le prompt de login apparaît sans avoir le temps de saisir la passphrase pour Apache.
Notons que systemd prévoit les demandes de passphrase au boot, que c'est intégré pour luks (partition système chiffrée) mais que ce n'est pas encore au point pour Apache. Voir : https://wiki.freedesktop.org/www/Software/systemd/PasswordAgents/ .
Notons que l'usage de la directive de configuration Apache « SSLPassPhraseDialog », que l'on place dans /etc/apache2/mods-available/ssl.conf car elle est commune à tous les VirtualHosts, et que l'on fait pointer sur un script qui fait appel à systemd-ask-password ne résoud pas le problème : la demande de passphrase apparaît mais getty prend la main trop vite... Voir ici pour des exemples de cette manip' : https://bugzilla.redhat.com/show_bug.cgi?id=707917
Solutions :
* Solution 1 : virer la passphrase. Si vous avez correctement corrigé le Perfect Forward Secrecy, alors les échanges passés sont en sécurité en cas de vol de votre clé privée. Si vous avez appliqué les bonnes permissions (root:root, 400), alors d'autres parties de votre système seront largement compromises si jamais on vous dérobe votre clé privée (car ça implique que le voleur était root donc game over complet). Mais c'est un contournement du problème un peu trop facile. :))))
SOIT
* Solution 2 : apt-get install sysvinit-core puis reboot mais c'est trop facile. :))))
SOIT
* Solution 3 : décaler le lancement des getty pour laisser le temps de saisir la passphrase. Notons que, contrairement à ce qui se produit avec sysvinit, cette solution ne bloque pas le lancement des autres services (SSH, mails, DNS,... en fonction de l'ordre de lancement), ce qui est super pratique en cas de reboot imprévu (vous recevez encore vos mails, par exemple) ou en cas de problème pour saisir la passphrase (SSH est fonctionnel).
* a) Ajouter « After=apache2 » dans l'unit getty (/etc/sytemd/system/getty.target.wants/getty@tty1.service ». Mais c'est sale : ce n'est pas à l'unit getty de s'adapter...
SOIT
* b) apache2 n'a pas d'unit systemd mais un initscript (/etc/init.d/apache2). Systemd parse les entêtes LSB. On peut donc ajouter « X-Start-Before: getty@tty1 » puis demander à systemd de re-parser et interprété les données LSB : systemctl daemon-reload. On peut vérifier la bonne génération : systemctl show apache2 | grep -i before doit afficher « Before=getty@tty1.service multi-user.target graphical.target shutdown.target ».
(Permalink)