Je souhaiterais connaître la bonne façon de « désactiver » un
compte Unix. En fait, j'ignore si le terme est correct (merci de
me rectifier le cas échéant) mais je précise ma pensée ci-dessous.
Ce que j'entends par là, c'est que je souhaite qu'il soit impossible
de se connecter au système avec le compte en question, appelons-le
"toto". Par exemple, toute connexion ssh au compte "toto" devra être
impossible. Idem pour une connexion sur tty[1-6] (et via le display
manager si il y en a un). En fait, je voudrais qu'aucun être humain
ne puisse se connecter au système en étant "toto" directement, je
souhaiterais que seul root puisse devenir "toto" via la commande "su",
c'est tout.
Je précise que je suis sur une Debian, Wheezy en l'occurrence (mais
j'imagine que ma question ne dépend pas trop de la distribution).
Actuellement, j'utilise cette commande pour arriver à mes fins :
passwd -d toto
ce qui rend le mot de passe de "toto" vide, ce qui semble avoir
l'effet que je recherche sur ma Wheezy.
1. Pourquoi ? À vrai dire, j'en sais trop rien et je serais curieux
d'avoir une explication sur ce point (je soupçonne une histoire avec
PAM mais je ne suis pas sûr).
2. Enfin, est-ce la bonne façon de faire ? Y a-t-il une façon plus
propre ?
3. Et attribuer au compte "toto" le shell /bin/false, est-ce mieux ?
Est-ce équivalent ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas George
Francois Lafont , dans le message <55bd53b7$0$3392$, a écrit :
passwd -d toto
ce qui rend le mot de passe de "toto" vide, ce qui semble avoir l'effet que je recherche sur ma Wheezy.
1. Pourquoi ? À vrai dire, j'en sais trop rien et je serais curieux d'avoir une explication sur ce point (je soupçonne une histoire avec PAM mais je ne suis pas sûr).
C'est bien PAM qui fait les choses.
Normalement, rendre le mot de passe vide a l'effet exactement inverse de ce que tu veux : le compte est accessible sans aucun mot de passe.
Heureusement, les mainteneurs se sont rendus compte que pour les services exposés au réseau, c'est vachement dangereux, donc maintenant PAM fait une exception pour les mots de passe vides, et c'est contrôlé par l'option nullok.
2. Enfin, est-ce la bonne façon de faire ?
Non.
Y a-t-il une façon plus propre ?
passwd -l va remplacer le mot de passe chiffré par une valeur impossible, ce qui refuse tout mot de passe. C'est la version propre de ce que tu fais.
Mais ça n'empêche pas l'utilisateur de se connecter avec sa clef SSH, ses crontabs de tourner, etc.
usermod -e 1 marque que le compte a expiré, et PAM refusera toute connexion.
3. Et attribuer au compte "toto" le shell /bin/false, est-ce mieux ? Est-ce équivalent ?
Ça devrait être à peu près équivalent, à part si tu suis les conseils des idiots qui disent de mettre /bin/false dans /etc/shells.
Francois Lafont , dans le message
<55bd53b7$0$3392$426a74cc@news.free.fr>, a écrit :
passwd -d toto
ce qui rend le mot de passe de "toto" vide, ce qui semble avoir
l'effet que je recherche sur ma Wheezy.
1. Pourquoi ? À vrai dire, j'en sais trop rien et je serais curieux
d'avoir une explication sur ce point (je soupçonne une histoire avec
PAM mais je ne suis pas sûr).
C'est bien PAM qui fait les choses.
Normalement, rendre le mot de passe vide a l'effet exactement inverse de ce
que tu veux : le compte est accessible sans aucun mot de passe.
Heureusement, les mainteneurs se sont rendus compte que pour les services
exposés au réseau, c'est vachement dangereux, donc maintenant PAM fait une
exception pour les mots de passe vides, et c'est contrôlé par l'option
nullok.
2. Enfin, est-ce la bonne façon de faire ?
Non.
Y a-t-il une façon plus
propre ?
passwd -l va remplacer le mot de passe chiffré par une valeur impossible, ce
qui refuse tout mot de passe. C'est la version propre de ce que tu fais.
Mais ça n'empêche pas l'utilisateur de se connecter avec sa clef SSH, ses
crontabs de tourner, etc.
usermod -e 1 marque que le compte a expiré, et PAM refusera toute connexion.
3. Et attribuer au compte "toto" le shell /bin/false, est-ce mieux ?
Est-ce équivalent ?
Ça devrait être à peu près équivalent, à part si tu suis les conseils des
idiots qui disent de mettre /bin/false dans /etc/shells.
Francois Lafont , dans le message <55bd53b7$0$3392$, a écrit :
passwd -d toto
ce qui rend le mot de passe de "toto" vide, ce qui semble avoir l'effet que je recherche sur ma Wheezy.
1. Pourquoi ? À vrai dire, j'en sais trop rien et je serais curieux d'avoir une explication sur ce point (je soupçonne une histoire avec PAM mais je ne suis pas sûr).
C'est bien PAM qui fait les choses.
Normalement, rendre le mot de passe vide a l'effet exactement inverse de ce que tu veux : le compte est accessible sans aucun mot de passe.
Heureusement, les mainteneurs se sont rendus compte que pour les services exposés au réseau, c'est vachement dangereux, donc maintenant PAM fait une exception pour les mots de passe vides, et c'est contrôlé par l'option nullok.
2. Enfin, est-ce la bonne façon de faire ?
Non.
Y a-t-il une façon plus propre ?
passwd -l va remplacer le mot de passe chiffré par une valeur impossible, ce qui refuse tout mot de passe. C'est la version propre de ce que tu fais.
Mais ça n'empêche pas l'utilisateur de se connecter avec sa clef SSH, ses crontabs de tourner, etc.
usermod -e 1 marque que le compte a expiré, et PAM refusera toute connexion.
3. Et attribuer au compte "toto" le shell /bin/false, est-ce mieux ? Est-ce équivalent ?
Ça devrait être à peu près équivalent, à part si tu suis les conseils des idiots qui disent de mettre /bin/false dans /etc/shells.
Erwan David
Nicolas George <nicolas$ écrivait :
usermod -e 1 marque que le compte a expiré, et PAM refusera toute connexion.
<mode Nicpolas Georges> Non. </mode>
Plus d'explication : ne fonctionne que pour des comptes locaux avec /etc/shadow.
Ne fonctionnera pas en ldap, NIS, etc...
-- Les simplifications c'est trop compliqué
Nicolas George <nicolas$george@salle-s.org> écrivait :
usermod -e 1 marque que le compte a expiré, et PAM refusera toute connexion.
<mode Nicpolas Georges>
Non.
</mode>
Plus d'explication : ne fonctionne que pour des comptes locaux avec
/etc/shadow.
usermod -e 1 marque que le compte a expiré, et PAM refusera toute connexion.
<mode Nicpolas Georges> Non. </mode>
Plus d'explication : ne fonctionne que pour des comptes locaux avec /etc/shadow.
Ne fonctionnera pas en ldap, NIS, etc...
-- Les simplifications c'est trop compliqué
Francois Lafont
Bonjour,
On 02/08/2015 10:30, Nicolas George wrote:
ce qui rend le mot de passe de "toto" vide, ce qui semble avoir l'effet que je recherche sur ma Wheezy.
1. Pourquoi ? À vrai dire, j'en sais trop rien et je serais curieux d'avoir une explication sur ce point (je soupçonne une histoire avec PAM mais je ne suis pas sûr).
C'est bien PAM qui fait les choses.
Normalement, rendre le mot de passe vide a l'effet exactement inverse de ce que tu veux : le compte est accessible sans aucun mot de passe.
Heureusement, les mainteneurs se sont rendus compte que pour les services exposés au réseau, c'est vachement dangereux, donc maintenant PAM fait une exception pour les mots de passe vides, et c'est contrôlé par l'option nullok.
Ok, c'était bien un truc comme ça dont je ne me rappelais plus trop. En revanche l'option nullok du module pam_unix semble faire en sorte justement qu'un mot de passe vide soit accepté, comme le suggère le nom de l'option et la page man, non ?
nullok The default action of this module is to not permit the user access to a service if their official password is blank. The nullok argument overrides this default and allows any user with a blank password to access the service.
Ceci étant sur ma Wheezy c'est l'option nullok_secure qui semble être utilisée mais j'avoue que j'ai pas trop pigé la subtile différence avec nullok. Bref, l'une comme l'autre de ces options semblent aller dans le sens de « j'autorise les mots de passe vide », non ?
2. Enfin, est-ce la bonne façon de faire ?
Non.
Ok. En effet, la commande que tu proposes ci-dessous semble bien plus convenable.
Y a-t-il une façon plus propre ?
passwd -l va remplacer le mot de passe chiffré par une valeur impossible, ce qui refuse tout mot de passe. C'est la version propre de ce que tu fais.
Mais ça n'empêche pas l'utilisateur de se connecter avec sa clef SSH, ses crontabs de tourner, etc.
Ok, ça c'est parfait. Avec l'idée en plus qu'on garde le mot de passe intact et qu'à tout moment on peut délocker avec l'option -u et retrouver le mot de passe de départ.
usermod -e 1 marque que le compte a expiré, et PAM refusera toute connexion.
Ok, je ne connaissais pas. J'ai pu constater qu'avec cette commande en effet plus grand chose ne marche avec le compte (connexions ssh, tâches cron etc). Par contre il semble que root soit toujours en mesure de se connecter avec le compte :
~# su - toto Your account has expired; please contact your system administrator su: Authentication failure (Ignored) ~$
On voit apparaître un message d'erreur mais on obtient bien le prompt au final. Ceci étant, ça ne me choque pas plus que ça car sur Linux root a tous les droits et-puis-c'est-tout.
3. Et attribuer au compte "toto" le shell /bin/false, est-ce mieux ? Est-ce équivalent ?
Ça devrait être à peu près équivalent,
Sauf erreur, ça me semble même peut-être un chouilla plus restrictif que la commande « passwd -l toto » car avec /bin/fasle comme shell de login même une connexion ssh via une clé sera impossible alors qu'avec « passwd -l toto » ça reste encore possible. Je me trompe ?
Sinon, ça semble globalement équivalent...
à part si tu suis les conseils des idiots qui disent de mettre /bin/false dans /etc/shells.
Alors j'avoue que le fichier /etc/shells, je viens de le découvrir. Je ne connais pas sa signification mais lorsque je vois en commentaire dans ce fichier « valid login shells », je me dis que jamais j'aurais suivi un conseil comme celui-là (ie mettre /bin/false dans ce fichier).
Merci pour ton aide Nicolas. Comme souvent j'ai des petites interrogations sur certains points ici ou là mais mon problème n'en est pas moins résolu. ;)
-- François Lafont
Bonjour,
On 02/08/2015 10:30, Nicolas George wrote:
ce qui rend le mot de passe de "toto" vide, ce qui semble avoir
l'effet que je recherche sur ma Wheezy.
1. Pourquoi ? À vrai dire, j'en sais trop rien et je serais curieux
d'avoir une explication sur ce point (je soupçonne une histoire avec
PAM mais je ne suis pas sûr).
C'est bien PAM qui fait les choses.
Normalement, rendre le mot de passe vide a l'effet exactement inverse de ce
que tu veux : le compte est accessible sans aucun mot de passe.
Heureusement, les mainteneurs se sont rendus compte que pour les services
exposés au réseau, c'est vachement dangereux, donc maintenant PAM fait une
exception pour les mots de passe vides, et c'est contrôlé par l'option
nullok.
Ok, c'était bien un truc comme ça dont je ne me rappelais plus trop.
En revanche l'option nullok du module pam_unix semble faire en sorte
justement qu'un mot de passe vide soit accepté, comme le suggère le
nom de l'option et la page man, non ?
nullok
The default action of this module is to not permit the user
access to a service if their official password is blank. The
nullok argument overrides this default and allows any user
with a blank password to access the service.
Ceci étant sur ma Wheezy c'est l'option nullok_secure qui semble être
utilisée mais j'avoue que j'ai pas trop pigé la subtile différence avec
nullok. Bref, l'une comme l'autre de ces options semblent aller dans le
sens de « j'autorise les mots de passe vide », non ?
2. Enfin, est-ce la bonne façon de faire ?
Non.
Ok. En effet, la commande que tu proposes ci-dessous semble bien plus
convenable.
Y a-t-il une façon plus
propre ?
passwd -l va remplacer le mot de passe chiffré par une valeur impossible, ce
qui refuse tout mot de passe. C'est la version propre de ce que tu fais.
Mais ça n'empêche pas l'utilisateur de se connecter avec sa clef SSH, ses
crontabs de tourner, etc.
Ok, ça c'est parfait. Avec l'idée en plus qu'on garde le mot de passe intact
et qu'à tout moment on peut délocker avec l'option -u et retrouver le mot
de passe de départ.
usermod -e 1 marque que le compte a expiré, et PAM refusera toute connexion.
Ok, je ne connaissais pas. J'ai pu constater qu'avec cette commande en
effet plus grand chose ne marche avec le compte (connexions ssh, tâches
cron etc). Par contre il semble que root soit toujours en mesure de se
connecter avec le compte :
~# su - toto
Your account has expired; please contact your system administrator
su: Authentication failure
(Ignored)
~$
On voit apparaître un message d'erreur mais on obtient bien le prompt au
final. Ceci étant, ça ne me choque pas plus que ça car sur Linux root a
tous les droits et-puis-c'est-tout.
3. Et attribuer au compte "toto" le shell /bin/false, est-ce mieux ?
Est-ce équivalent ?
Ça devrait être à peu près équivalent,
Sauf erreur, ça me semble même peut-être un chouilla plus restrictif que
la commande « passwd -l toto » car avec /bin/fasle comme shell de login
même une connexion ssh via une clé sera impossible alors qu'avec
« passwd -l toto » ça reste encore possible. Je me trompe ?
Sinon, ça semble globalement équivalent...
à part si tu suis les conseils des
idiots qui disent de mettre /bin/false dans /etc/shells.
Alors j'avoue que le fichier /etc/shells, je viens de le découvrir.
Je ne connais pas sa signification mais lorsque je vois en commentaire
dans ce fichier « valid login shells », je me dis que jamais j'aurais
suivi un conseil comme celui-là (ie mettre /bin/false dans ce fichier).
Merci pour ton aide Nicolas. Comme souvent j'ai des petites interrogations
sur certains points ici ou là mais mon problème n'en est pas moins résolu. ;)
ce qui rend le mot de passe de "toto" vide, ce qui semble avoir l'effet que je recherche sur ma Wheezy.
1. Pourquoi ? À vrai dire, j'en sais trop rien et je serais curieux d'avoir une explication sur ce point (je soupçonne une histoire avec PAM mais je ne suis pas sûr).
C'est bien PAM qui fait les choses.
Normalement, rendre le mot de passe vide a l'effet exactement inverse de ce que tu veux : le compte est accessible sans aucun mot de passe.
Heureusement, les mainteneurs se sont rendus compte que pour les services exposés au réseau, c'est vachement dangereux, donc maintenant PAM fait une exception pour les mots de passe vides, et c'est contrôlé par l'option nullok.
Ok, c'était bien un truc comme ça dont je ne me rappelais plus trop. En revanche l'option nullok du module pam_unix semble faire en sorte justement qu'un mot de passe vide soit accepté, comme le suggère le nom de l'option et la page man, non ?
nullok The default action of this module is to not permit the user access to a service if their official password is blank. The nullok argument overrides this default and allows any user with a blank password to access the service.
Ceci étant sur ma Wheezy c'est l'option nullok_secure qui semble être utilisée mais j'avoue que j'ai pas trop pigé la subtile différence avec nullok. Bref, l'une comme l'autre de ces options semblent aller dans le sens de « j'autorise les mots de passe vide », non ?
2. Enfin, est-ce la bonne façon de faire ?
Non.
Ok. En effet, la commande que tu proposes ci-dessous semble bien plus convenable.
Y a-t-il une façon plus propre ?
passwd -l va remplacer le mot de passe chiffré par une valeur impossible, ce qui refuse tout mot de passe. C'est la version propre de ce que tu fais.
Mais ça n'empêche pas l'utilisateur de se connecter avec sa clef SSH, ses crontabs de tourner, etc.
Ok, ça c'est parfait. Avec l'idée en plus qu'on garde le mot de passe intact et qu'à tout moment on peut délocker avec l'option -u et retrouver le mot de passe de départ.
usermod -e 1 marque que le compte a expiré, et PAM refusera toute connexion.
Ok, je ne connaissais pas. J'ai pu constater qu'avec cette commande en effet plus grand chose ne marche avec le compte (connexions ssh, tâches cron etc). Par contre il semble que root soit toujours en mesure de se connecter avec le compte :
~# su - toto Your account has expired; please contact your system administrator su: Authentication failure (Ignored) ~$
On voit apparaître un message d'erreur mais on obtient bien le prompt au final. Ceci étant, ça ne me choque pas plus que ça car sur Linux root a tous les droits et-puis-c'est-tout.
3. Et attribuer au compte "toto" le shell /bin/false, est-ce mieux ? Est-ce équivalent ?
Ça devrait être à peu près équivalent,
Sauf erreur, ça me semble même peut-être un chouilla plus restrictif que la commande « passwd -l toto » car avec /bin/fasle comme shell de login même une connexion ssh via une clé sera impossible alors qu'avec « passwd -l toto » ça reste encore possible. Je me trompe ?
Sinon, ça semble globalement équivalent...
à part si tu suis les conseils des idiots qui disent de mettre /bin/false dans /etc/shells.
Alors j'avoue que le fichier /etc/shells, je viens de le découvrir. Je ne connais pas sa signification mais lorsque je vois en commentaire dans ce fichier « valid login shells », je me dis que jamais j'aurais suivi un conseil comme celui-là (ie mettre /bin/false dans ce fichier).
Merci pour ton aide Nicolas. Comme souvent j'ai des petites interrogations sur certains points ici ou là mais mon problème n'en est pas moins résolu. ;)
-- François Lafont
Nicolas George
Francois Lafont , dans le message <55bf10a1$0$3355$, a écrit :
Ceci étant sur ma Wheezy c'est l'option nullok_secure qui semble être utilisée mais j'avoue que j'ai pas trop pigé la subtile différence avec nullok. Bref, l'une comme l'autre de ces options semblent aller dans le sens de « j'autorise les mots de passe vide », non ?
Oui, les deux autorisent les connexions sans mot de passe ou autre authentification sur les comptes sans mot de passe.
La différence c'est que nullok_secure ne l'accepte que pour des connexions qui proviennent d'un périphérique réputé sûr, et donc en particulier pas du réseau. Mais l'utilisateur pourra toujours se loguer en console, typiquement.
On voit apparaître un message d'erreur mais on obtient bien le prompt au final. Ceci étant, ça ne me choque pas plus que ça car sur Linux root a tous les droits et-puis-c'est-tout.
Exactement.
Alors j'avoue que le fichier /etc/shells, je viens de le découvrir. Je ne connais pas sa signification mais lorsque je vois en commentaire dans ce fichier « valid login shells », je me dis que jamais j'aurais suivi un conseil comme celui-là (ie mettre /bin/false dans ce fichier).
/etc/shells liste les _vrais_ shells, qui sont censés permettre de faire n'importe quoi. Si le shell d'un utilisateur est listé dans /etc/shells, alors certains outils (typiquement, su) acceptent d'utiliser un autre shell si l'utilisateur demande. Cf. su(1) et l'option -s.
Francois Lafont , dans le message
<55bf10a1$0$3355$426a74cc@news.free.fr>, a écrit :
Ceci étant sur ma Wheezy c'est l'option nullok_secure qui semble être
utilisée mais j'avoue que j'ai pas trop pigé la subtile différence avec
nullok. Bref, l'une comme l'autre de ces options semblent aller dans le
sens de « j'autorise les mots de passe vide », non ?
Oui, les deux autorisent les connexions sans mot de passe ou autre
authentification sur les comptes sans mot de passe.
La différence c'est que nullok_secure ne l'accepte que pour des connexions
qui proviennent d'un périphérique réputé sûr, et donc en particulier pas du
réseau. Mais l'utilisateur pourra toujours se loguer en console,
typiquement.
On voit apparaître un message d'erreur mais on obtient bien le prompt au
final. Ceci étant, ça ne me choque pas plus que ça car sur Linux root a
tous les droits et-puis-c'est-tout.
Exactement.
Alors j'avoue que le fichier /etc/shells, je viens de le découvrir.
Je ne connais pas sa signification mais lorsque je vois en commentaire
dans ce fichier « valid login shells », je me dis que jamais j'aurais
suivi un conseil comme celui-là (ie mettre /bin/false dans ce fichier).
/etc/shells liste les _vrais_ shells, qui sont censés permettre de faire
n'importe quoi. Si le shell d'un utilisateur est listé dans /etc/shells,
alors certains outils (typiquement, su) acceptent d'utiliser un autre shell
si l'utilisateur demande. Cf. su(1) et l'option -s.
Francois Lafont , dans le message <55bf10a1$0$3355$, a écrit :
Ceci étant sur ma Wheezy c'est l'option nullok_secure qui semble être utilisée mais j'avoue que j'ai pas trop pigé la subtile différence avec nullok. Bref, l'une comme l'autre de ces options semblent aller dans le sens de « j'autorise les mots de passe vide », non ?
Oui, les deux autorisent les connexions sans mot de passe ou autre authentification sur les comptes sans mot de passe.
La différence c'est que nullok_secure ne l'accepte que pour des connexions qui proviennent d'un périphérique réputé sûr, et donc en particulier pas du réseau. Mais l'utilisateur pourra toujours se loguer en console, typiquement.
On voit apparaître un message d'erreur mais on obtient bien le prompt au final. Ceci étant, ça ne me choque pas plus que ça car sur Linux root a tous les droits et-puis-c'est-tout.
Exactement.
Alors j'avoue que le fichier /etc/shells, je viens de le découvrir. Je ne connais pas sa signification mais lorsque je vois en commentaire dans ce fichier « valid login shells », je me dis que jamais j'aurais suivi un conseil comme celui-là (ie mettre /bin/false dans ce fichier).
/etc/shells liste les _vrais_ shells, qui sont censés permettre de faire n'importe quoi. Si le shell d'un utilisateur est listé dans /etc/shells, alors certains outils (typiquement, su) acceptent d'utiliser un autre shell si l'utilisateur demande. Cf. su(1) et l'option -s.
Francois Lafont
On 03/08/2015 10:07, Nicolas George wrote:
Ceci étant sur ma Wheezy c'est l'option nullok_secure qui semble être utilisée mais j'avoue que j'ai pas trop pigé la subtile différence avec nullok. Bref, l'une comme l'autre de ces options semblent aller dans le sens de « j'autorise les mots de passe vide », non ?
Oui, les deux autorisent les connexions sans mot de passe ou autre authentification sur les comptes sans mot de passe.
La différence c'est que nullok_secure ne l'accepte que pour des connexions qui proviennent d'un périphérique réputé sûr, et donc en particulier pas du réseau. Mais l'utilisateur pourra toujours se loguer en console, typiquement.
Ah ok. Effectivement, je n'avais jamais testé auparavant mais une connexion sur tty1 avec un mot de passe vide fonctionne bien. Au passage, je pensais qu'il fallait que j'indique quand même un mot de passe -- la chaîne de caractères vide "" -- mais en fait non. Si j'ai bien compris, mettre un mot de passe vide signifie en fait « pas de demande de mot de passe du tout ».
On voit apparaître un message d'erreur mais on obtient bien le prompt au final. Ceci étant, ça ne me choque pas plus que ça car sur Linux root a tous les droits et-puis-c'est-tout.
Exactement.
Alors j'avoue que le fichier /etc/shells, je viens de le découvrir. Je ne connais pas sa signification mais lorsque je vois en commentaire dans ce fichier « valid login shells », je me dis que jamais j'aurais suivi un conseil comme celui-là (ie mettre /bin/false dans ce fichier).
/etc/shells liste les _vrais_ shells, qui sont censés permettre de faire n'importe quoi. Si le shell d'un utilisateur est listé dans /etc/shells, alors certains outils (typiquement, su) acceptent d'utiliser un autre shell si l'utilisateur demande. Cf. su(1) et l'option -s.
Ok, maintenant je comprends mieux pourquoi ce n'est pas une bonne idée de mettre /bin/false dans /etc/shells : si un compte toto possède /bin/false comme shell de login, potentiellement le compte titi pourrait se connecter en tant que toto avec le shell /bin/bash via su (enfin à condition tout de même qu'il connaisse le mot de passe de toto).
Merci beaucoup pour toutes ces explications. À+
-- François Lafont
On 03/08/2015 10:07, Nicolas George wrote:
Ceci étant sur ma Wheezy c'est l'option nullok_secure qui semble être
utilisée mais j'avoue que j'ai pas trop pigé la subtile différence avec
nullok. Bref, l'une comme l'autre de ces options semblent aller dans le
sens de « j'autorise les mots de passe vide », non ?
Oui, les deux autorisent les connexions sans mot de passe ou autre
authentification sur les comptes sans mot de passe.
La différence c'est que nullok_secure ne l'accepte que pour des connexions
qui proviennent d'un périphérique réputé sûr, et donc en particulier pas du
réseau. Mais l'utilisateur pourra toujours se loguer en console,
typiquement.
Ah ok. Effectivement, je n'avais jamais testé auparavant mais une connexion
sur tty1 avec un mot de passe vide fonctionne bien. Au passage, je pensais
qu'il fallait que j'indique quand même un mot de passe -- la chaîne de
caractères vide "" -- mais en fait non. Si j'ai bien compris, mettre un mot
de passe vide signifie en fait « pas de demande de mot de passe du tout ».
On voit apparaître un message d'erreur mais on obtient bien le prompt au
final. Ceci étant, ça ne me choque pas plus que ça car sur Linux root a
tous les droits et-puis-c'est-tout.
Exactement.
Alors j'avoue que le fichier /etc/shells, je viens de le découvrir.
Je ne connais pas sa signification mais lorsque je vois en commentaire
dans ce fichier « valid login shells », je me dis que jamais j'aurais
suivi un conseil comme celui-là (ie mettre /bin/false dans ce fichier).
/etc/shells liste les _vrais_ shells, qui sont censés permettre de faire
n'importe quoi. Si le shell d'un utilisateur est listé dans /etc/shells,
alors certains outils (typiquement, su) acceptent d'utiliser un autre shell
si l'utilisateur demande. Cf. su(1) et l'option -s.
Ok, maintenant je comprends mieux pourquoi ce n'est pas une bonne idée de
mettre /bin/false dans /etc/shells : si un compte toto possède /bin/false
comme shell de login, potentiellement le compte titi pourrait se connecter
en tant que toto avec le shell /bin/bash via su (enfin à condition tout de
même qu'il connaisse le mot de passe de toto).
Ceci étant sur ma Wheezy c'est l'option nullok_secure qui semble être utilisée mais j'avoue que j'ai pas trop pigé la subtile différence avec nullok. Bref, l'une comme l'autre de ces options semblent aller dans le sens de « j'autorise les mots de passe vide », non ?
Oui, les deux autorisent les connexions sans mot de passe ou autre authentification sur les comptes sans mot de passe.
La différence c'est que nullok_secure ne l'accepte que pour des connexions qui proviennent d'un périphérique réputé sûr, et donc en particulier pas du réseau. Mais l'utilisateur pourra toujours se loguer en console, typiquement.
Ah ok. Effectivement, je n'avais jamais testé auparavant mais une connexion sur tty1 avec un mot de passe vide fonctionne bien. Au passage, je pensais qu'il fallait que j'indique quand même un mot de passe -- la chaîne de caractères vide "" -- mais en fait non. Si j'ai bien compris, mettre un mot de passe vide signifie en fait « pas de demande de mot de passe du tout ».
On voit apparaître un message d'erreur mais on obtient bien le prompt au final. Ceci étant, ça ne me choque pas plus que ça car sur Linux root a tous les droits et-puis-c'est-tout.
Exactement.
Alors j'avoue que le fichier /etc/shells, je viens de le découvrir. Je ne connais pas sa signification mais lorsque je vois en commentaire dans ce fichier « valid login shells », je me dis que jamais j'aurais suivi un conseil comme celui-là (ie mettre /bin/false dans ce fichier).
/etc/shells liste les _vrais_ shells, qui sont censés permettre de faire n'importe quoi. Si le shell d'un utilisateur est listé dans /etc/shells, alors certains outils (typiquement, su) acceptent d'utiliser un autre shell si l'utilisateur demande. Cf. su(1) et l'option -s.
Ok, maintenant je comprends mieux pourquoi ce n'est pas une bonne idée de mettre /bin/false dans /etc/shells : si un compte toto possède /bin/false comme shell de login, potentiellement le compte titi pourrait se connecter en tant que toto avec le shell /bin/bash via su (enfin à condition tout de même qu'il connaisse le mot de passe de toto).
