SFTP received message too long error

Received too large (1298752370 B) SFTP package. Max supported package size
is 1024000 B.

The error is typically caused by message printed from startup script (like
.profile). The message may start with "Micr".

Cannot initialize SFTP protocol. Is the host running a SFTP server?

I then tried PuTTY's psftp program, but it would just hang after I provided the password and I would have to hit Ctrl-C to abort the program.

C:\Program Files (x86)\PuTTY>psftp nell@192.168.0.72
Using username "nell".
nell@192.168.0.72's password:
^C
C:\Program Files (x86)\PuTTY>

So then I tried copying the file to the remote sysetm using a secure copy (SCP) program on a Linux system.

$ scp office_version.vbs nell@192.168.0.72:.
nell@192.168.0.72's password:
Microsoft Windows [Version 6.1.7601]
$

I tried a few times with the same results each time. I would see the "Microsoft Windows [Version 6.1.7601" message on the Linux system, but the file would never be transferred to the remote Microsoft Windows 7 system that was functioning as an SSH server. Version 6.1 is Windows 7; "Windows 7" is the name Microsoft used to market the operating system to consumers, but the internal version number corresponding to it is 6.1. The ".7601" at the end indicates that service pack 1 is installed for Windows 7 - see List of Microsoft Windows versions for a complete listing of the correspondence between the consumer friendly names and the editions of Microsoft Windows.

I next tried SFTP from the Linux system to the Windows system. I then saw "Received message too long 1298752370".

$ sftp nell@192.168.0.72
nell@192.168.0.72's password:
Received message too long 1298752370
$

The article noted that the numeric value returned in the "received message too long" error is the decimal representation of an ASCII string returned by the SFTP server. So I converted the decimal value I saw in the error message I received, i.e., 1298752370, to hexadecimal using the Calculator program that comes with Microsoft Windows by clicking on View then selecting Programmer, pasting the decimal value into Calculator, then clicking on the Hex radio button.

I converted the hexadecimal value 4D696372 to ASCII text using the online Hex to ASCII converter. Those 4 bytes equate to "Micr", i.e., the first four characters of "Microsoft Windows [Version 6.1.7601]".

While connected to the remote system via SSH, I moved the

.bashrc

file in the C:\Users\nell directory to .barshrc.save and then tried an SFTP connection again, but again I received the "Received message too long 1298752370" error mesage. I then moved the .bash_profile file to .bash_profile.save.

C:\users\nell>move .bash_profile .bash_profile.save
move .bash_profile .bash_profile.save
        1 file(s) moved.

C:\users\nell>

I hadn't expected renaming the files would resolve the problem, since I didn't see anything in either that would produce the "Microsoft Windows [Version 6.1.7601]" message, but I renamed them as a test, since I found postings online by people stating that statements in those files could lead to text being echoed to an SCP or SFTP client that would cause the problem. Since renaming the files didn't fix the problem, I renamed them again to the orginal file names.

When I checked the sshd_config file for CopSSH, which is in the etc subdirectory beneath the directory in which CopSSH was installed, I saw the following:

MaxSessions 10
Subsystem sftp internal-sftp -l ERROR

Match User owner
        PasswordAuthentication   yes
        PubkeyAuthentication   yes
        AllowTcpForwarding   yes
Match User nell
        ForceCommand   /cygdrive/c/windows/system32/cmd.exe
        PasswordAuthentication   yes
        PubkeyAuthentication   yes
	AllowTcpForwarding   yes

So I could see that C:\windows\system32\cmd.exe would be run upon an SSH/SFTP login. When you open a command prompt window on a Microsoft Windos 7, system, you will see the version number displayed:

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\Nell>

So I could tell that was the origin of the"Microsoft Windows [Version 6.1.7601]". For the user's account, CopSSH was configured with an "access type" of "Windows shell". However, it appeared that another account on the system, "owner", was configured for "Linux shell and sftp" access, since I didn't see the "ForceCommand /cygdrive/c/windows/system32/cmd.exe" for that account, so a login to the other account would not lead to a Windows command prompt and thus not produce the offending "Microsoft Windows [Version 6.1.7601]" message. So I tried logging into the other account with PuTTY and saw the following prompt:

login as: owner
owner@192.168.0.72's password:
Last login: Sun Aug 16 12:17:24 2015 from 192.168.3.10

owner@QueenBee ~
$

And when I tried transferring the file with SFTP using the sftp client program on the Linux system, I was able to transfer it using the account that was not configured to use a Windows shell.

$ sftp owner@192.168.0.72
owner@192.168.0.72's password:
Connected to 192.168.0.72.
sftp> put office_version.vbs
Uploading office_version.vbs to /cygdrive/c/users/owner/office_version.vbs
office_version.vbs                            100%  713     0.7KB/s   00:00
sftp>

And I was also able to use WinSCP to transfer files using that account, though afterwards I had to log into the account with the Windows shell access to run the VBScript file, office_version.vbs, I transferred and see its results displayed. The reason I had needed SFTP access to the system was so I could put that script there to remotely check on what version of Microsoft Office was on the Windows 7 system.