| 1 |
On Monday 04 May 2009 06:04:16 Valmor de Almeida wrote: |
| 2 |
> Alan McKinnon wrote: |
| 3 |
> > On Sunday 03 May 2009 04:53:41 Mike Kazantsev wrote: |
| 4 |
> >> On Sat, 02 May 2009 20:52:39 -0400 |
| 5 |
> >> |
| 6 |
> >> I don't know about motd, but the rest looks like pam problem to me, if |
| 7 |
> >> you're using pam, of course. Try 'euse -i pam' to see if it's enabled. |
| 8 |
> >> |
| 9 |
> >> If that's the case, first of all I'd suggest to check etc-update. |
| 10 |
> >> Then look through /etc/pam.d, especially system-* files. There you can |
| 11 |
> >> remove some of the required (for successfull authentication) modules, |
| 12 |
> >> so their failure won't affect the process. |
| 13 |
> > |
| 14 |
> > And read the elogs. There's been some pam updates come through on my |
| 15 |
> > machines the last few weeks/months. |
| 16 |
> |
| 17 |
> I re-emerged pam and following this message: |
| 18 |
> |
| 19 |
> -------------- |
| 20 |
> LOG: postinst |
| 21 |
> Starting from version 20080801, pambase optionally enables |
| 22 |
> SHA512-hashed passwords. For this to work, you need sys-libs/pam-1.0.1 |
| 23 |
> built against sys-libs/glibc-2.7 or later. |
| 24 |
|
| 25 |
I imagine this constraint is satisfied on your machines, otherwise that pam |
| 26 |
would not have been emerged due to blockers in the ebuild |
| 27 |
|
| 28 |
[snip] |
| 29 |
|
| 30 |
> since I find this in /etc/pam.d/system-auth |
| 31 |
> |
| 32 |
> ------------ |
| 33 |
> password required pam_unix.so try_first_pass use_authtok |
| 34 |
> nullok sha512 shadow |
| 35 |
> -------------- |
| 36 |
> |
| 37 |
> After these changes (do I need to reboot? I am doing this remotely so I |
| 38 |
> will have to wait till I can sit on the console) still can't login or su |
| 39 |
> to 3 of the accounts. Also created a new account and no luck login to to |
| 40 |
> it nor using su. Apparently newly created accounts definitely are |
| 41 |
> affected. Older accounts still work (???) |
| 42 |
|
| 43 |
You don't need to reboot - pam config is dynamic. Here's a quick go/no-go |
| 44 |
experiment to see if it's the new hashes that are doing it. Find an account |
| 45 |
that can sudo to root on the affected machines and examine the shadow file. |
| 46 |
See what kind of hashes the affected accounts are using. md5 is 34 characters |
| 47 |
long and sha512 is 98 in this format: |
| 48 |
|
| 49 |
$x$<salt>$<hash> |
| 50 |
x is 1 for md5 and 6 for sha512. <salt> is 8 characters for both |
| 51 |
|
| 52 |
If the affected account is sha512, run |
| 53 |
|
| 54 |
openssl passwd -1 |
| 55 |
|
| 56 |
to generate an md5 hash, and copy paste it back into field 2 of your account |
| 57 |
in shadow. You might want to comment out a copy of the original line just in |
| 58 |
case. See if sudo now works. If so, hashes are the problem. If not, we should |
| 59 |
look further, especially at the pam config for sudo. |
| 60 |
|
| 61 |
Here's mine which works: |
| 62 |
|
| 63 |
auth include system-auth |
| 64 |
account include system-auth |
| 65 |
password include system-auth |
| 66 |
session include system-auth |
| 67 |
|
| 68 |
And you did confirm that sudo checks for wheel group membership, and that you |
| 69 |
are still in this group? |
| 70 |
|
| 71 |
-- |
| 72 |
alan dot mckinnon at gmail dot com |
Archives