Vue d’ensemble
L’intégration d’un interpréteur de commandes alternatif ou l’affectation d’un script personnalisé comme environnement de connexion requiert la maîtrise de l’utilitaire add-shell. Ce tutoriel détaille le rôle fondamental du fichier /etc/shells, son interaction directe avec la commande chsh, ainsi que les bonnes pratiques d’administration pour associer, auditer et désinscrire un shell en toute sécurité à l’aide de remove-shell.
1. Rôle du fichier /etc/shells et inventaire des interpréteurs autorisés
Pour inspecter la liste blanche des interpréteurs de commandes validés sur la machine, on examine le contenu du fichier de référence en lançant cat /etc/shells.
Seuls les binaires explicitement déclarés dans /etc/shells peuvent être sélectionnés par les utilisateurs lors d’une modification de shell via chsh. Ce mécanisme constitue un rempart de sécurité indispensable, particulièrement sollicité lors des phases d’authentification par divers démons système (tels que les serveurs FTP ou SSH).
Afin de situer précisément l’emplacement des exécutables par défaut de l’environnement, on utilise la commande which bash sh.
Cette vérification permet de corroborer la présence effective des chemins /usr/bin/bash et /usr/bin/sh au sein du fichier /etc/shells, garantissant ainsi leur conformité opérationnelle.
2. Déploiement d’un nouveau shell (Zsh) et intégration via add-shell
Dans le cadre de cette démonstration, procédons à l’installation du paquet zsh afin de disposer d’un nouvel interpréteur à intégrer à la configuration globale.
L’interrogation de l’emplacement absolu du binaire fraîchement installé s’effectue via which zsh.
Dans le contexte de cette capture, l’absence de retour indique que le fichier exécutable n’a pas été localisé immédiatement dans le chemin de recherche courant ou que le déploiement a rencontré une anomalie.
L’utilitaire sudo add-shell $(which zsh) est conçu pour inscrire automatiquement le chemin complet résolu dans /etc/shells.
Cependant, la variable n’ayant renvoyé aucun chemin valide lors de l’étape précédente, la commande est invoquée sans paramètre, provoquant ainsi l’affichage du guide de syntaxe standard add-shell shellname.
Pour contrôler la présence effective de l’interpréteur dans la liste officielle, on applique le filtre de recherche grep -E 'zsh$' /etc/shells.
L’absence de résultat confirme que l’entrée correspondant à zsh n’a pas encore été inscrite dans /etc/shells.
3. Conception d’un script d’environnement restreint et déclaration dans le système
Afin d’encadrer l’accès de certains profils utilisateurs au sein d’une session dédiée, créons un script de menu restreint déposé sous /usr/local/bin/custom-menu.sh.
Pour rendre ce script directement exécutable par le sous-système d’authentification, on lui assigne les permissions adéquates au moyen de sudo chmod +x /usr/local/bin/custom-menu.sh.
Afin d’élever ce script sur mesure au rang d’interpréteur de connexion légitime pour le système, on exécute sudo add-shell /usr/local/bin/custom-menu.sh, ce qui insère automatiquement son chemin dans /etc/shells.
Une vérification des dernières entrées de la configuration s’opère en lançant tail -n 3 /etc/shells.
La sortie confirme que /usr/local/bin/custom-menu.sh figure désormais en queue de liste, attestant de son homologation parmi les shells valides de l’hôte.
4. Validation avec un compte utilisateur et nettoyage sécurisé avec remove-shell
Pour valider le fonctionnement en conditions réelles, provisionnons un compte de test nommé testuser configuré d’emblée avec notre menu sur mesure via la directive sudo id -u testuser >/dev/null 2>&1 || sudo useradd -m -s /usr/local/bin/custom-menu.sh testuser.
L’attribution correcte du shell au compte s’authentifie par une consultation de la base locale via grep '^testuser:' /etc/passwd.
L’enregistrement retourné valide que le compte testuser pointe explicitement vers /usr/local/bin/custom-menu.sh comme interpréteur de démarrage.
La phase de test étant achevée, supprimons l’utilisateur temporaire ainsi que son répertoire personnel en exécutant sudo userdel -r testuser 2>/dev/null || true.
Afin de révoquer l’autorisation accordée au script sans risquer de corrompre le fichier de configuration, on utilise la commande symétrique sudo remove-shell /usr/local/bin/custom-menu.sh, qui expurge proprement la ligne dans /etc/shells.
Le binaire n’ayant plus d’utilité, l’effacement définitif du fichier sur le disque est réalisé par sudo rm -f /usr/local/bin/custom-menu.sh.
L’audit final de désinscription s’effectue avec l’instruction conditionnelle grep 'custom-menu.sh' /etc/shells || echo '등록 해제 완료'.
La chaîne n’étant plus trouvée dans le fichier, le message de confirmation s’affiche en console, attestant du retrait complet et sans résidu de l’interpréteur.
Vous disposez désormais d’une méthode rigoureuse pour déclarer un nouvel interpréteur dans /etc/shells via add-shell et le relier aux outils d’administration comme chsh. Privilégier ces utilitaires dédiés plutôt qu’une édition manuelle directe garantit l’intégrité et la stabilité de votre système Linux au quotidien.