tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

[ARM32] rfc: scp/ssh corruption data bug



Hello.

After recent pmap.c related patches the sshd seems to be ok (it means
is worked without panic).
However the scp and later ssh on client side can't be worked properly
due to some corruption data on server side.

How to reproduce:
1. Start NetBSD-current/ARM on OMAP/H4.
2. Append new user, f.e. vsx0 with normal shell and password.
3. In shell start sshd like

    /usr/bin/sshd

4. On the host side start ssh client like

    ssh -v vsx0@<address of board>

That is should be ok

5. Find the big ( >~1Mb) file on host side.
6. Try to copy it to the board through scp

    scp -v <big file> vsx0@<address of board>:

You should get corruption of MAC or length of the packet after first
16-128kB transfered data

andy@FITFIESPPC176:~$ scp -v
/home/andy/Downloads/AdobeReader_enu-8.1.2-1.i486.rpm
vsx0%192.168.10.4@localhost:
Executing: program /usr/bin/ssh host 192.168.10.4, user vsx0, command
scp -v -t .
OpenSSH_4.6p1 Debian-5ubuntu0.5, OpenSSL 0.9.8e 23 Feb 2007
....
debug1: Next authentication method: keyboard-interactive
Received disconnect from 192.168.10.4: 2: Corrupted MAC on input.
lost connection

7. After action #6 try to restart ssh again. The error still
reproduced but for ssh as well

andy@FITFIESPPC176:~$ ssh -C -v 192.168.10.4 -l vsx0
OpenSSH_4.6p1 Debian-5ubuntu0.5, OpenSSL 0.9.8e 23 Feb 2007
debug1: Reading configuration data /home/andy/.ssh/config
debug1: Applying options for *
...
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
Received disconnect from 192.168.10.4: 2: Corrupted MAC on input.

andy@FITFIESPPC176:~$ ssh -C -v 192.168.10.4 -l vsx0
OpenSSH_4.6p1 Debian-5ubuntu0.5, OpenSSL 0.9.8e 23 Feb 2007
debug1: Reading configuration data /home/andy/.ssh/config
...
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
Received disconnect from 192.168.10.4: 2: Bad packet length 1611302054.

8. Note: interesting to see this bug in interface dependent manner. If
you try to connect to the sshd via localhost it will work ok.

-- 
With Best Regards,
Andy Shevchenko


Home | Main Index | Thread Index | Old Index