Re: Authentication breakdown
On Tue, Apr 7, 2015 at 6:48 PM, Karl E. Jorgensen wrote:
> Hi
>
> On Tue, 2015-04-07 at 10:02 -0300, francis picabia wrote:
>> I'm having a perplexing problem around authentication on my home system.
>>
>> It has been running 32 bit Debian for years, and up to date with Debian 7.
>>
>> Nothing new had been installed or configured for months, only
>> aptitude update and aptitude safe-upgrade.
>>
>> This morning, checking email, I found thunderbird could not login to dovecot.
>> Restarted dovecot and no difference.
>>
>> SSH login failed from two different systems.
>>
>> I checked that the firewall on Linux was off.
>> I checked last reports and there was no unusual access.
>> Tested with chkrootkit and nothing came up.
>> This system is normally protected by unusual ssh port
>> plus denyhosts against brute force login.
>>
>> nsswitch.conf had compat for passwd, group and shadow,
>> and I switched it to "files", with no difference. Nothing
>> seemed odd under /etc/pam.d with the common-* files.
>>
>> Console login as my user or as root failed.
>>
>> dmesg didn't report anything unusual happened.
>>
>> Tried a passwd refresh to a new password. That required
>> entering my existing password, and entering the existing
>> password worked. However it wouldn't allow ssh or console
>> login with the changed password. I changed it back
>> to the usual password, and again, it accepted the
>> old password when prompted.
>
> If logins via both console and ssh failed (as both yourself and root),
> how did you get in?
Login with Recovery kernel option ('single' in the kernel options) worked.
But once the system was fully up, neither console (VT 1) nor ssh nor any
authenticating service would work.
> Once logged in, I would suggest that you study the log files before
> trying to change things. The log files are usually a much faster route
> to the underlying cause...
>
> Assuming you have a default(ish) syslog config, the first log file I'd
> look at is /var/log/auth.log. Then /var/log/kern.log and the remaining
> log files.
Yeah, I checked the auth.log and it didn't have details about
how/why it failed.
Anyhow, as I posted in another follow up, pam-auth-update
was able to clear the authentication pieces out I don't need.
That was the solution.
Thanks for the follow up...
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/ca+akb6eiu9297_vunmaxfrtvxznqcgorg7vjq3xtfhiuknh...@mail.gmail.com
Re: Authentication breakdown
On Tue, Apr 7, 2015 at 6:30 PM, francis picabia wrote: > On Tue, Apr 7, 2015 at 10:02 AM, francis picabia wrote: >> I'm having a perplexing problem around authentication on my home system. >> >> It has been running 32 bit Debian for years, and up to date with Debian 7. >> >> Nothing new had been installed or configured for months, only >> aptitude update and aptitude safe-upgrade. >> >> This morning, checking email, I found thunderbird could not login to dovecot. >> Restarted dovecot and no difference. >> >> SSH login failed from two different systems. >> >> I checked that the firewall on Linux was off. >> I checked last reports and there was no unusual access. >> Tested with chkrootkit and nothing came up. >> This system is normally protected by unusual ssh port >> plus denyhosts against brute force login. >> >> nsswitch.conf had compat for passwd, group and shadow, >> and I switched it to "files", with no difference. Nothing >> seemed odd under /etc/pam.d with the common-* files. >> >> Console login as my user or as root failed. >> >> dmesg didn't report anything unusual happened. >> >> Tried a passwd refresh to a new password. That required >> entering my existing password, and entering the existing >> password worked. However it wouldn't allow ssh or console >> login with the changed password. I changed it back >> to the usual password, and again, it accepted the >> old password when prompted. >> >> Eventually I was locked out when the screen save came on >> after leaving it alone for awhile. I rebooted, and the system still >> has this wacky behaviour. In addition, the gdm screen >> does not come up - displaying only an hourglass. >> VT consoles do come up after reboot, but again, >> console login as myself or root are failing, >> and ssh login from remote as myself is failing. >> >> I've never seen something like this fail before unless I had >> been messing around with pam configuration files. I'm currently >> unable to get into the system so I'll be getting a rescue CD >> set up to use later today. >> >> Anyone have suggestions on what could have happened? > > Working on this some more... > > On a single user login I can login as root, but not once it starts > services. I've attempted to trim back inits, but so far no difference > once it comes up after single user mode. > > In single user mode I can run debsums -cs and it doesn't discover > anything corrupted other than something I know about, like flashplayer. > /etc/inittab has the expected getty services, and lsattr doesn't > show anything odd about /sbin/getty. > > I'd like to see something that describes the bare minimum to get > Debian to boot multiuser - looking at rcconf there are several I'm > not sure I can do without. It is a system that has come from Debian 5 > to 6 to 7 so there are possibly left overs. But again, this is nothing > new and has not impacted anything before. The system had been > rebooted about a month before. Problem resolved... I decided to redo pam-auth-update with --force That was interesting as it showed stuff not in the common-* group: [*] Cracklib password strength checking [*] Unix authentication [ ] Winbind NT/Active Directory authentication [ ] GNOME Keyring Daemon - Login keyring management [ ] ConsoleKit Session Management I had checks in GNOME and ConsoleKit somehow. When those were removed then all authentication worked again. I don't know what change had recently crept up, but I can remember I was getting annoyed with a browser pop up about key rings, and I had done something which I had hoped would eliminate that. Perhaps that crippled this PAM plugin. Any I don't need it, so it is unchecked and I'm fine now. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ca+akb6fqhwj3pdzomvj0um0c0hbvxyhybhxag6dpogrbbee...@mail.gmail.com
Re: Authentication breakdown
Hi On Tue, 2015-04-07 at 10:02 -0300, francis picabia wrote: > I'm having a perplexing problem around authentication on my home system. > > It has been running 32 bit Debian for years, and up to date with Debian 7. > > Nothing new had been installed or configured for months, only > aptitude update and aptitude safe-upgrade. > > This morning, checking email, I found thunderbird could not login to dovecot. > Restarted dovecot and no difference. > > SSH login failed from two different systems. > > I checked that the firewall on Linux was off. > I checked last reports and there was no unusual access. > Tested with chkrootkit and nothing came up. > This system is normally protected by unusual ssh port > plus denyhosts against brute force login. > > nsswitch.conf had compat for passwd, group and shadow, > and I switched it to "files", with no difference. Nothing > seemed odd under /etc/pam.d with the common-* files. > > Console login as my user or as root failed. > > dmesg didn't report anything unusual happened. > > Tried a passwd refresh to a new password. That required > entering my existing password, and entering the existing > password worked. However it wouldn't allow ssh or console > login with the changed password. I changed it back > to the usual password, and again, it accepted the > old password when prompted. If logins via both console and ssh failed (as both yourself and root), how did you get in? Once logged in, I would suggest that you study the log files before trying to change things. The log files are usually a much faster route to the underlying cause... Assuming you have a default(ish) syslog config, the first log file I'd look at is /var/log/auth.log. Then /var/log/kern.log and the remaining log files. > Eventually I was locked out when the screen save came on > after leaving it alone for awhile. I rebooted, and the system still > has this wacky behaviour. Ah - a graphical login! I'd recommend staying with the console (text-only) login whilst diagnosing this. It's simpler software, and should thus be simpler to debug. And it is plausible that your gdm greeter is suffering from the same underlying cause... > > In addition, the gdm screen > does not come up - displaying only an hourglass. > VT consoles do come up after reboot, but again, > console login as myself or root are failing, > and ssh login from remote as myself is failing. > > I've never seen something like this fail before unless I had > been messing around with pam configuration files. I'm currently > unable to get into the system so I'll be getting a rescue CD > set up to use later today. Well - it is theoretically possible that a disk corruption has done something to your pam configuration. Hopefully the log files will contain clues so you don't have to rely on such wild unsubstantiated guesses... Hope this helps -- Karl E. Jorgensen -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1428443299.4670.13.ca...@jorgensen.org.uk
Re: Authentication breakdown
On Tue, Apr 7, 2015 at 10:02 AM, francis picabia wrote: > I'm having a perplexing problem around authentication on my home system. > > It has been running 32 bit Debian for years, and up to date with Debian 7. > > Nothing new had been installed or configured for months, only > aptitude update and aptitude safe-upgrade. > > This morning, checking email, I found thunderbird could not login to dovecot. > Restarted dovecot and no difference. > > SSH login failed from two different systems. > > I checked that the firewall on Linux was off. > I checked last reports and there was no unusual access. > Tested with chkrootkit and nothing came up. > This system is normally protected by unusual ssh port > plus denyhosts against brute force login. > > nsswitch.conf had compat for passwd, group and shadow, > and I switched it to "files", with no difference. Nothing > seemed odd under /etc/pam.d with the common-* files. > > Console login as my user or as root failed. > > dmesg didn't report anything unusual happened. > > Tried a passwd refresh to a new password. That required > entering my existing password, and entering the existing > password worked. However it wouldn't allow ssh or console > login with the changed password. I changed it back > to the usual password, and again, it accepted the > old password when prompted. > > Eventually I was locked out when the screen save came on > after leaving it alone for awhile. I rebooted, and the system still > has this wacky behaviour. In addition, the gdm screen > does not come up - displaying only an hourglass. > VT consoles do come up after reboot, but again, > console login as myself or root are failing, > and ssh login from remote as myself is failing. > > I've never seen something like this fail before unless I had > been messing around with pam configuration files. I'm currently > unable to get into the system so I'll be getting a rescue CD > set up to use later today. > > Anyone have suggestions on what could have happened? Working on this some more... On a single user login I can login as root, but not once it starts services. I've attempted to trim back inits, but so far no difference once it comes up after single user mode. In single user mode I can run debsums -cs and it doesn't discover anything corrupted other than something I know about, like flashplayer. /etc/inittab has the expected getty services, and lsattr doesn't show anything odd about /sbin/getty. I'd like to see something that describes the bare minimum to get Debian to boot multiuser - looking at rcconf there are several I'm not sure I can do without. It is a system that has come from Debian 5 to 6 to 7 so there are possibly left overs. But again, this is nothing new and has not impacted anything before. The system had been rebooted about a month before. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ca+akb6ggejy2qsfursle6rpddttjgnyxqdtbjnwlkwgawzu...@mail.gmail.com
Authentication breakdown
I'm having a perplexing problem around authentication on my home system. It has been running 32 bit Debian for years, and up to date with Debian 7. Nothing new had been installed or configured for months, only aptitude update and aptitude safe-upgrade. This morning, checking email, I found thunderbird could not login to dovecot. Restarted dovecot and no difference. SSH login failed from two different systems. I checked that the firewall on Linux was off. I checked last reports and there was no unusual access. Tested with chkrootkit and nothing came up. This system is normally protected by unusual ssh port plus denyhosts against brute force login. nsswitch.conf had compat for passwd, group and shadow, and I switched it to "files", with no difference. Nothing seemed odd under /etc/pam.d with the common-* files. Console login as my user or as root failed. dmesg didn't report anything unusual happened. Tried a passwd refresh to a new password. That required entering my existing password, and entering the existing password worked. However it wouldn't allow ssh or console login with the changed password. I changed it back to the usual password, and again, it accepted the old password when prompted. Eventually I was locked out when the screen save came on after leaving it alone for awhile. I rebooted, and the system still has this wacky behaviour. In addition, the gdm screen does not come up - displaying only an hourglass. VT consoles do come up after reboot, but again, console login as myself or root are failing, and ssh login from remote as myself is failing. I've never seen something like this fail before unless I had been messing around with pam configuration files. I'm currently unable to get into the system so I'll be getting a rescue CD set up to use later today. Anyone have suggestions on what could have happened? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ca+akb6h3d6bz-ot+2_khal3nqrryh1e8f2rqsizd0p_frcg...@mail.gmail.com
