slack@localhost:~$ su -
Mot de passe :
su: Échec d'authentification
Et je suis sur que mon mot de passe est le bon.
Ca me l’a déjà fait une fois et par chance j’avais un terminal d’ouvert en root, alors j’ai fait un passwd et j’ai changé mon mot de passe, mais là ça me l’a refait une deuxième fois et je n’ai plus de terminal root d’ouvert…
edit: J’ai tenté la procédure de récupération de mot de passe en ajoutant init=/bin/bash
derrière /boot/vmlinuz
, puis faire un mount -n -o remount, rw /
puis passwd
et ça a fonctionné, j’ai pu changer de mot de passe root, mais dès que j’ai réouvert une session Gnome, mon mot de passe root n’a plus fonctionné.
Je ne sais plus quoi faire, j’ai essayé tout ce que j’ai pu trouver sur le net mais rien y fait.
La seule solution est d’accéder à la partition contenant /etc à partir d’un autre système, soit pré-installé sur un support externe, soit à installer/installé sur une partition interne*.
*Une bonne pratique est de toujours avoir au mois 2 systèmes présents sur un PC, c’est utile dans un tel cas, pratique pour un upgrade, pour des tests de distributions différentes, …
Je pensais à ça aussi. @xddj : vérifie que ton clavier a bien le même “layout” lorsque tu es en “récupération”, tty et graphique. À chaque fois, teste ton clavier, tapes ton mot de passe à l’invite de commande juste pour voir si tout les caractères sont les bons. (Oui c’est crade comme approche mais je n’ai jamais réussi à m’en sortir avec les configurations clavier au niveau noyau, tty, xorg, gnome)
Pourquoi ? C’est ça la vraie question… J’arrive bien à le changer le mot de passe root, je viens encore d’essayer, j’ai mis que des chiffres pour être sur qu’il n’y ait pas de problème avec le qwerty, mais non, dès que je reviens sur Gnome ça ne fonctionne plus.
Moi je crois que je me suis fait hacker, mais quelque chose de bien.
edit: Je vais quand même retester une fois en vérifiant que les chiffres ne sont pas impactés par le qwerty, mais ça m’étonnerais fort.
Moi je vous le dis, il y a un hacker qui joue avec mes nerfs.
Alors je vous explique, j’ai retenté une récupération et les chiffres ne fonctionnait pas ! Il fallait appuyer deux fois sur verrouillage num pour que ça fonctionne !
Donc tout content je me reconnecte à ma session Gnome, je vérifie direct que les chiffres fonctionnent AVANT de taper mon mot de passe et là ça me redis “su: Échec d’authentification”
Je me dis “tiens, je vais essayer une deuxième fois” une forme d’acharnement je ne sais pas, et là ça marche !
Vous ne trouvez pas ça étrange vous ?
Moi je suis sur qu’un hacker joue avec moi.
Peut-être que ton.profile , .bash_profile , /etc/profile ou .bashrc contient une erreur.
Si c’est le cas, utilise ctr-alt-F1 pour entrer dans le shell. Utilise la commande su - root pour entrer une session racine, puis utilisez nano ou vi pour modifier le fichier qui est endommagé.
Bonjour
J’ai eu le même problème mais avec sudo.
J’étais sur d’avoir tapé et retapé le bon password. Rien à faire pas moyen de passer en root.
Et j’ai essayé su et bingo, je suis passé en root.
Essayez.
Bah tout les hacker sont plus ou moins sadiques =)
Je vais tenter de vérifier les fichiers dont tu me parles, mais je ne sais pas trop quoi chercher…
edit:
Tout d’abord, le .profile
# ~/.profile: executed by Bourne-compatible login shells.
if [ "$BASH" ]; then
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
fi
mesg n || true
Puis le .bash_profile est vide…
Maintenant le /etc/profile:
# /etc/profile: system-wide .profile file for the Bourne shell (sh(1))
# and Bourne compatible shells (bash(1), ksh(1), ash(1), ...).
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
export PATH
if [ "${PS1-}" ]; then
if [ "${BASH-}" ] && [ "$BASH" != "/bin/sh" ]; then
# The file bash.bashrc already sets the default PS1.
# PS1='\h:\w\$ '
if [ -f /etc/bash.bashrc ]; then
. /etc/bash.bashrc
fi
else
if [ "`id -u`" -eq 0 ]; then
PS1='# '
else
PS1='$ '
fi
fi
fi
if [ -d /etc/profile.d ]; then
for i in /etc/profile.d/*.sh; do
if [ -r $i ]; then
. $i
fi
done
unset i
fi
Et enfin le .bashrc:
# ~/.bashrc: executed by bash(1) for non-login shells.
# Note: PS1 and umask are already set in /etc/profile. You should not
# need this unless you want different defaults for root.
# PS1='${debian_chroot:+($debian_chroot)}\h:\w\$ '
# umask 022
# You may uncomment the following lines if you want `ls' to be colorized:
# export LS_OPTIONS='--color=auto'
# eval "`dircolors`"
# alias ls='ls $LS_OPTIONS'
# alias ll='ls $LS_OPTIONS -l'
# alias l='ls $LS_OPTIONS -lA'
#
# Some more alias to avoid making mistakes:
# alias rm='rm -i'
# alias cp='cp -i'
# alias mv='mv -i'
Ne fais rien, c’est tout-à-fait normal puisque tu utilises Debian testing et non pas stable.
Je t’ai déjà expliqué ça dans un autre sujet (Nvidia), d’autant plus qu’on ouvre jamais, je répète, jamais une session X avec un certain user très particulier qui s’appellerait “root”.
Pour aller chercher dans des fichiers “.bash*” de user pourquoi le compte “root” est refusé en session X, il te manque de sérieuses bases quand-même.
Il me semblait t’avoir conseillé d’être sudoers (j’en suis même sûr).
Mon avis est que testing n’est pas fait pour toi, ou si tu veux du testing, et bien teste et apprends.
Maintenant, dans un terminal, lorsque tu tapes su , un mot de passe devrait t’être demandé.
=> accepté ou refusé ?
Arrête avec ton “hacker”…
1 - tu utilises une Debian TESTING, sans visiblement maîtriser certaines bases;
2 - tu utilises en permanence des consoles en mode “root”, et essaie même de rentrer en session X en “root”… (no more comment);
3- j’ai vu ton sujet Realtek, mais préféré m’abstenir d’intervenir;
4 - j’utilise le module Realtek r8169 de Debian depuis des années que ce soit en Stable/Testing/SID sans aucun problème, … à condition de ne pas blacklister le module et de ne pas aller chercher des modules n’importe où, c’est-à-dire commencer à tripatouiller.
5 - si d’un coup sans rien faire (on va supposer), ton réseau tombe en panne, la première chose à faire est de vérifier l’état matériel avec un autre OS (double boot ou session live).
En conclusion, ton sujet " [Je ne peux plus me connecter en root]" est résolu, puisque tu peux te connecter en root, tout-à-fait conformément à l’utilisation de Debian testing, ce que tu as oublié de préciser dans le sujet.
Je suis sur qu’il s’agit d’un kacker. La preuve ma carte réseau ethernet n’a plus fonctionné au même moment. Je ne suis pas débile quand même, je sais un minimum ce que je fais.
Je ne suis pas débile quand même, mon mot de passe root ne s’est pas changé tout seul comme par magie. Si je vous dis qu’il y a un hacker c’est qu’il y en a un.
Surtout que ces derniers jours j’ai vu le curseur de ma sourie bouger tout seul à plusieurs reprises ! Là aussi je suis débile ! J’ai halluciné c’est ça !
Si je vous dis qu’il y a un hacker c’est qu’il y en a un, je suis pas débile !
edit: Seconde preuve, ma carte réseau qui ne fonctionnait plus s’est remise à fonctionner avec le pilote officiel Realtek, que j’avais déjà teste et c’était un échec total. Ca fait quand même beaucoup le même jour !
Je sais pas où tu as vu que j’ai ouvert une session X en root mais tu as halluciné mec. Tout ce que j’ai fait (par erreur) sur le sujet Nvidia c’est ouvrir une applie graphique en root, parce que j’avais oublié que j’étais en root (de toute façon ça n’a pas fonctionné).
Je n’ai pas commencé à tripatouiller comme tu dis, la première chose que j’ai faite a été de changer de câble réseau, puis tester sur un autre port de la box, puis en dernière position blacklister le module pour installer le pilote officiel (ce qui n’a pas fonctionné) Et comme par miracle je retente le coup une fois le problème du mot de passe réglé et là ça fonctionne ! J’ai quand même essayé avec trois pilotes différents ! Le link était toujours down.
