[plug] sshd help (take2)
Denis Brown
dsbrown at cyllene.uwa.edu.au
Mon Feb 7 21:29:31 WST 2005
Sigh,
Not quite as simple as I thought! Okay, the situation appears to be that
sshd sessions "hang about" in the process list so that even though the
vanilla user logs off, if that logoff was un-clean for some reason(?) then
the sshd process refuses to allow further connections. For any
user. Consider:
After sending my previous mail I switched back to the PuTTY session for the
vanilla user. I was able to do some simple things (like an ls, and ps)
and then chose to log out. I then tried to log on again as the same
vanilla user, only to be refused connection. Then I tried another
non-root account - same refusal. Examining the ps listing shows that in
fact the original login session is still in force, despite the fact that I
terminated it! So now I have
a) stale login session for vanilla user with a "good" looking ps listing
(the [priv] and non-priv parts of the protocol are displayed)
b) the classic three [priv], [net] and [pam] processes that seem to spell
doom for the vanilla user and
c) another three processes-of-doom [priv], [net] and [pam] for the second
non-root user.
This IS starting to turn into a show stopper especially as I had hopes of
remotely admin'ing the machine from home - while otherwise on
holidays! If I go to the console and as root kill the sshd processes that
refer to the supposedly logged-out vanilla user then I can log in via ssh
as either non-root user quite happily.
Thoughts appreciated. Google is not too helpful on this one it
seems. The PuTTY website FAQ does mention the error messages but puts
them down to Windows networking issues. Okay I am not surprised but why
now, when in an earlier life it was all working fine? In any event this
is looking more and more like a dyspepsia in Gentoo. In case anyone was
wondering, attempting login from another Linux machine (Debian as it
happens) showed nothing helpful even with -v -v and -v as arguments.
Denis
More information about the plug
mailing list