Re: Strange ssh hangups, netbsd-9 GENERIC

[Louis Guillaume <louis%zabrico.com@localhost>]

On 3/12/21 8:38 AM, RVP wrote:
> On Fri, 12 Mar 2021, Louis Guillaume wrote:
>
> > OpenSSH_8.0 NetBSD_Secure_Shell-20190418-hpn13v14-lpk, OpenSSL 1.1.1g 
> > 21 Apr 2020
>
> Is this the server or the client? Can you post both?
>
> > > ssh -vvv user%ser.ver@localhost 'dd if=/dev/zero bs=1m count=1 2>/dev/null'  
> > > >out.bin 2>ssh.log.txt
> >
> > Actually out.bin is 0b after running that - but it doesn't surprise 
> > me. Would it actually send text to stdout for each \0 returned by dd? 
> > Seems like it would basically be an empty string. The stderr is below. 
> > Thanks for looking!
>
> You should get a 1MB file if /dev/zero exists, and is readable on
> the server (and the dd on the server understands `bs=1m'):
>
> $ ssh -vvv u%s.loc@localhost 'dd if=/dev/zero bs=1048576 count=1 2>/dev/null' 
>  >out.bin 2>ssh.log.txt
> $ ls -l
> total 1036
> -rw-------  1 rvp  wheel  1048576 Mar 12 13:15 out.bin
> -rw-------  1 rvp  wheel    11282 Mar 12 13:15 ssh.log.txt
> $ hexdump -C out.bin
> 00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
> |................|
> *
> 00100000
> $

Yes - it's not writing any data through the socket after some 
non-specific number of bytes. So the output of this is just empty.


> > OpenSSH_8.1p1, LibreSSL 2.7.3
>
> What OS & client is this? Can you try a different client?

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]

> > debug1: Exit status -1
>
> The client is not exiting cleanly. It should--even if there
> is a command execution error on the server.
>
>
> -RVP


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.

Here's the interface in case that helps.


wm1: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        capabilities=7ff80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
        capabilities=7ff80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx>
        capabilities=7ff80<TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6>
        enabled=0
        ec_capabilities=17<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,EEE>
        ec_enabled=2<VLAN_HWTAGGING>
        address: 02:00:e8:16:41:15
        media: Ethernet autoselect (1000baseT full-duplex)
        status: active
        inet 192.168.1.2/24 broadcast 192.168.1.255 flags 0x0
        inet6 fe80::e8ff:fe16:4115%wm1/64 flags 0x0 scopeid 0x2



--
Louis