Sur l'interface web Aruba Mobility Master (v8.6), je génère une CSR. Je la communique à notre autorité de certification x509 (AC), et j'obtiens un certificat x509.

Je récupère ce certificat au format PEM, je l'uploade dans l'interface web Aruba Mobility Master, et je me mange l'erreur : « Cert public key did not match the private key in the CSR store ».
Non, je n'ai pas généré une autre CSR entre-temps. Oui, j'ai bien récupéré le certificat qui correspond à la CSR depuis l'interface web de notre AC.

Solution : récupérer le certificat au format PKCS#7 (ou PKCS#7 PEM) auprès de notre AC. L'upload fonctionne alors très bien… … …

Si t'as une VM Aruba Mobility Master v8.6 (ArubaOS) sur un hyperviseur Proxmox + KVM, convertie depuis l'image disque VMWare livrée par Aruba, il faut la configurer pour utiliser le chipset q35 (au lieu de i440fx par défaut) sinon l'interface web Aruba freezera très régulièrement (affichage partiel + aucune réaction aux clics dans les menus).

J'ai aucune idée de la fonctionnalité du chipset q35 dont ArubaOS a besoin (PCI-E ? :D Secure Boot ? :D AHCI ? vIOMMU ?).

Je rappelle qu'il faut également choisir un modèle de CPU qui prend en charge les instructions SSSE3 sinon Aruba Mobility master ne démarre pas.

Sur l'interface web d'Aruba Mobility Master v8.6, je tente d'uploader un nouveau certificat x509 : « Error : Expecting string of length 1 to 31 ». Il faut que la longueur du nom du fichier contenant le certificat n’excède pas 31 caractères… … …

J'étais au-dessus car, dans le nom du fichier, nous mettons le common name ainsi que le numéro de commande auprès de notre autorité de certification afin de superviser et de retrouver facilement un certificat. Dingue qu'Aruba ne prenne pas en charge un cas aussi banal.

Sur notre parc Ubuntu 20.04, chromium ne fonctionne pas. Chromium est installé avec snap. L'ensemble pose deux problèmes :

• Le profil AppArmor livré ne prend pas en charge les homedirs situés ailleurs que dans /home/ et/ou montés en NFS (non, il ne suffit pas de configurer les variables dans /etc/apparmor.d/tunables/home.d, lire ci-dessous pour les détails) ;
  
  
• Indépendamment d'AppArmor (le désactiver ne résout pas le problème), snap ne semble pas gérer des homedirs (dossier personnel) montés en NFS. Voir : https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662552 et https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1884299.

On notera également que le dossier Téléchargements se trouve dans ~/snap/chromium/current/Téléchargements. Super pratique pour un utilisateur !

Au final, on a installé Google Chrome (qui n'est pas diffusé via snap) et basta. :( On a autre chose à faire que de compiler chromium régulièrement depuis les sources et on n'a pas trouvé de dépôt apt à jour et de confiance (ce qui permettrait de nous passer de snap).

Démarche (tests effectués) et découverte d'AppArmor :

• Chemin vers homedir = /home/$uid + absence de NFS : chromium démarre ;

• Chemin vers homedir = /home/$uid + NFS : chromium ne démarre pas, erreur « cannot open path of the current working directory: Permission denied » ;

  • cd /tmp/ && chromium-browser : chromium démarre (+ snap écrit dans $HOME/snap ! Je croyais que t'arrivais pas à y accéder ?!) ;

• Chemin vers homedir = /home/$nas/$categorie/$uid + NFS : même comportement et même erreur ;

  • cd /tmp && chromium-browser : chromium ne démarre pas, erreur « cannot create user data directory: /home/$nas/$categorie/$uid/snap/chromium/1753: Permission denied ». En fonction de la configuration d'AppArmor (voir ci-dessous), l'erreur peut aussi être « cannot create user data directory: /home/$nas/$categorie/$uid/snap/chromium/1753: Stale file handle ».

Le dernier point est lié au profil AppArmor /var/lib/snapd/apparmor/profiles/snap-confine.snapd.12883.

• Si je désactive totalement AppArmor (ajouter apparmor=0 dans GRUB_CMDLINE_LINUX_DEFAULT dans /etc/default/grub puis lancer update-grub2 puis redémarrer), je n'ai plus de problème pour lancer chromium depuis /tmp (ou autre endroit sans NFS). Sur le web, on lit que la commande systemctl disable apparmor et un redémarrage permettent de désactiver AppArmor : ce n'est pas exact ;
  
  
• Si je passe le profil en mode complain (geindre dans les journaux sans rien bloquer), chromium démarre toujours quand pwd = /tmp. Comme le profil n'est pas dans /etc/apparmor.d, la commande aa-complain /snap/snapd/12883/usr/lib/snapd/snap-confine sort en erreur « Profile for /snap/snapd/12883/usr/lib/snapd/snap-confine not found, skipping » (idem avec « /var/lib/snapd/apparmor/profiles/snap-confine.snapd.12883 »). Pour passer outre : ln -s /var/lib/snapd/apparmor/snap-confine.snapd.12883 /etc/apparmor.d/ && aa-complain /snap/snapd/12883/usr/lib/snapd/snap-confine. Quid de la pérennité ? « 12883 » dans le nom du profil est la révision de snapd… qui changera lors des mises à jours… ;
  
  
• Si je passe le profil en mode complain, je m'aperçois qu'AppArmor empêche snap d'accéder à /home/ et /home/$nas en lecture ainsi que d'envoyer des messages réseau pour accéder à notre NAS en NFS. Pour débrayer le premier problème, il faut ajouter les lignes /home/ r, et /home/$nas/ r, dans le profil. Pour NFS, il faut ajouter une ligne network, dans le profil. Puis je recharge le profil avec apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap-confine.snapd.12883 (on lit souvent que systemctl reload apparmor fait le job, mais c'est incorrect). Quid de la pérennité ? « 12883 » dans le nom du profil est la révision de snapd, donc le nom du profil (et/ou son contenu) changera lors des mises à jours… ;
  
  
• Il est vain de désactiver le profil (ln -s /var/lib/snapd/apparmor/profiles/snap-confine.snapd.12883 /etc/apparmor.d/disable/ + reboot), le lancement de chromium génerera l'erreur « snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks » ;
  
  
• Il n'est pas possible de désinstaller AppArmor car snapd dépend de lui et chromium dépend de snapd…

Un collègue (merci, Maxime) m'a fait découvrir sshpass qui permet d'automatiser / scripter une connexion SSH par mot de passe. Paquet logiciel du même nom dans Debian.
Le mot de passe est transmis à sshpass en argument ou dans un fichier ou dans une variable d'environnement ou dans un descripteur de fichier.

Au final, sshpass fonctionne comme expect : il lance ssh (fork(), exec()), il lit la sortie standard, quand ssh demande le mot de passe, il l'envoie sur l'entrée standard. « -P » permet d'ailleurs de changer la chaîne de caractères à laquelle sshpass réagit.
Ça signifie aussi que toute demande imprévue de ssh est bloquante genre vérification de l'empreinte de la clé du serveur ou demande de la passphrase d'une clé SSH si l'on a une directive « IdentityFile » dans son ssh_config. « -v » permet de visualiser ce qui bloque.

Je préfère l'authentification par clé SSH sans passphrase dédiée à un compte utilisateur sur le serveur lui-même dédié à un script / à un ensemble de scripts d'un même périmètre / giron (cela permet une traçabilité des accès sans contrainte excessive) avec droits d'accès limités (droits fichiers ou droits sudo précis), mais c'est intéressant de savoir que sshpass existe pour les cas où l'auth par clé n'est pas en place.