Re: scp -r incompatibility between -current and NetBSD releases

[Robert Elz <kre%munnari.OZ.AU@localhost>]

I am having a similar problem (though with ssh, rather than scp).

I have long had a setup where I run tunnels over ssh (in both
directions) between munnari.oz.au and me at home.  The latter
(me@home) has a new 9.99.97 system in the process of being installed.

I have a pseudo-host "work" (not a particularly sane name really)
in /etc/ssh/sse_config which is defined to set up the necessary
tunnels.   If I do "ssh work" it all works as expected (using public
key authentication).   My normal setup does "ssh -N 
-n work" in a
moderately complex sh loop which keeps things running when my home ISP
decides it is time to remake the world and change all my external IP
addresses, causing current TCP connections to fail).   That also keeps
track of what public IP addresses I am using and tells me (just in case
it matters) and when all this happens.   That (using "ssh -N -n work") is
no longer working - the tunnels get made locally, and I can make a
connection to the local endpoint, but nothing gets passed to the remote
end (nor from it - I suspect that it never sees the attempted connection
at all).   And just to repeat, if I don't use the -n -N flags, it does all
work (but runs in foreground and wastes an xterm ... sure a very small one,
but...)

This used to work fine on my NetBSD 8'ish (an early 8.99.x) userland,
the script which is running it is identical (all I needed to fix was
send updated public keys, using a different algorithm - seems like the
old dsa is no longer supported, but that's a trivial issue, and handled).

Anyone have any clues on that?

kre

ps: I'm using the same version as wiz:

   OpenSSH_9.0 NetBSD_Secure_Shell-20220415-hpn13v14-lpk, OpenSSL 1.1.1n  15 Mar 2022

from NetBSD sources (HEAD) from June 7th.