Hello. I confirm the existence of an identical problem for 6.6 from my side and for sftp(1) sessions as also.
On Fri, Nov 22, 2019 at 12:08:16PM +0100, [email protected] wrote: > Am 22.11.19 um 07:14 schrieb Darren Tucker: > > It's not a bug in scp. It's possible that it's a bug in OpenSSH or > > OpenBSD but unlikely. > > > > The message means that the data was changed in transit between client > > and server causing SSH's integrity check to fail. A large number of > > things have been found over the years to be causes of this, including > > faulty/buggy network equipment, ram, ethernet interfaces and network > > drivers. Many of the known causes are listed here: > > https://bugzilla.mindrot.org/show_bug.cgi?id=845 > > I'm a little bit helpless now. > > My test-setup today was: > A real (BSD-)PC with 6.6 and my try to copy resulted in the same error. > Then I went to our outpost and connected this PC on the same switch as the > firewall and copied over 30 times without any error. > A copy from our controller (6.6) to the second PC failed, too. > So in my opinion the problem must be a combination from something „on the > way“ and the 6.6er installation :-( > > I tried once more to copy from a 6.4 BSD to the firewall and got no error. > Do you have any idea, what could have changed between 6.4 and 6.5!? Or how > can I ship around this error? I had a look at the scp-logfile from a (6.4er) > working copy and saw no great differences between this and the error-logfile > :-( On the mindrot-page was a paragraph about a specific cipher, that caused > the problem at his setup. Do you think, this could be my problem, too? Or > what could I else do? > > Of course, I could copy my files on another way, like http(s), but it has a > negative smack, because you know, something is now not working, what was > running in a earlier release and over 2 years without a problem. And you > don't know, if this problem causes other failures :-( > > > > /usr/sbin/sshd -ddd -p 50 -E sshd.debug.4.log > > > > If you add "-e" to the command line you'll get more information from > > after when sshd re-execs itself. > > Same output with „-e“ as without :-( > > > > The controller is a virtual machine on ESXi. > > > > This is the first variable I'd try removing if possible. There have > > been other cases of VMWare networking causing problems (although not > > these symptoms): > > https://marc.info/?l=openssh-unix-dev&m=153535111501535&w=2 > > Yes I tried, same problem with a real PC. > > > from the dmesg: > > > em0 at pci2 dev 0 function 0 "Intel 82545EM" rev 0x01: > > > > Alternatively, I'd try switch the network interface to vio from em. > > That's unfortunately not possible, the firewall is like a appliance with two > build-in nics and no room for extensions. > > Thank you for your help and kind regards, > Illya Meyer
