La honte m'étouffe. J'ai commis l'erreur de changer au même moment mon
mot de passe root et mon mot de passe utilisateur, et je n'arrive
plus à retrouver le premier :`-(
Pour m'en tirer, j'ai réussi à booter sur une vieille disquette
rescue, j'ai accordé les droits en écriture à tous sur le fichier
/etc/shadow, puis j'ai relancé mon système et édité ce fichier pour
enlever le mot de passe crypté entre les ":", mais cela ne marche pas
! Quand je fais un su suivi d'un retour chariot comme mot de passe,
l'erreur suivante se produit :
su: Authentication service cannot retrieve authentication info.
Pourquoi ais-je une telle erreur ? Comment faire pour supprimer ce mot
de passe root ?
Merci de vos réponses éclairées,
--
Laurent Hugé (pour m'écrire, enlever nospam de l'adresse de réponse)
GPG fingerprint = B5E2 AB11 C37C E3C6 C6C0 0EEC ECF7 F96B E937 B34B
Dans l'article news:401bf16e$0$32650$, Laurent Hugé écrivait :
Bon, ben j'y suis arrivé tout de même. Pour répondre à la question de TiChou, il se trouve que même vi n'était pas présent sur mes disquettes rescue
Même pas pico, nano ou joe ? Une disquette rescue sans le moindre éditeur textet n'est plus une disquette rescue pourmoi. :)
Enfin, ce ne fût pas sans peine ; je me suis retrouvé dans la situation désagréable où personne ne pouvait plus se logger (je pense que cela venait des dates d'expiration des mots de passe dans /etc/shadow).
Un mot de passe qui expire n'empèche pas de se logger mais force l'utilisateur à changer son mot de passe avant d'avoir le prompt.
Par contre, malgré un vide complet après "root:" dans /etc/passwd et /etc/shadow, impossible de se connecter en root !
Quand vous parlez vide complet après "root:", vous voulez dire vraiment plus rien après "root:" ou bien rien entre le premier séparateur ":" et le deuxième ? Dans le premier cas alors oui c'est normal puisque le reste de la ligne donne les caractéristiques du compte en particulier le shell qui sera lancé aprèys la phase de login. Dans le deuxième cas ce n'est pas normal. A moins que pam interfère et empeche de se logger avec des mots de passes vides.
-- TiChou
Dans l'article news:401bf16e$0$32650$626a54ce@news.free.fr,
Laurent Hugé <hugenospam.root@freenospam.fr> écrivait :
Bon, ben j'y suis arrivé tout de même.
Pour répondre à la question de TiChou, il se trouve que même vi
n'était pas présent sur mes disquettes rescue
Même pas pico, nano ou joe ? Une disquette rescue sans le moindre éditeur
textet n'est plus une disquette rescue pourmoi. :)
Enfin, ce ne fût pas sans peine ; je me suis retrouvé dans la
situation désagréable où personne ne pouvait plus se logger (je pense
que cela venait des dates d'expiration des mots de passe dans
/etc/shadow).
Un mot de passe qui expire n'empèche pas de se logger mais force
l'utilisateur à changer son mot de passe avant d'avoir le prompt.
Par contre, malgré un vide complet après "root:" dans
/etc/passwd et /etc/shadow, impossible de se connecter en root !
Quand vous parlez vide complet après "root:", vous voulez dire vraiment plus
rien après "root:" ou bien rien entre le premier séparateur ":" et le
deuxième ?
Dans le premier cas alors oui c'est normal puisque le reste de la ligne
donne les caractéristiques du compte en particulier le shell qui sera lancé
aprèys la phase de login.
Dans le deuxième cas ce n'est pas normal. A moins que pam interfère et
empeche de se logger avec des mots de passes vides.
Dans l'article news:401bf16e$0$32650$, Laurent Hugé écrivait :
Bon, ben j'y suis arrivé tout de même. Pour répondre à la question de TiChou, il se trouve que même vi n'était pas présent sur mes disquettes rescue
Même pas pico, nano ou joe ? Une disquette rescue sans le moindre éditeur textet n'est plus une disquette rescue pourmoi. :)
Enfin, ce ne fût pas sans peine ; je me suis retrouvé dans la situation désagréable où personne ne pouvait plus se logger (je pense que cela venait des dates d'expiration des mots de passe dans /etc/shadow).
Un mot de passe qui expire n'empèche pas de se logger mais force l'utilisateur à changer son mot de passe avant d'avoir le prompt.
Par contre, malgré un vide complet après "root:" dans /etc/passwd et /etc/shadow, impossible de se connecter en root !
Quand vous parlez vide complet après "root:", vous voulez dire vraiment plus rien après "root:" ou bien rien entre le premier séparateur ":" et le deuxième ? Dans le premier cas alors oui c'est normal puisque le reste de la ligne donne les caractéristiques du compte en particulier le shell qui sera lancé aprèys la phase de login. Dans le deuxième cas ce n'est pas normal. A moins que pam interfère et empeche de se logger avec des mots de passes vides.
-- TiChou
Laurent Hugé
Bon, ben j'y suis arrivé tout de même. Pour répondre à la question de TiChou, il se trouve que même vi n'était pas présent sur mes disquettes rescue
Même pas pico, nano ou joe ? Une disquette rescue sans le moindre éditeur textet n'est plus une disquette rescue pourmoi. :) A vrai dire, c'était plutôt de la récupération de mes premières
installations de linux. Le vrai nom, c'était "disquette racine", je crois ; et le seul éditeur présent ici, c'est sed :-( J'ai eu plus tard l'idée d'utiliser le CD-ROM de Fedora Core qu'un ami a oublié chez moi, et qui fourni un système complet (qui se paye même le luxe de scanner les disques durs et de monter (en lecture seule si l'utilisateur le demande) les paritions linux)). A savoir.
Enfin, ce ne fût pas sans peine ; je me suis retrouvé dans la situation désagréable où personne ne pouvait plus se logger (je pense que cela venait des dates d'expiration des mots de passe dans /etc/shadow).
Un mot de passe qui expire n'empèche pas de se logger mais force l'utilisateur à changer son mot de passe avant d'avoir le prompt. Ah bon ! Pourtant il me semble que ce cas m'est déjà arrivé, et j'ai
été obligé de me logger en root pour changer le mot de passe expiré (j'ai un doute quand même parce qu'il me semble n'avoir essayé que sous kdm, et pas en mode console, mais bon, ça m'étonne quand même de n'avoir pas ressayé avant de me logger root (en mode console forcément !))
Par contre, malgré un vide complet après "root:" dans /etc/passwd et /etc/shadow, impossible de se connecter en root !
Quand vous parlez vide complet après "root:", vous voulez dire vraiment plus rien après "root:" ou bien rien entre le premier séparateur ":" et le deuxième ? Oui, c'est bien entre le premier ":" et le second (ça aurait été hier,
j'aurai presque trouvé la question insultante, mais aujourd'hui, après avoir oublié le mot de passe root, je crois que je mérite les flammes de l'enfer sans tergiverser ;-)
Dans le deuxième cas ce n'est pas normal. A moins que pam interfère et empeche de se logger avec des mots de passes vides. C'est bien ce qui semble s'être passé, le seul moyen de contournement
étant l'init 1 (pam est-il actif en mde single user ?) -- Laurent Hugé (pour m'écrire, enlever nospam de l'adresse de réponse) GPG fingerprint = B5E2 AB11 C37C E3C6 C6C0 0EEC ECF7 F96B E937 B34B
Bon, ben j'y suis arrivé tout de même.
Pour répondre à la question de TiChou, il se trouve que même vi
n'était pas présent sur mes disquettes rescue
Même pas pico, nano ou joe ? Une disquette rescue sans le moindre
éditeur textet n'est plus une disquette rescue pourmoi. :)
A vrai dire, c'était plutôt de la récupération de mes premières
installations de linux. Le vrai nom, c'était "disquette racine", je
crois ; et le seul éditeur présent ici, c'est sed :-(
J'ai eu plus tard l'idée d'utiliser le CD-ROM de Fedora Core qu'un ami
a oublié chez moi, et qui fourni un système complet (qui se paye même
le luxe de scanner les disques durs et de monter (en lecture seule si
l'utilisateur le demande) les paritions linux)). A savoir.
Enfin, ce ne fût pas sans peine ; je me suis retrouvé dans la
situation désagréable où personne ne pouvait plus se logger (je
pense que cela venait des dates d'expiration des mots de passe dans
/etc/shadow).
Un mot de passe qui expire n'empèche pas de se logger mais force
l'utilisateur à changer son mot de passe avant d'avoir le prompt.
Ah bon ! Pourtant il me semble que ce cas m'est déjà arrivé, et j'ai
été obligé de me logger en root pour changer le mot de passe expiré
(j'ai un doute quand même parce qu'il me semble n'avoir essayé que
sous kdm, et pas en mode console, mais bon, ça m'étonne quand même de
n'avoir pas ressayé avant de me logger root (en mode console
forcément !))
Par contre, malgré un vide complet après "root:" dans
/etc/passwd et /etc/shadow, impossible de se connecter en root !
Quand vous parlez vide complet après "root:", vous voulez dire
vraiment plus rien après "root:" ou bien rien entre le premier
séparateur ":" et le deuxième ?
Oui, c'est bien entre le premier ":" et le second (ça aurait été hier,
j'aurai presque trouvé la question insultante, mais aujourd'hui,
après avoir oublié le mot de passe root, je crois que je mérite les
flammes de l'enfer sans tergiverser ;-)
Dans le deuxième cas ce n'est pas normal. A moins que pam interfère
et empeche de se logger avec des mots de passes vides.
C'est bien ce qui semble s'être passé, le seul moyen de contournement
étant l'init 1 (pam est-il actif en mde single user ?)
--
Laurent Hugé (pour m'écrire, enlever nospam de l'adresse de réponse)
GPG fingerprint = B5E2 AB11 C37C E3C6 C6C0 0EEC ECF7 F96B E937 B34B
Bon, ben j'y suis arrivé tout de même. Pour répondre à la question de TiChou, il se trouve que même vi n'était pas présent sur mes disquettes rescue
Même pas pico, nano ou joe ? Une disquette rescue sans le moindre éditeur textet n'est plus une disquette rescue pourmoi. :) A vrai dire, c'était plutôt de la récupération de mes premières
installations de linux. Le vrai nom, c'était "disquette racine", je crois ; et le seul éditeur présent ici, c'est sed :-( J'ai eu plus tard l'idée d'utiliser le CD-ROM de Fedora Core qu'un ami a oublié chez moi, et qui fourni un système complet (qui se paye même le luxe de scanner les disques durs et de monter (en lecture seule si l'utilisateur le demande) les paritions linux)). A savoir.
Enfin, ce ne fût pas sans peine ; je me suis retrouvé dans la situation désagréable où personne ne pouvait plus se logger (je pense que cela venait des dates d'expiration des mots de passe dans /etc/shadow).
Un mot de passe qui expire n'empèche pas de se logger mais force l'utilisateur à changer son mot de passe avant d'avoir le prompt. Ah bon ! Pourtant il me semble que ce cas m'est déjà arrivé, et j'ai
été obligé de me logger en root pour changer le mot de passe expiré (j'ai un doute quand même parce qu'il me semble n'avoir essayé que sous kdm, et pas en mode console, mais bon, ça m'étonne quand même de n'avoir pas ressayé avant de me logger root (en mode console forcément !))
Par contre, malgré un vide complet après "root:" dans /etc/passwd et /etc/shadow, impossible de se connecter en root !
Quand vous parlez vide complet après "root:", vous voulez dire vraiment plus rien après "root:" ou bien rien entre le premier séparateur ":" et le deuxième ? Oui, c'est bien entre le premier ":" et le second (ça aurait été hier,
j'aurai presque trouvé la question insultante, mais aujourd'hui, après avoir oublié le mot de passe root, je crois que je mérite les flammes de l'enfer sans tergiverser ;-)
Dans le deuxième cas ce n'est pas normal. A moins que pam interfère et empeche de se logger avec des mots de passes vides. C'est bien ce qui semble s'être passé, le seul moyen de contournement
étant l'init 1 (pam est-il actif en mde single user ?) -- Laurent Hugé (pour m'écrire, enlever nospam de l'adresse de réponse) GPG fingerprint = B5E2 AB11 C37C E3C6 C6C0 0EEC ECF7 F96B E937 B34B
TiChou
Dans l'article news:401bff25$0$32629$, Laurent Hugé écrivait :
Enfin, ce ne fût pas sans peine ; je me suis retrouvé dans la situation désagréable où personne ne pouvait plus se logger (je pense que cela venait des dates d'expiration des mots de passe dans /etc/shadow).
Un mot de passe qui expire n'empèche pas de se logger mais force l'utilisateur à changer son mot de passe avant d'avoir le prompt.
Ah bon ! Pourtant il me semble que ce cas m'est déjà arrivé, et j'ai été obligé de me logger en root pour changer le mot de passe expiré
Vous avez probablement raison. J'ai parlé un peu trop vite en fait. En fait il y a deux dates pour l'expiration des mots de passes. Celle qui impose de changer son mot de passe après une date précise et la deuxième qui vient après et qui désactive le compte si on n'a pas modifié son mot de passe à temps.
Dans le deuxième cas ce n'est pas normal. A moins que pam interfère et empeche de se logger avec des mots de passes vides.
C'est bien ce qui semble s'être passé, le seul moyen de contournement étant l'init 1 (pam est-il actif en mde single user ?)
Oui.
-- TiChou
Dans l'article news:401bff25$0$32629$626a54ce@news.free.fr,
Laurent Hugé <hugenospam.root@freenospam.fr> écrivait :
Enfin, ce ne fût pas sans peine ; je me suis retrouvé dans la
situation désagréable où personne ne pouvait plus se logger (je
pense que cela venait des dates d'expiration des mots de passe dans
/etc/shadow).
Un mot de passe qui expire n'empèche pas de se logger mais force
l'utilisateur à changer son mot de passe avant d'avoir le prompt.
Ah bon ! Pourtant il me semble que ce cas m'est déjà arrivé, et j'ai
été obligé de me logger en root pour changer le mot de passe expiré
Vous avez probablement raison. J'ai parlé un peu trop vite en fait.
En fait il y a deux dates pour l'expiration des mots de passes.
Celle qui impose de changer son mot de passe après une date précise et la
deuxième qui vient après et qui désactive le compte si on n'a pas modifié
son mot de passe à temps.
Dans le deuxième cas ce n'est pas normal. A moins que pam interfère
et empeche de se logger avec des mots de passes vides.
C'est bien ce qui semble s'être passé, le seul moyen de contournement
étant l'init 1 (pam est-il actif en mde single user ?)
Dans l'article news:401bff25$0$32629$, Laurent Hugé écrivait :
Enfin, ce ne fût pas sans peine ; je me suis retrouvé dans la situation désagréable où personne ne pouvait plus se logger (je pense que cela venait des dates d'expiration des mots de passe dans /etc/shadow).
Un mot de passe qui expire n'empèche pas de se logger mais force l'utilisateur à changer son mot de passe avant d'avoir le prompt.
Ah bon ! Pourtant il me semble que ce cas m'est déjà arrivé, et j'ai été obligé de me logger en root pour changer le mot de passe expiré
Vous avez probablement raison. J'ai parlé un peu trop vite en fait. En fait il y a deux dates pour l'expiration des mots de passes. Celle qui impose de changer son mot de passe après une date précise et la deuxième qui vient après et qui désactive le compte si on n'a pas modifié son mot de passe à temps.
Dans le deuxième cas ce n'est pas normal. A moins que pam interfère et empeche de se logger avec des mots de passes vides.
C'est bien ce qui semble s'être passé, le seul moyen de contournement étant l'init 1 (pam est-il actif en mde single user ?)
Oui.
-- TiChou
Thomas Nemeth
Le sam 31 jan 2004 à 19:17, TiChou a tapoté : | Dans l'article news:, | Kevin DENIS écrivait : | | >> Je ne crois pas que Qing Liu parlait du mot de passe de Lilo mais | >> plutôt du fait qu'en démarrant en mode single user on passe quand | >> même par une phase de login pour accéder à la console. | >> | > linux 1 et linux init=/bin/bash | > ce n'est pas la meme chose. | | Vous n'avez pas du bien suivre le thread alors. :) | Nous parlions pas de init mais du level sous lequel était lancé Linux.
Sauf que c'est init qui s'occupe des runlevels :)
| Je recite Qing Liu : | | >>>> Alors linux S. Problème: c'est parfois protéger par un mot | ^ | >>>> de passe quand même. | | > Generalement linux 1 te demande le mot de passe root | | Oui, c'est ce que je disais. | | > et te demande plusieurs machins | | Quoi donc ? Je n'ai pas eu souvent l'occasion de passer en mode single user | mais de souvenir à part la phase de login, je n'ai rien eu d'autre à saisir.
Hum. Je pense que Kevin devait parler de divers trucs lancés en rl1, les rares machins qu'il y a dans /etc/rc[S1].d dans une debian ;)
| > (et d'ailleurs linux 1 a besoin d'init), | | Oui.
Car 1 est un runlevel géré par init.
| > mais linux init=/bin/bash ne te demande rien, | | Oui. Mais faut-il que le système démarre sur cet init, ce qui ne fonctionne | pas toujours comme je le disais au départ.
Si tu as /bin/bash, linux _remplace_ init par /bin/bash avec la commande lilo qui t'es donnée ici... Donc plus de gestion des rl, mais un simple shell root. Si tu remplaces init (c'est un programme, hein :) par bash, alors quelle que soit ta distro, tous les services habituellement lancés par les scripts de boot ne seront pas exécutés car init n'ayant pas été lancé, il n'aura pas pu les lancer à son tour.
Si init=/bin/bash ne fonctionne pas chez toi c'est certainement que exether[~] ldd /bin/bash libncurses.so.5 => /lib/libncurses.so.5 (0x4001a000) libdl.so.2 => /lib/libdl.so.2 (0x40059000) libc.so.6 => /lib/libc.so.6 (0x4005d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
tu n'as pas /lib sur la même partition que /bin ;) Du moins dans le cas d'une vieille debian potato.
Thomas -- JCP : Oui, j'ai cru remarquer que les gens n'étaient pas très ...détendus... sur fr.usenet.forums.evolution FB : Normal. Il faut être tendu pour violenter ces pauvres mouches. -+- in: Guide du Cabaliste Usenet - Les enfilades sous tension -+-
Le sam 31 jan 2004 à 19:17, TiChou a tapoté :
| Dans l'article news:slrnc1nqoj.cof.Kevin@slackware.local.tux,
| Kevin DENIS <Kevin@nowhere.invalid> écrivait :
|
| >> Je ne crois pas que Qing Liu parlait du mot de passe de Lilo mais
| >> plutôt du fait qu'en démarrant en mode single user on passe quand
| >> même par une phase de login pour accéder à la console.
| >>
| > linux 1 et linux init=/bin/bash
| > ce n'est pas la meme chose.
|
| Vous n'avez pas du bien suivre le thread alors. :)
| Nous parlions pas de init mais du level sous lequel était lancé Linux.
Sauf que c'est init qui s'occupe des runlevels :)
| Je recite Qing Liu :
|
| >>>> Alors linux S. Problème: c'est parfois protéger par un mot
| ^
| >>>> de passe quand même.
|
| > Generalement linux 1 te demande le mot de passe root
|
| Oui, c'est ce que je disais.
|
| > et te demande plusieurs machins
|
| Quoi donc ? Je n'ai pas eu souvent l'occasion de passer en mode single user
| mais de souvenir à part la phase de login, je n'ai rien eu d'autre à saisir.
Hum. Je pense que Kevin devait parler de divers trucs lancés en rl1,
les rares machins qu'il y a dans /etc/rc[S1].d dans une debian ;)
| > (et d'ailleurs linux 1 a besoin d'init),
|
| Oui.
Car 1 est un runlevel géré par init.
| > mais linux init=/bin/bash ne te demande rien,
|
| Oui. Mais faut-il que le système démarre sur cet init, ce qui ne fonctionne
| pas toujours comme je le disais au départ.
Si tu as /bin/bash, linux _remplace_ init par /bin/bash avec la
commande lilo qui t'es donnée ici... Donc plus de gestion des rl,
mais un simple shell root. Si tu remplaces init (c'est un programme,
hein :) par bash, alors quelle que soit ta distro, tous les services
habituellement lancés par les scripts de boot ne seront pas exécutés
car init n'ayant pas été lancé, il n'aura pas pu les lancer à son
tour.
Si init=/bin/bash ne fonctionne pas chez toi c'est certainement que
exether[~] ldd /bin/bash
libncurses.so.5 => /lib/libncurses.so.5 (0x4001a000)
libdl.so.2 => /lib/libdl.so.2 (0x40059000)
libc.so.6 => /lib/libc.so.6 (0x4005d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
tu n'as pas /lib sur la même partition que /bin ;)
Du moins dans le cas d'une vieille debian potato.
Thomas
--
JCP : Oui, j'ai cru remarquer que les gens n'étaient pas très
...détendus... sur fr.usenet.forums.evolution
FB : Normal. Il faut être tendu pour violenter ces pauvres mouches.
-+- in: Guide du Cabaliste Usenet - Les enfilades sous tension -+-
Le sam 31 jan 2004 à 19:17, TiChou a tapoté : | Dans l'article news:, | Kevin DENIS écrivait : | | >> Je ne crois pas que Qing Liu parlait du mot de passe de Lilo mais | >> plutôt du fait qu'en démarrant en mode single user on passe quand | >> même par une phase de login pour accéder à la console. | >> | > linux 1 et linux init=/bin/bash | > ce n'est pas la meme chose. | | Vous n'avez pas du bien suivre le thread alors. :) | Nous parlions pas de init mais du level sous lequel était lancé Linux.
Sauf que c'est init qui s'occupe des runlevels :)
| Je recite Qing Liu : | | >>>> Alors linux S. Problème: c'est parfois protéger par un mot | ^ | >>>> de passe quand même. | | > Generalement linux 1 te demande le mot de passe root | | Oui, c'est ce que je disais. | | > et te demande plusieurs machins | | Quoi donc ? Je n'ai pas eu souvent l'occasion de passer en mode single user | mais de souvenir à part la phase de login, je n'ai rien eu d'autre à saisir.
Hum. Je pense que Kevin devait parler de divers trucs lancés en rl1, les rares machins qu'il y a dans /etc/rc[S1].d dans une debian ;)
| > (et d'ailleurs linux 1 a besoin d'init), | | Oui.
Car 1 est un runlevel géré par init.
| > mais linux init=/bin/bash ne te demande rien, | | Oui. Mais faut-il que le système démarre sur cet init, ce qui ne fonctionne | pas toujours comme je le disais au départ.
Si tu as /bin/bash, linux _remplace_ init par /bin/bash avec la commande lilo qui t'es donnée ici... Donc plus de gestion des rl, mais un simple shell root. Si tu remplaces init (c'est un programme, hein :) par bash, alors quelle que soit ta distro, tous les services habituellement lancés par les scripts de boot ne seront pas exécutés car init n'ayant pas été lancé, il n'aura pas pu les lancer à son tour.
Si init=/bin/bash ne fonctionne pas chez toi c'est certainement que exether[~] ldd /bin/bash libncurses.so.5 => /lib/libncurses.so.5 (0x4001a000) libdl.so.2 => /lib/libdl.so.2 (0x40059000) libc.so.6 => /lib/libc.so.6 (0x4005d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
tu n'as pas /lib sur la même partition que /bin ;) Du moins dans le cas d'une vieille debian potato.
Thomas -- JCP : Oui, j'ai cru remarquer que les gens n'étaient pas très ...détendus... sur fr.usenet.forums.evolution FB : Normal. Il faut être tendu pour violenter ces pauvres mouches. -+- in: Guide du Cabaliste Usenet - Les enfilades sous tension -+-
Jolitorax
Jerome Lambert nous narrait
Ou que le prompt n'est pas toujours possible. Dans les mdk, on choisit les entrées dans la liste avec les curseurs, un point c'est tout...
Avec Grub ? essaye un "e" sur la ligne selectionnée
-- Jean Louis Mas
Jerome Lambert nous narrait
Ou que le prompt n'est pas toujours possible.
Dans les mdk, on choisit les entrées dans la liste avec les curseurs, un
point c'est tout...
Avec Grub ?
essaye un "e" sur la ligne selectionnée
