[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