Monthly Archives: June 2018

Connexion automatique d’un utilisateur avec une session verrouillée (sddm)

Connexion automatique d’un utilisateur

Il faut éditer le fichier de configuration de sddm afin d’ajouter les entrées de connexion automatique d’un utilisateur, dans la section Autologin:

  • Session: spécifier la session utilisateur (plasma, gnome, etc…). La liste des sessions disponible (installée sur votre poste) se trouve dans le répertoire /usr/share/xsessions/
    ls /usr/share/xsessions/
  • Relogin: Spécifier si sddm doit reconnecter l’utilisateur lorsque celui-ci se déconnecte
  • User: Le login de l’utilisateur à connecter automatiquement
Fichier /etc/sddm.conf
...
[Autologin]
Relogin=false
Session=plasma.desktop
User=tartarefr
...

Verrouillage de la session au démarrage

Pour verrouiller la session d’un utilisateur au démarrage de celle-ci, il faut ajouter au fichier (ou le créer s’il n’existe pas) ~/.profile

Fichier ~/.profile
export DESKTOP_LOCKED=yes

La ligne de commande correspondante (pour un copier/coller)

echo "export DESKTOP_LOCKED=yes" >> ~/.profile

Remplacer les mots de passe par l’insertion d’une clé USB

Ou comment remplacer ce que l’on sait (le mot de passe) par ce que l’on possède (une clé USB particulière). Cela permet de donner une seconde vie à des clés USB totalement obsolètes de par leur taille vraiment faible (inférieure à 1Go).

Pamusb permet de se connecter sans avoir à taper un mot de passe. Pour cela un module PAM est ajouté et la sécurité repose sur la possession de cette fameuse clé. Bien que cela ne soit pas impossible, il est très difficile de remplacer cette clé, qui sera reconnue par son ID (iSerial) et qui possédera le même secret partagé que l’ordinateur. C’est cette dernière partie qui est très difficile à reproduire car le secret partagé est changé à chaque utilisation.

Pour obtenir ce numéro de série, on fait la différence de la commande lsusb avant et après l’insertion de la clé pour en déduire le numéro du bus et de device. Pour moi c’est ça

Bus 002 Device 007: ID 04e8:1623 Samsung Electronics Co., Ltd

J’interroge donc lsusb (en tant que superutilisateur root) sur ce périphérique et je vais comparer ce chiffre à celui que me proposera pam-usb lors de la configuration de ma clé USB.

sudo lsusb -s 002:007 -v | grep iSerial
iSerial 3 0123456789AB

L’installation de pam-usb est triviale

sudo dnf install pam_usb

On branche ensuite notre clé USB, si ce n’est pas déjà fait, (sans montage de partition) et on la déclare comme clé utilisable par pam-usb en lui donnant un nom

sudo pamusb-conf --add-device masterkey
Please select the device you wish to add.
* Using "Samsung Mighty Drive (0123456789AB)" (only option)

Which volume would you like to use for storing data ?
* Using "/dev/sdh1 (UUID: 99899601-c7de-4086-bc81-f2ff36a0b509)" (only option)

Name            : masterkey
Vendor          : Samsung
Model           : Mighty Drive
Serial          : 0123456789AB
UUID            : 99899601-c7de-4086-bc81-f2ff36a0b509

Save to /etc/pamusb.conf ?
[Y/n]

Impossible d’écrire dans le fichier /etc/pamusb.conf

Le fichier /etc/pamusb.conf par défaut comporte des commentaires multi-lignes.

Bien que cela soit valide d’un point de vue XML, pam-usb n’aime vraiment pas ça.

De plus la bonne indentation du fichier est le cadet de ses soucis.

Donc on écrit un fichier valide pour pam-usb et on s’occupera de l’indentation manuellement à la fin.

sudo mv/etc/pamusb.conf /etc/pamusb.conf.orig
sudo echo '<configuration><defaults></defaults><devices></devices><users></users><services></services></configuration>' > /etc/pamusb.conf

On ajoute notre utilisateur

sudo pamusb-conf --add-user tartarefr
Which device would you like to use for authentication ?
* Using "masterkey" (only option)

User            : tartarefr
Device          : masterkey

Save to /etc/pamusb.conf ?
[Y/n]

On modifie les fichiers /etc/pam.d/system-auth et /etc/pam.d/system-auth-ac pour ajouter la ligne autorisant l’authentification par le module pam-usb avant celle de l’authentification unix (ligne existante qui ne doit pas être modifiée)

Fichiers /etc/pam.d/system-auth et /etc/pam.d/system-auth-ac
auth        sufficient    pam_usb.so
auth        sufficient    pam_unix.so ....

On vérifie

pamusb-check tartarefr
* Authentication request for user "tartarefr" (pamusb-check)
* Device "masterkey" is connected (good).
* Performing one time pad verification...
* Access granted
sudo cat /etc/fedora-release
* pam_usb v0.5.0
* Authentication request for user "didier" (sudo)
* Device "masterkey" is connected (good).
* Performing one time pad verification...
* Access granted.
Fedora release 28 (Twenty Eight)

Au secours, ça ne fonctionne plus
Il suffit de supprimer le répertoire local comportant le secret partagé (en se connectant avec le mot de passe unix). Le secret partagé sera réinitialisé avec la commande pamusb-check.

rm -rf ~/.pamusb
pamusb-check $USER

Relayer ses courriels via gmail

Afin de s’affranchir du relais SMTP de son F.A.I. on peut utiliser son compte google (gmail) pour envoyer les courriels avec son serveur de courrier postfix. C’est bon pour la planète car cela supprime les intermédiaires entre son courrier et les services de renseignements peu scrupuleux de notre vie privée. En parlant de ça, quelqu’un a déjà réussi à faire une restauration à partir de la solution NSACloudBackup ?

Il suffit de modifier un tout petit peu la configuration de postfix (qui a été le service mail par défaut de fedora et qui est toujours celui de centos).

On édite le fichier, afin de rajouter ou de modifier les entrées suivantes:

Fichier /etc/postfix/main.cf
relayhost = [smtp.gmail.com]:587

# use tls
smtp_use_tls=yes

# use sasl when authenticating to foreign SMTP servers
smtp_sasl_auth_enable = yes

# path to password map file
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

# list of CAs to trust when verifying server certificate
smtp_tls_CAfile = /etc/ssl/certs/ca-bundle.trust.crt

# eliminates default security options which are imcompatible with gmail
smtp_sasl_security_options = noanonymous
smtp_sasl_mechanism_filter = plain

On génère le fichier fichier contenant les identifiants.

Fichier /etc/postfix/sasl_passwd
[smtp.gmail.com]:587  <email gmail>:<motdepasse>

On transforme ce fichier dans un langage compréhensible par postfix (fichiers indexés) et on supprime la version en clair

sudo postmap /etc/postfix/sasl_passwd
sudo rm /etc/postfix/sasl_passwd

On redémarre le service postfix et le tour est joué.

sudo systemctl restart postfix

Google considère que la seule méthode d’autentification sécurisée est OAuth2, et que SASL ne l’est pas. Il faudra donc autoriser les connexions “moins sécurisée” à son compte Google sur la page https://www.google.com/settings/security/lesssecureapps.

On teste la bonne réception d’un courriel envoyé avec la commande suivante:

echo 'Test from CLI' | mail -s 'gmail relay' <mon adresse email>