Comment verrouiller un compte temporairement

Problématique somme toute simple, comment désactiver temporairemennt un compte sur un système *nix sans pour autant le supprimer, ni altérer son mot de passe. Pas si simple en réalité...

Verrouillage du compte

Alors il y a le moyen classique de verrouillage du compte utilisateur. Pour cela,en tant que root, on utilise la commande passwd

root#passwd vilain -l

passwd : expiration du mot de passe modifiée.

verrouillage d'un compte

A partir de là, l’utilisateur vilain ne peut plus se saisir son mot de passe. Mais le problème n'est pas pour autant réglé lorsque ce dernier a configuré son compte pour s'y connecter sans mot de passe, via une clef ssh. La solution n'est donc pas 100% efficace. On va donc dévérouiller le compte et tenter autre chose.

root#passwd vilain -u

passwd : expiration du mot de passe modifiée.

déverrouillage d'un compte

Altération de /etc/passwd

Une autre solution aussi radicale que bestiale consiste simplement à altérer le nom d'utilisateur dans le fichier /etc/passwd. Par exemple en rajoutant un # devant

#vilain:x:1006:1006:Vilain,,,:/home/vilain:/bin/bash

extrait de /etc/passwd

Là, avec ou sans clef ssh, l'utilisateur ne peut plus se connecter. Les malins vont se dire, qu'il suffit de la savoir, et de se connecter du coup en tant que '#vilain', mais ça ne fonctionnera pas car 1/ il va y avoir un désynchronisation entre /etc/passwd et /etc/shadow, et 2/ le dossier /home/vilain contenant la clef ssh ne serait de toute façon plus retrouvé par le système.

Alors cela fleure un peu la grosse bidouille, voyons si nous pouvons trouver plus propre...

Envoyer l'utilisateur dans l'espace

Une autre manière de régler le problème, sans doute plus élégante, consiste à désactiver le shell de l'utilisateur. En effet, si nous regardons à nouveau sa ligne /etc/passwd, nous y voyons un gentil /bin/bash. Si nous modifions cette ligne à nouveau pour retirer le # et cette fois remplacer /bin/bash par /bin/false, nous utilisateur va certes pouvoir se connecter, mais sa connexion sera directement fermée.

vilain:x:1006:1006:Vilain,,,:/home/vilain:/bin/false

extrait de /etc/passwd

Le malin se dira que via ssh, il est possible de lancer un shell. Et bien que l'on se rassure, cela ne fonctionne pas. Le système refusera catégoriquement le lancement de la commande non pas à cause de /bin/false en soit, mais simplement parce que /bin/false n'est pas une commande autorisé en tant que shell dans le fichier /etc/shells.

Conclusion

En somme, plusieurs méthode possible, mais une seule semble permettre de bloquer totalement l'utilisateur temporairement indésirable (si c'était définitif il suffirait de détruire le compte ;-).

A noter cependant que si cette technique permet de désactiver l'accès à une machine à un compte donné, elle ne bloque pas l'usage de ce compte pour des applications. Par exemple si vous utilisez PAM pour authentifier les comptes apache, cela continuera à fonctionner. C'est donc aussi une bonne pratique pour créer des comptes mails, apache, etc qui n'ont aucune raison de se connecter via ssh sur la machine.