Mailing List Archive

Tuc at T-B-O-H wrote:
> Is there a way to tell why I'm getting frequent
> "Connection reset by peer" all of a sudden?
>
> I'm using a FreeBSD machine, plugged via eithernet to a Linksys
> router running DD-WRT, to another Linksys 50 feet away running DD-WRT,
> both of them WDS'd together, plugged via ethernet to another FreeBSD machine.
> With debug cranked, I see :

1) check the SSH server's logs to see if there's any logged message
corresponding to the disconnects. If the problem is easy to reproduce,
you could run sshd in debug mode in the foreground (eg "/path/to/sshd
-ddde -p 2022" then connect to port 22).

2) if that doesn't have anything, or has the same "connection reset by
peer message" then you probably will need to run tcpdump or similar to
see which end is generating the TCP RST (in theory it should be only
generated by one of the TCP endpoints but it could also be generated by,
eg an intermediate NAT box).

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

>
> Tuc at T-B-O-H wrote:
> > Is there a way to tell why I'm getting frequent
> > "Connection reset by peer" all of a sudden?
> >
> > I'm using a FreeBSD machine, plugged via eithernet to a Linksys
> > router running DD-WRT, to another Linksys 50 feet away running DD-WRT,
> > both of them WDS'd together, plugged via ethernet to another FreeBSD machine.
> > With debug cranked, I see :
>
> 1) check the SSH server's logs to see if there's any logged message
> corresponding to the disconnects. If the problem is easy to reproduce,
> you could run sshd in debug mode in the foreground (eg "/path/to/sshd
> -ddde -p 2022" then connect to port 22).
>
> 2) if that doesn't have anything, or has the same "connection reset by
> peer message" then you probably will need to run tcpdump or similar to
> see which end is generating the TCP RST (in theory it should be only
> generated by one of the TCP endpoints but it could also be generated by,
> eg an intermediate NAT box).
>
Hi,

Thanks for the reply...

1) Nothing out of the ordinary in the logs.

Last bit of logging from the server before/after it happens :

debug3: tty_parse_modes: 93 0
debug1: server_input_channel_req: channel 0 request shell reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: PAM: setting PAM_TTY to "/dev/ttyp4"
debug2: fd 5 setting TCP_NODELAY
debug2: channel 0: rfd 10 isatty
debug2: fd 10 setting O_NONBLOCK
debug2: fd 9 is O_NONBLOCK
debug1: Setting controlling tty using TIOCSCTTY.
debug3: mm_answer_pty: tty /dev/ttyp4 ptyfd 3
debug3: mm_request_receive entering
Read error from remote host 10.0.0.1: Connection reset by peer
debug1: do_cleanup
debug1: PAM: cleanup
debug3: PAM: sshpam_thread_cleanup entering
debug1: do_cleanup
debug1: PAM: cleanup
debug3: PAM: sshpam_thread_cleanup entering
debug1: session_pty_cleanup: session 0 release /dev/ttyp4

2) TCPDUMP available to anyone that wants it via email (21K)

The last "good" packet between the SSH server and client looked
pretty normal, has Flags of PSH and ACK.

The next packet comes from the router closest to the SSH server.
There is no sequence or acknowledgement number, but its claiming
to originate from the same port that the client originally was
using. The window size is 1/2 of what the client/server window
was. Its sending to the SSH server an ACK.

The next packet is from the SSH server to the router, there
is no sequence number, window size is 0, Flags are RST.

Next packet is from the SSH server to the client, marked
as a TCP retransmission, same sequence as the last "good"
packet, PSH,ACK

Last packet is from SSH client to server, with RST Flag
set.

So why is the router jumping into the middle of
the conversation and being a spoil sport?

Thanks, Tuc
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Tuc at T-B-O-H.NET wrote:
>> Tuc at T-B-O-H wrote:
>>> Is there a way to tell why I'm getting frequent
>>> "Connection reset by peer" all of a sudden?
>>>
>>> I'm using a FreeBSD machine, plugged via eithernet to a Linksys
>>> router running DD-WRT, to another Linksys 50 feet away running DD-WRT,
>>> both of them WDS'd together, plugged via ethernet to another FreeBSD machine.
>>> With debug cranked, I see :
>> 1) check the SSH server's logs to see if there's any logged message
>> corresponding to the disconnects. If the problem is easy to reproduce,
>> you could run sshd in debug mode in the foreground (eg "/path/to/sshd
>> -ddde -p 2022" then connect to port 22).
>>
>> 2) if that doesn't have anything, or has the same "connection reset by
>> peer message" then you probably will need to run tcpdump or similar to
>> see which end is generating the TCP RST (in theory it should be only
>> generated by one of the TCP endpoints but it could also be generated by,
>> eg an intermediate NAT box).
>>
> Hi,
>
> Thanks for the reply...
>
> 1) Nothing out of the ordinary in the logs.
>
> Last bit of logging from the server before/after it happens :
>
> debug3: tty_parse_modes: 93 0
> debug1: server_input_channel_req: channel 0 request shell reply 0
> debug1: session_by_channel: session 0 channel 0
> debug1: session_input_channel_req: session 0 req shell
> debug1: PAM: setting PAM_TTY to "/dev/ttyp4"
> debug2: fd 5 setting TCP_NODELAY
> debug2: channel 0: rfd 10 isatty
> debug2: fd 10 setting O_NONBLOCK
> debug2: fd 9 is O_NONBLOCK
> debug1: Setting controlling tty using TIOCSCTTY.
> debug3: mm_answer_pty: tty /dev/ttyp4 ptyfd 3
> debug3: mm_request_receive entering
> Read error from remote host 10.0.0.1: Connection reset by peer
> debug1: do_cleanup
> debug1: PAM: cleanup
> debug3: PAM: sshpam_thread_cleanup entering
> debug1: do_cleanup
> debug1: PAM: cleanup
> debug3: PAM: sshpam_thread_cleanup entering
> debug1: session_pty_cleanup: session 0 release /dev/ttyp4
>
> 2) TCPDUMP available to anyone that wants it via email (21K)
>
> The last "good" packet between the SSH server and client looked
> pretty normal, has Flags of PSH and ACK.
>
> The next packet comes from the router closest to the SSH server.
> There is no sequence or acknowledgement number, but its claiming
> to originate from the same port that the client originally was
> using. The window size is 1/2 of what the client/server window
> was. Its sending to the SSH server an ACK.
>
> The next packet is from the SSH server to the router, there
> is no sequence number, window size is 0, Flags are RST.
>
> Next packet is from the SSH server to the client, marked
> as a TCP retransmission, same sequence as the last "good"
> packet, PSH,ACK

Check the IP TOS bits on the packets as I think that's around the point
that it sets IPTOS_LOWDELAY. I have heard that some NAT/firewall
devices can't handle a connection where the TOS changes mid-connection.

If you have netcat installed, you can try this:

ssh -o "ProxyCommand nc %h %p" yourserver

as a quick test.

> Last packet is from SSH client to server, with RST Flag
> set.
>
> So why is the router jumping into the middle of
> the conversation and being a spoil sport?
>
> Thanks, Tuc
>


--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

>
> Tuc at T-B-O-H.NET wrote:
> >> Tuc at T-B-O-H wrote:
> >>> Is there a way to tell why I'm getting frequent
> >>> "Connection reset by peer" all of a sudden?
> >>>
> >>> I'm using a FreeBSD machine, plugged via eithernet to a Linksys
> >>> router running DD-WRT, to another Linksys 50 feet away running DD-WRT,
> >>> both of them WDS'd together, plugged via ethernet to another FreeBSD machine.
> >>> With debug cranked, I see :
> >> 1) check the SSH server's logs to see if there's any logged message
> >> corresponding to the disconnects. If the problem is easy to reproduce,
> >> you could run sshd in debug mode in the foreground (eg "/path/to/sshd
> >> -ddde -p 2022" then connect to port 22).
> >>
> >> 2) if that doesn't have anything, or has the same "connection reset by
> >> peer message" then you probably will need to run tcpdump or similar to
> >> see which end is generating the TCP RST (in theory it should be only
> >> generated by one of the TCP endpoints but it could also be generated by,
> >> eg an intermediate NAT box).
> >>
> > Hi,
> >
> > Thanks for the reply...
> >
> > 1) Nothing out of the ordinary in the logs.
> >
> > Last bit of logging from the server before/after it happens :
> >
> > debug3: tty_parse_modes: 93 0
> > debug1: server_input_channel_req: channel 0 request shell reply 0
> > debug1: session_by_channel: session 0 channel 0
> > debug1: session_input_channel_req: session 0 req shell
> > debug1: PAM: setting PAM_TTY to "/dev/ttyp4"
> > debug2: fd 5 setting TCP_NODELAY
> > debug2: channel 0: rfd 10 isatty
> > debug2: fd 10 setting O_NONBLOCK
> > debug2: fd 9 is O_NONBLOCK
> > debug1: Setting controlling tty using TIOCSCTTY.
> > debug3: mm_answer_pty: tty /dev/ttyp4 ptyfd 3
> > debug3: mm_request_receive entering
> > Read error from remote host 10.0.0.1: Connection reset by peer
> > debug1: do_cleanup
> > debug1: PAM: cleanup
> > debug3: PAM: sshpam_thread_cleanup entering
> > debug1: do_cleanup
> > debug1: PAM: cleanup
> > debug3: PAM: sshpam_thread_cleanup entering
> > debug1: session_pty_cleanup: session 0 release /dev/ttyp4
> >
> > 2) TCPDUMP available to anyone that wants it via email (21K)
> >
> > The last "good" packet between the SSH server and client looked
> > pretty normal, has Flags of PSH and ACK.
> >
> > The next packet comes from the router closest to the SSH server.
> > There is no sequence or acknowledgement number, but its claiming
> > to originate from the same port that the client originally was
> > using. The window size is 1/2 of what the client/server window
> > was. Its sending to the SSH server an ACK.
> >
> > The next packet is from the SSH server to the router, there
> > is no sequence number, window size is 0, Flags are RST.
> >
> > Next packet is from the SSH server to the client, marked
> > as a TCP retransmission, same sequence as the last "good"
> > packet, PSH,ACK
>
> Check the IP TOS bits on the packets as I think that's around the point
> that it sets IPTOS_LOWDELAY. I have heard that some NAT/firewall
> devices can't handle a connection where the TOS changes mid-connection.
>
> If you have netcat installed, you can try this:
>
> ssh -o "ProxyCommand nc %h %p" yourserver
>
> as a quick test.
>
There is no NAT enabled devices between system. There are no
SPI firewalls between systems. The 2 systems go out eithernet to a
Linksys Router running DD-WRT thats basically been put into "DUMB" mode
and WDS'd together.

I think wireshark calls TOS "Differentiated Services Field".
About 31 packets in I see my client sending to the server 0x10,
which isn't that IPTOS_LOWDELAY? (From FreeBSD netinet/ip.h :

#define IPTOS_LOWDELAY 0x10

Trouble doesn't seem to star until about 104 packets in.
TOS is set to 0x10 about 76 times in the entire conversation.

I ran what you said, and the first one ran for about
2 minutes and then :

Connection to 10.0.0.6 closed by remote host.
Connection to 10.0.0.6 closed.

And the 2nd time about 20 seconds before the same.

Thanks, Tuc
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Tue, Jan 29, 2008, Tuc at T-B-O-H.NET wrote about "Re: [openssh] Re: Frequent "Connection reset by peer"":
> I ran what you said, and the first one ran for about
> 2 minutes and then :
>
> Connection to 10.0.0.6 closed by remote host.
> Connection to 10.0.0.6 closed.
>
> And the 2nd time about 20 seconds before the same.

If I understood correctly, what you ran just opened a connection, but passed
no data for two minutes. Is it possible that your router simply disconnects
inactive TCP connections after two minutes, in the pretext of saving memory,
guard against DOS attacks, or who knows what?

You can try setting ServerAliveInterval in your client to something less than
two minutes, and see if it helps. E.g., in your ~/.ssh/config put

ServerAliveInterval 60


--
Nadav Har'El | Thursday, Jan 31 2008, 24 Shevat 5768
nyh@math.technion.ac.il |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |He who has more is not happier than he
http://nadav.harel.org.il |who wants less.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Nadav Har'El wrote:
> On Tue, Jan 29, 2008, Tuc at T-B-O-H.NET wrote about "Re: [openssh] Re: Frequent "Connection reset by peer"":
>> I ran what you said, and the first one ran for about
>> 2 minutes and then :
>>
>> Connection to 10.0.0.6 closed by remote host.
>> Connection to 10.0.0.6 closed.
>>
>> And the 2nd time about 20 seconds before the same.
>
> If I understood correctly, what you ran just opened a connection, but passed
> no data for two minutes. Is it possible that your router simply disconnects
> inactive TCP connections after two minutes, in the pretext of saving memory,
> guard against DOS attacks, or who knows what?

Good point, and that reminds me: another thing to check for,
particularly if you have links with differing MTUs, is fragmentation
problems:

http://www.snailbook.com/faq/mtu-mismatch.auto.html

A dead giveaway for this problem is if you see a non-zero and increasing
number in the SendQ column in the "netstat" output for the SSH
connection (on either server or client end of the connection).

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

>
> On Tue, Jan 29, 2008, Tuc at T-B-O-H.NET wrote about "Re: [openssh] Re: Frequent "Connection reset by peer"":
> > I ran what you said, and the first one ran for about
> > 2 minutes and then :
> >
> > Connection to 10.0.0.6 closed by remote host.
> > Connection to 10.0.0.6 closed.
> >
> > And the 2nd time about 20 seconds before the same.
>
> If I understood correctly, what you ran just opened a connection, but passed
> no data for two minutes. Is it possible that your router simply disconnects
> inactive TCP connections after two minutes, in the pretext of saving memory,
> guard against DOS attacks, or who knows what?
>
> You can try setting ServerAliveInterval in your client to something less than
> two minutes, and see if it helps. E.g., in your ~/.ssh/config put
>
> ServerAliveInterval 60
>
Hi,

I'm sorry if somehow you took away that I didn't do anything for
the 2 minutes. Every time I'm testing I am either scurring to get something
typed in before it disconnects, or I am running "ls" over and over and having
it quit mid my typing or mid the response.

Absolutely not a timeout issue. When I was asked to do the last
test, it took me 7 logins just to get screen running, start tcpdump
writing to a file listening on 2022, and in another window start ssh on
2022. So there was never a second I wasn't typing or there wasn't screen
interaction, and it still dumped me 6 times.

The only reason I was able to get that long seemed to be using
the ProxyCommand. Without it, normal sessions lasted anywhere from 0
(Yes, it would disconnect before I could type the 8 character password
I've been using for 29 year and could type in my sleep) to 15 or 20
seconds.

I also get knocked off of SSH from the ROUTER ITSELF.

So this can't be it.

I set up where past the "router" and laptop, I wireless connected
to a home router, and then out to the net. With this, if I ssh to a
machine outside the site, I can stay connected for DAYS.

laptop->router+ddwrt|====air===|router+ddwrt->laptop+NAT===air===router->cablemodem
....................SSH PROBLEMS HERE.SSH PROBLEMS H...............................

I'm guessing if RSTs are generated, they aren't able to get to/past
the cable modem.


Thanks, Tuc
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

>
> Nadav Har'El wrote:
> > On Tue, Jan 29, 2008, Tuc at T-B-O-H.NET wrote about "Re: [openssh] Re: Frequent "Connection reset by peer"":
> >> I ran what you said, and the first one ran for about
> >> 2 minutes and then :
> >>
> >> Connection to 10.0.0.6 closed by remote host.
> >> Connection to 10.0.0.6 closed.
> >>
> >> And the 2nd time about 20 seconds before the same.
> >
> > If I understood correctly, what you ran just opened a connection, but passed
> > no data for two minutes. Is it possible that your router simply disconnects
> > inactive TCP connections after two minutes, in the pretext of saving memory,
> > guard against DOS attacks, or who knows what?
>
> Good point, and that reminds me: another thing to check for,
> particularly if you have links with differing MTUs, is fragmentation
> problems:
>
> http://www.snailbook.com/faq/mtu-mismatch.auto.html
>
> A dead giveaway for this problem is if you see a non-zero and increasing
> number in the SendQ column in the "netstat" output for the SSH
> connection (on either server or client end of the connection).
>
I wouldn't have time to even run a netstat.

I went back to my original dump, and verified that no received
packet had the fragment bit on. Not even towards the end that it was
expecting a fragment but never received it.

But would the device have sent a RST if it received a fragment
it couldn't route? I'm getting an actual RST from the router on the other
end of a WDS link towards the far end laptop.

Thanks, Tuc
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 2008-01-31 13:44, Tuc at T-B-O-H.NET wrote:
> But would the device have sent a RST if it received a fragment
> it couldn't route? I'm getting an actual RST from the router on the other
> end of a WDS link towards the far end laptop.

Some versions of Linux wrongly generate an RST in response to a bad TCP
checksum. (Wrongly because the bad checksum is telling you you can't
trust the TCP header and payload, so why generate an RST using values
from the header?) I've had problems in the past with simply bad cabling
exercising this bug.

--
Jefferson Ogata <Jefferson.Ogata@noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt@noaa.gov>
"Never try to retrieve anything from a bear."--National Park Service
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Hi,

On Thu, Jan 31, 2008 at 08:35:06AM -0500, Tuc at T-B-O-H.NET wrote:
> I also get knocked off of SSH from the ROUTER ITSELF.

I have seen this happen when I had a duplicate IP address on the LAN -
every time the packet happened to hit the "other" box, it caused a RST
(because the other box didn't know anything about it).

You can see this if you look into the ARP caches of other boxes on the
same network - if the server IP address is alternating between different
MAC addresses, you have a double IP address.

gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert@greenie.muc.de
fax: +49-89-35655025 gert@net.informatik.tu-muenchen.de
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

>
> Hi,
>
> On Thu, Jan 31, 2008 at 08:35:06AM -0500, Tuc at T-B-O-H.NET wrote:
> > I also get knocked off of SSH from the ROUTER ITSELF.
>
> I have seen this happen when I had a duplicate IP address on the LAN -
> every time the packet happened to hit the "other" box, it caused a RST
> (because the other box didn't know anything about it).
>
> You can see this if you look into the ARP caches of other boxes on the
> same network - if the server IP address is alternating between different
> MAC addresses, you have a double IP address.
>
The entire network (prior to adding the outside link, which
happened AFTER all the problems started) is 4 pieces of equipment. The arp table
shows only all 4 of them. I'm using 10.0.0.0/24. When it was isolated to
just those 4 pieces of equipment, and impossible for any other piece of
equipment to be a part of the network, the problems existed. Adding the
new part has not changed the original way the network acts at all.

If there were any arp changes, the machines would be logging
it.

Tuc
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

>
> On 2008-01-31 13:44, Tuc at T-B-O-H.NET wrote:
> > But would the device have sent a RST if it received a fragment
> > it couldn't route? I'm getting an actual RST from the router on the other
> > end of a WDS link towards the far end laptop.
>
> Some versions of Linux wrongly generate an RST in response to a bad TCP
> checksum. (Wrongly because the bad checksum is telling you you can't
> trust the TCP header and payload, so why generate an RST using values
> from the header?) I've had problems in the past with simply bad cabling
> exercising this bug.
>
But would it generate the RST *FORWARD* or *BACKWARD*?
So generally if .1 sends a packet through .2 which is WDS'd
to .5 for .6 ... If .1 or .2 forwarded/created a bad packet
destined for .6, would .5 deliver the RST to .1/.2 or to
.6? My situation is .1 sends, through .2 (Ethernet input,
WDS/radio output) to .5 (radio/WDS input, ethernet output)
for .6.

.5 sends the RST to .6. I've checked the checksums
I can capture off .6 for checksum issues, none were marked
that way.

I'll swap out the far side cable to see if it helps.

Thanks, Tuc
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

>
> On 2008-01-31 13:44, Tuc at T-B-O-H.NET wrote:
> > But would the device have sent a RST if it received a fragment
> > it couldn't route? I'm getting an actual RST from the router on the other
> > end of a WDS link towards the far end laptop.
>
> Some versions of Linux wrongly generate an RST in response to a bad TCP
> checksum. (Wrongly because the bad checksum is telling you you can't
> trust the TCP header and payload, so why generate an RST using values
> from the header?) I've had problems in the past with simply bad cabling
> exercising this bug.
>
New cables on one side, then the other, then both. Still
happening.

Tuc
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Tuc at T-B-O-H.NET wrote:
> New cables on one side, then the other, then both. Still
> happening.
>
> Tuc
>
Hi Tuc,

Sorry to come into this discussion late, I was wondering what DD-WRT
version you are running in WDS ? What wireless security settings have
you chosen (there are known issues with WDS and WPA2/PSK) ?

With the "I also get knocked off of SSH from the ROUTER ITSELF."
statement, do you mean when you are connected via wire to that router ?

As a final thing to try, check out the latest v24RC6v2.

Damien


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

I have the very same problem, but in a quite different environment.

I have three machines, all using ubuntu, but different versions.
One of the machines is supposed to be a common storage for the other two to copy data to as some sort of backup.

One of the machines can connect to the "backup machine" just fine, but the other can't, receiving the exact error described in this thread.
To be more specific, both the machines can connect, but one of them loses connection in everything between 0-120 seconds.

Switching on verbose on the troubling machine I also get the:
"debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 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 ucsbackup03: Connection reset by peer
Connection to ucsbackup03 closed.
debug1: Transferred: stdin 0, stdout 0, stderr 96 bytes in 5329.1 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status -1"

And regarding the cabling, both the "client machines" are connected to the same virtual switch (they are virtual machines), so the cabling between the clients and the server is exactly the same, yet one work and one fail.

Sincerely,
Mattias
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

I have the very same problem, but in a quite different environment.

I have three machines, all using ubuntu, but different versions.
One of the machines is supposed to be a common storage for the other two to copy data to as some sort of backup.

One of the machines can connect to the "backup machine" just fine, but the other can't, receiving the exact error described in this thread.
To be more specific, both the machines can connect, but one of them loses connection in everything between 0-120 seconds.

Switching on verbose on the troubling machine I also get the:
"debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 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 ucsbackup03: Connection reset by peer
Connection to ucsbackup03 closed.
debug1: Transferred: stdin 0, stdout 0, stderr 96 bytes in 5329.1 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status -1"

And regarding the cabling, both the "client machines" are connected to the same virtual switch (they are virtual machines), so the cabling between the clients and the server is exactly the same, yet one work and one fail.

Sincerely,
Mattias

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev