Re: Authentication breakdown
On Tue, Apr 7, 2015 at 6:48 PM, Karl E. Jorgensen <karl@jorgensen.org.uk> 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...
Reply to: