[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ale] openssh server returns FIN immediately after the TCP handshake
Thanks, mike. What you said is pretty close to what happened. Some
ldap problem prevented 'sshd', the special user needed for openssh
priv-separation, from being recognized as a user. Master sshd process
couldn't drop priv for the child sshd process.
- Original message -
I've seen that happen after an update has updated sshd a...
On 2/27/08, Michael H. Warfield <mhw at wittsend.com> wrote:
> On Wed, 2008-02-27 at 11:34 -0500, Jerry Yu wrote:
> > Starting today, I couldn't ssh into a production server, a stock
> > installation of RHEL 5.1/PPC (a LPAR on a 16-way power5 server).
> > tcpdump showed FIN packet was received on the client, immediately
> > after the TCP handshake (SYN + SYN ACK + ACK) was done.
> > The server functions otherwise (nfsd & syslogd).
> > If it matters, all os access accounts are controlled by a remote LDAP
> > server. Same accounts can be used to authenticate the user
> > successfully on other RHEL 5.1/ppc against this LDAP server
> I've seen that happen after an update has updated sshd and not
> restarted the server. The master server seems to run fine but the
> instant it forks off a child the child dies due to some library problem.
> Try restarting that sshd. Obviously, you've got a chicken and egg
> situation if you can't connect to the server to restart the sshd so you
> can connect to the server...
> Interesting that this has occurred today. I just checked one of my
> CentOS boxes and there are some OpenLDAP updates in that pipe. First
> restart the sshd server. Second, restart any ldap processes.
> Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com
> /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
> NIC whois: MHW9 | An optimist believes we live in the best of
> PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
Sent from Gmail for mobile | mobile.google.com