Connection reset by peer

[Stephen Carville]

Tom H wrote:
> Furnish, Trever G wrote:
>> You didn't note where you did your capture (on the client, the server,
>> or some intermediary device).  Presuming that you did the capture on the
>> client, I'd do a similar capture on the server and verify that it's
>> really the server sending the rst.  Lots of firewalls send RSTs in both
>> directions to break connections.
>>   
> 
> I've managed to replicate this with 2 servers that are in the same vlan, 
> plugged into the same switch. No firewall or suchlike causing the problem.
> It's very weird, I'm starting to suspect the Tigon drivers for the 
> broadcom BCM5703 card. im going to switch back to the bcm driver and see 
> if it make any difference.
> 
> However, I have 12 blades running exactly the same build of RHEL4 
> x86_64, and only 4 servers that are having the problem, and they are in 
> different enclosures.

Unfortunately the "Connection reset by peer" error can mean about a 
zillion and one things.  It is actually sent by glibc which doesn't help 
much either.

I was looking tht the emails and this line looks like you might be 
trying to start a process at the server end and it is failing:

debug1: Transferred: stdin 0, stdout 0, stderr 126 bytes in
  0.2 seconds

Did you check var log secure to make sure it isn't a permission, 
authentication, or PAM issue?

No IP conclicts?

No dupliate MAC addresses?

> Cheers,
> 
> Tom
> 
> 
> 
> 
> 
> 
>> If it really does turn out that the server is sending an RST, then I'd
>> start the server with debugging output turned on and look for clues
>> there.
>>  
>>
>>   
>>> -----Original Message-----
>>> From: redhat-list-bounces at redhat.com 
>>> [mailto:redhat-list-bounces at redhat.com] On Behalf Of Tom H
>>> Sent: Wednesday, May 09, 2007 4:58 PM
>>> To: redhat-list at redhat.com
>>> Subject: ssh: Connection reset by peer
>>>
>>> Hi,
>>>
>>> I have a couple of RHEL4 which have started disconnecting me 
>>> during ssh login after I enter the correct password;
>>>
>>> "Read from remote host msweb01.test.ms.osti.local: Connection 
>>> reset by peer Connection to msweb01.test.ms.osti.local closed."
>>>
>>> I turned on -vvv debugging on the client and the relevant section is;
>>>
>>> debug3: remaining preferred: ,password
>>> debug3: authmethod_is_enabled password
>>> debug1: Next authentication method: password 
>>> txxxxxx at msweb01.test.ms.osti.local's password:
>>> debug3: packet_send2: adding 48 (len 61 padlen 19 extra_pad 64)
>>> debug2: we sent a password packet, wait for reply
>>> debug1: Authentication succeeded (password).
>>> debug1: channel 0: new [client-session]
>>> debug3: ssh_session2_open: channel_new: 0
>>> debug2: channel 0: send open
>>> debug1: Entering interactive session.
>>> debug1: channel 0: free: client-session, nchannels 1
>>> debug3: channel 0: status: The following connections are open:
>>>   #0 client-session (t3 r-1 i0/0 o0/0 fd 4/5 cfd -1)
>>>
>>> debug3: channel 0: close_fds r 4 w 5 e 6 c -1 Read from 
>>> remote host msweb01.test.ms.osti.local: Connection reset by 
>>> peer Connection to msweb01.test.ms.osti.local closed.
>>> debug1: Transferred: stdin 0, stdout 0, stderr 126 bytes in 
>>> 0.2 seconds
>>> debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 703.9
>>> debug1: Exit status -1
>>>
>>>
>>> A tcpdump shows that the server is sending a RST, ACK to 
>>> close the connection. The server debug logs has the following;
>>>
>>>
>>> Apr 27 04:08:24 msweb01 sshd[13481]: debug2: monitor_read: 46 
>>> used once, 
>>> disabling now
>>> Apr 27 04:08:24 msweb01 sshd[13481]: debug2: monitor_read: 3 
>>> used once, 
>>> disabling now
>>> Apr 27 04:08:24 msweb01 sshd[13481]: debug2: monitor_read: 4 
>>> used once, 
>>> disabling now
>>> Apr 27 04:08:24 msweb01 sshd[13481]: debug2: monitor_read: 9 
>>> used once, 
>>> disabling now
>>> Apr 27 03:08:24 msweb01 sshd[13482]: debug1: userauth_banner: sent
>>> Apr 27 03:08:24 msweb01 sshd[13482]: Failed none for txxxxxx from 
>>> 10.127.5.104 port 4460 ssh2
>>> Apr 27 03:08:27 msweb01 sshd[13482]: debug1: userauth-request 
>>> for user 
>>> txxxxxx service ssh-connection method password
>>> Apr 27 03:08:27 msweb01 sshd[13482]: debug1: attempt 1 failures 1
>>> Apr 27 03:08:27 msweb01 sshd[13482]: debug2: 
>>> input_userauth_request: try 
>>> method password
>>> Apr 27 04:08:27 msweb01 sshd[13481]: debug1: PAM: password 
>>> authentication accepted for txxxxxx
>>> Apr 27 04:08:27 msweb01 sshd[13481]: Accepted password for 
>>> txxxxxx from 
>>> 10.127.5.104 port 4460 ssh2
>>> Apr 27 03:08:27 msweb01 sshd[13482]: Accepted password for 
>>> txxxxxx from 
>>> 10.127.5.104 port 4460 ssh2
>>> Apr 27 04:08:27 msweb01 sshd[13481]: debug1: monitor_child_preauth: 
>>> txxxxxx has been authenticated by privileged process
>>> Apr 27 04:08:27 msweb01 sshd[13481]: debug2: mac_init: found hmac-md5
>>> Apr 27 04:08:27 msweb01 sshd[13481]: debug2: mac_init: found hmac-md5
>>> Apr 27 04:08:27 msweb01 sshd[13481]: debug2: User child is on 
>>> pid 13484
>>> Apr 27 04:08:27 msweb01 sshd[13481]: debug1: do_cleanup
>>> Apr 27 04:08:27 msweb01 sshd[13481]: debug1: PAM: cleanup
>>>
>>>
>>>
>>> Any ideas on what might cause that?
>>>
>>> Thanks,
>>>
>>> Tom
>>>
>>>
>>>
>>>
>>> -- 
>>> redhat-list mailing list
>>> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
>>> https://www.redhat.com/mailman/listinfo/redhat-list
>>>
>>>     
>>   
> 


-- 
Stephen Carville <stephen at totalflood.com>
Systems Engineer
Land America
1.626.667.1450 X326