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
