SFTP received message too long error

I was able to log into a Microsoft Windows 7 system running CopSSH via Secure Shell (SSH) using PuTTY, but when I attempted to transfer a file to the system via the SSH File Transfer Protocol (SFTP) using WinSCP, I received the error message below:

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?

oreilly.com - Your tech ebook super store

I tried several times, but WinSCP always displayed the same error message.

WinSCP received too large error

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@
Using username "nell".
nell@'s password:
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@
nell@'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@
nell@'s password:
Received message too long 1298752370

During some online searching regarding the problem, I found When I try to use sftp or scp2, I get a message like this: Received message too long (or "Bad packet length") 1416586337 that explained the issue noting:

In order for this to work, the SSH session must be "clean" — that is, it must have on it only information transmitted by the programs at either end. What often happens, though, is that there are statements in either the system or per-user shell startup files on the server (.bashrc, .profile, /etc/csh.cshrc, .login, etc.) which output text messages on login, intended to be read by humans (like fortune, echo "Hi there!", etc.). Such code should only produce output on interactive logins, when there is a tty attached to standard input. If it does not make this test, it will insert these text messages where they don't belong: in this case, polluting the protocol stream between scp2/sftp and sftp-server. The first four bytes of the text gets interpreted as a 32-bit packet length, which will usually be a wildly large number, provoking the error message above.

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.

Decimal: 1298752370
Hexadecimal: 4D696372

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.


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:

Acronis 125x125
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.


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@'s password:
Last login: Sun Aug 16 12:17:24 2015 from

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.

1&1 Web Hosting
$ sftp owner@
owner@'s password:
Connected to
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

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.


TechRabbit ad 300x250 newegg.com

Justdeals Daily Electronics Deals1x1 px