[plug] sshd help please!!
Denis Brown
dsbrown at cyllene.uwa.edu.au
Mon Feb 7 20:44:19 WST 2005
Hello PLUG list members.
I'd appreciate some input on this conundrum regarding sshd. The platform
is Gentoo from the 2004.3 install and emerge --sync, emerge --update system
and emerge --update world have been done. Not much is installed on this
machine yet apart from xinetd, sshd, cupsd and xorg/KDE. The cups and
Xorg/KDE side is fine, xinetd is not doing anything at present and I may in
hindsight remove it since I am not planning to run ftp, web, mail or other
services on this machine. Sshd is protected by fairly strict entries in
the /etc/hosts.allow and .deny files (it was apparently compiled with
tcpwrappers.)
Sshd is giving a little pain though, as follows....
Sshd is started as normal (using the "/etc/init.d/sshd start" method,
although I will do this through rc-update later) and there appears just one
sshd process in a ps -A listing. So far so good. If I log on as a
normal (non-root) user, I see the original sshd daemon plus two new sshd
processes representing the priv. and non-priv. parts of ssh. So far so
good. If I then log off the vanilla user, the two latter processes
disappear which I take to be normal operation. So far so good.
However if I deliberately try naughty things like ssh'ing is as root, I get
a stern refusal, which is good, but subsequent attempts to log is as the
normal (non-root) user are also met with stern refusal! Here "stern
refusal" is identified as "Network error: Software caused connection
abort." from a Windows-based PuTTY impementation (the latest, version 0.56)
running on Win XP SP2 -- don't ask :-)
Examining the ps -A listing then shows the parent sshd process plus three
additional processes, [priv], [net] and [pam] for root and for the
now-refused user thus:
blah blah blah sshd: root[priv]
blah blah blah sshd: root[net]
blah blah blah sshd: root[pam]
blah blah blah sshd: vanilla[priv]
blah blah blah sshd: vanilla[net]
blah blah blah sshd: vanilla[pam]
After some time delay (not accurately measured it yet but I'd estimate 5 to
10 minutes), the vanilla user can again log on and the ps -A display shows
the root user's three sshd child processes have gone but the three for the
vanilla user remain. I suppose that in another few minutes those unwanted
vanilla-user process will also disappear.
Now to the questions!
1) Is the above par for the course with sshd (for there to be the priv, net
and pam variants)? [priv] and I guess [pam] I understand but [net] could
do with explanation.
2) In the event that I do something bad accidentally (i.e. drunk too little
coffee and attempted login as root via ssh) is there any way to decrease or
otherwise adjust the delay time for the above observations?
3) This behaviour (connection refusals) was not observed with two earlier
implementations of Gentoo and sshd on identical hardware. I recall a
problem that was traced to an early PuTTY version (might have been 0.53 or
0.54) that refused to parlay with the then release of sshd, but that was
common to my Debian installations as well as to the Gentoo's. Perhaps a
reflection of tightened security, recently?
Ahhh... just checked and yes, the bogus sshd: vanilla[net] and [pam] have
gone away while still leaving the vanilla user logged in. Yay!! So this
is no longer the show stopper that I thought it would be but it is none the
less annoying to suffer the time lag for subsequent connection refusals.
Thoughts appreciated as always!
Denis
More information about the plug
mailing list