I tried several times, but WinSCP always displayed the same error message.
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 email@example.com Using username "nell". firstname.lastname@example.org'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 email@example.com:. firstname.lastname@example.org'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 email@example.com firstname.lastname@example.org'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 (
.login, etc.) which output text messages on login, intended to be read by humans (like
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
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
returned by the SFTP server. So I converted the decimal value I saw in the
error message I received, i.e.,
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
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
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
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
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
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 email@example.com'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 firstname.lastname@example.org email@example.com'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.