On Wed, 17 Mar 2021, Louis Guillaume wrote:
Connecting from NetBSD or macOS hosts gives the results I've been
describing. But a connection from Linux is never accepted. We get this
in the authlog:
ssh_dispatch_run_fatal: Connection from 192.168.1.127 port 35632:
Network is unreachable [preauth]
...
It's definitely something on the server. When this hangup happens I
see this in the authlog...
sshd[15352]: fatal: process_output: ssh_packet_write_poll: Network is
unreachable
... but the system is consistently up and transferring data with no
downtime (it is in fact a firewall). The problem seems isolated to
sshd, and only when a rush of data happens.
This is from my ssh client log for the dd command:
debug1: Sending command: dd if=/dev/zero bs=1048576 count=1 2>/dev/null
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug2: channel 0: window 1982464 sent adjust 114688
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype eow%openssh.com@localhost reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: chan_shutdown_read (i0 o0 sock -1 wfd 3 efd 7 [write])
debug2: channel 0: input open -> closed
...
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
And, this is your ssh client running the same dd command:
debug1: Sending command: dd if=/dev/zero bs=1m count=1 2>/dev/null
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug3: send packet: type 1
debug1: channel 0: free: client-session, nchannels 1
As you can see, my ssh xfers data until an `eof' (packet type 96)
is received. Your ssh server accepts the dd command, executes it;
then for some reason, the client sends a disconnect packet (type 1)
https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xml
and the connection is closed.
... but the system is consistently up and transferring data with no
downtime (it is in fact a firewall).
After observing the above last week, I was going to ask if there
was a firewall in the path somewhere. Now that you're confirmed
it, please check your firewall setup.
You can find out if it is the firewall which is interfering by
running nc(1) on port 22 on the server/firewall.
On the server (using a console--not via ssh):
1. Stop sshd first.
2. Run: dd if=/dev/zero bs=1m count=1 | nc -l 22
On the client machine:
1. Run: nc -dN ser.ver 22 > out.bin
-RVP