Brak haseł w systemie - polecenie passwd nie działa

KeFaS - 17-03-2009 03:20
Witam.

System: Debian Squeeze, kernel 2.6.26-1-686, GNOME 2.22.3

Mam bardzo dziwny problem, który pojawił się po ostatniej aktualizacji (przez kilka dni nie robiłem, więc ok. 70 pakietów się zaktualizowało). Mianowicie zniknęły mi hasła dla użytkownika i roota. Nie wiem jak, samemu na pewno ich nie usuwałem, ani nikt inny, bo tylko ja mam dostęp do komputera. Chodzi o to, że włączam dzisiaj komputer (wczoraj po aktualizacjach od razu wyłączyłem), loguje się w gdm i... no właśnie loguje się bez hasła. Odpalam gnome-terminal, wpisuję su... i loguje się na roota bez hasła. Wrzucam passwd, żeby ustalić nowa hasło, a ten od razu mi wyrzuca: kefas@PC-Linux:~$ su
PC-Linux:/home/kefas#
PC-Linux:/home/kefas# passwd root
passwd: hasło zostało zmienione
PC-Linux:/home/kefas# passwd kefas
passwd: hasło zostało zmienione
PC-Linux:/home/kefas# exit
exit
kefas@PC-Linux:~$
kefas@PC-Linux:~$ passwd
passwd: hasło zostało zmienione
kefas@PC-Linux:~$ Czyli nie mogę nawet ustalić hasła. W konsoli bez X'ów jest to samo. Najdziwniejsze, że w pliku /etc/shadow są hasła zaszyfrowane. Mimo to system mnie o nie nie pyta przy logowaniu. Co do użytkownika to jeszcze pół biedy, ale root bez hasła? Myślałem, że to niemożliwe do zrobienia.
Przychodzi mi do głowy tylko jeden pomysł. Ręczne wpisanie zakodowanego hasła do /etc/shadow. Ale właśnie nie wiem jak je "zakodować"? Nie znam algorytmu szyfrowania tych haseł, a od tego przecież jest program passwd, który u mnie przestał działać.
Proszę o pomoc.

Pozdrawiam.

P.S: Aha, przy ostatniej aktualizacji nie było nowej wersji programu passwd.

RaV. - 17-03-2009 17:31

Przychodzi mi do głowy tylko jeden pomysł. Ręczne wpisanie zakodowanego hasła do /etc/shadow. Ale właśnie nie wiem jak je "zakodować"? man 1ssl passwd

W skrócie:
openssl passwd -1 Wygląda mi to raczej nie na problem z programem passwd a z instytucją o nazwie PAM. Zobacz, czy w ostatnich aktualizacjach nie pociągnąłeś jakichś modułów do PAMa.
Wrzuć wynik polecenia
grep -vE "(^#|^$)" /etc/pam.d/common-password oraz może jeszcze:
grep -vE "(^#|^$)" /etc/pam.d/common-auth Może te listingi rozjaśnią trochę sytuację. Przyjrzyj się także logom zawartym w pliku: /var/log/auth.log
grep pam /var/log/auth.log

KeFaS - 18-03-2009 04:15
Dzięki za odpowiedź.

Na początek wyniki podanych przez Ciebie komend:

PC-Linux:/home/kefas# grep -vE "(^#|^$)" /etc/pam.d/common-password
password [default=1] pam_permit.so
password requisite pam_deny.so
password required pam_permit.so PC-Linux:/home/kefas# grep -vE "(^#|^$)" /etc/pam.d/common-auth
auth [default=1] pam_permit.so
auth requisite pam_deny.so
auth required pam_permit.so PC-Linux:/home/kefas# grep pam /var/log/auth.log
Mar 15 06:25:52 PC-Linux CRON[6211]: pam_unix(cron:session): session closed for user root
Mar 15 06:47:01 PC-Linux CRON[6469]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 15 06:47:03 PC-Linux CRON[6469]: pam_unix(cron:session): session closed for user root
Mar 15 06:49:44 PC-Linux su[6521]: pam_unix(su:session): session opened for user root by kefas(uid=1000)
Mar 15 06:52:36 PC-Linux su[6521]: pam_unix(su:session): session closed for user root
Mar 15 07:44:49 PC-Linux gdm[2308]: pam_unix(gdm:session): session closed for user kefas
Mar 15 22:48:18 PC-Linux gdm[2311]: gkr-pam: no password is available for user
Mar 16 06:54:36 PC-Linux gdm[5746]: pam_nologin(gdm:auth): cannot determine username
Mar 16 06:57:21 PC-Linux gdm[2304]: gkr-pam: no password is available for user
Mar 16 06:57:47 PC-Linux gdm[2304]: pam_nologin(gdm:auth): cannot determine username
Mar 16 06:57:47 PC-Linux gdm[2304]: gkr-pam: no password is available for user
Mar 16 23:11:11 PC-Linux gdm[2303]: gkr-pam: no password is available for user
Mar 17 23:00:31 PC-Linux gdm[2307]: gkr-pam: no password is available for user Ten ostatni log mnie najbardziej dziwi, dlaczego jest "nie można określić nazwy użytkownika" i "hasło niedostępne dla użytkownika" ?
A jak te pozostałe? Jest napisane, że password/auth są "wymagane", czyli wygląda OK... chyba?

Jeszcze zaraz spróbuje wygenerować nowe hasła za pomocą openssl i ręcznie dodam je do pliku /etc/shadow i zobaczę czy dalej będę się logować bez haseł.

Edit:

Niestety i to nie pomogło. :-( Wygenerowałem nowe hasła za pomocą openssl passwd -1 Dodałem je ręcznie do /etc/shadow, zrestartowałem komputer, ale dalej loguje się na użytkownika i roota bez hasła. Nowe zaszyfrowane hasła są cały czas w pliku shadow (nic ich nie usunęło), mimo to ciągle jest ten sam problem.

tomii - 18-03-2009 08:21
Spróbuj utworzyć nowego użytkownika i pokaż plik passwd.

RaV. - 18-03-2009 08:59
Hola, hola...
Czegoś mi brakuje w /etc/pam.d/common-auth (i nie tylko).
Spróbuj dorzucić na początku: auth [success=1 default=ignore] pam_unix.so nullok_secure Ważne, by było przed linią
auth [default=1] pam_permit.so Moduł pam_unix.so odpowiada właśnie za Unixową autentykację użytkowników. Skoro jego zabrakło a jest tylko pam_permit, ZAWSZE użytkownik dostanie dostęp do maszyny.

A może zróbmy to od razu hurtem. Pododawaj poniższe linie do odpowiednich plików na początku, przed innymi modułami (jeśli nie ma w pliku linii z pam_unix.so): /etc/pam.d/common-account
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so

/etc/pam.d/common-auth
auth [success=1 default=ignore] pam_unix.so nullok_secure

/etc/pam.d/common-password
password [success=1 default=ignore] pam_unix.so obscure md5 Mam nadzieję, że nie zamotałem za zbytnio :P

Edit:
Restartować maszyny nie musisz. PAM działa od razu. I tu pojawia się dodatkowy problem. Jak coś się zwali w którymś z tych plików, to będzie kicha i trzeba będzie startować system w "Single mode". Staraj się zatem mieć w jakiejś konsoli otwartą sesję roota, by w razie czego cofnąć zmiany.
Ciekawi mnie jeszcze wynik polecenia:
grep -E "^[^#].*pam_unix" /etc/pam.d/* Czy w ogóle gdzieś pam_unix.so jest przez Twój system używany? Możliwe bowiem, że masz trochę przerobioną konfigurację PAM.