zitoss wrote: thought about spec symbols, but don't understand why so hardly escape password from this problem.
It is because of how the Total Commander and WinSCP process the password arguments. In the TC SFTP plugin I'm not really sure what causes the problem, but the latest version of libssh2.dll might be the solution. I can see you are from Russia, so you probably use a different encoding than the standard
ISO/IEC 8859-1 or
Windows-1252 (US and Western Europe). In the SSH Authentication specification (
IETF RFC 4252), section #8 it says :
Note that the 'plaintext password' value is encoded in ISO-10646
UTF-8. It is up to the server how to interpret the password and
validate it against the password database. However, if the client
reads the password in some other encoding (e.g., ISO 8859-1 - ISO
Latin1), it MUST convert the password to ISO-10646 UTF-8 before
transmitting, and the server MUST convert the password to the
encoding used on that system for passwords.
So, it might be that the SFTP plugin doesn't take care of the proper encoding before sending the password or you server uses different encoding to verify it (in a database for example). Try to change the encoding in your Windows to the CP-1252 or UTF-8 (which Windows should be using by default).
The "&" character 26th in the ASCII table, so there shouldn't be a problem with conversion between codepages, because only the second half of the ASCII table is different for the
code page 866 (Cyrillic). But again, we are talking about the conversion between ASCII and UTF-8 between two different systems, so there might some other issues.
As for the WinSCP, it uses the puTTY to start the session over the command line. When it passes the "-pw" argument without quotes, you get something like this :
Code: Select all
putty.exe user@server -pw hfW4aG3&
which means that the last "&" will be interpreted as "run putty.exe AND <other command>". So, you must use the "^&" in order to tell the command prompt that you actually want to use the "&" character and not the special AND operator. You should be able to see this in the
Process Explorer (by Sysinternals/Microsoft), in the command line arguments of the puTTY process launched by the WinSCP.
zitoss wrote:How I detect, that our server tools pass our passwords without escape or quotation marks. Quotation marks help to resolve this problem.
I don't know what is your setup, but I assume you use cygwin to run Bash scripts to connect to the remote server. Whenever you use $variable in a Bash script, you should surround it with double quotes, ex. "$variable". Read
this Bash quoting guide and
Bash documentation for more details. You should be able to see the arguments using the 'ps -auxf'. Also, you can simply "echo" the command you are launching, just be careful about how Bash escapes and processes double quotes when you use "echo". The
Bash special variable "$@" contains a list of arguments passed to the program. You can also use
Bash traps to see the last launched command.
I don't have a Windows machine currently available, but when I will be able to, I will install OpenSSH and try to reproduce this problem on my side. I hope I will be able to tell you more about the problem afterwards.
zitoss wrote:Thank you very much for links and helping at solution of problem.
I'm glad I could help.
EDIT #1:
I have created a test user on my Linux machine with password "test123$" and also "test123&"
On my PC with English Windows 7 the TC is version 8.51a. I have installed the
SFTP plugin (v1.4.1) from this website. And added the latest libssh2.dll (v1.4.3, the x64 version) and the libeay32.dll (v1.0.0.15, also x64 version). These DLLs come from
curl-7.39.0-devel-mingw64.
I was able to login without any problems using the WinSCP (v5.1.4) and also SFTP plugin with both passwords. I have also tried to change the encoding to Windows-1251 and CP-866 and it still worked. Please try it again with the same versions of the plugin and the DLLs. In the Total Commander you can see the connection log when you double click on next to the "DISCONNECT" button. In the WinSCP you can turn on "debug 1" under "Logging" in the settings when you create a new SCP session. By default WinSCP stores the log in the Windows %temp% directory. You should see there was is going wrong.
Because it works for me, I don't think anymore that the "&" is making trouble in the password exchange. I'm starting to think the problem can be on the server side. Make sure you are not banned and that you use the correct username/password. Also, consider using public key authentication for your SSH account, it is much safer.
Please also try to configure your
WinSCP to use puTTY instead. You can do that in the WinSCP Preferences->Integration->Applications. You have to
download the latest puTTY and select the first ("Remember sessions password and pass it to puTTY (SSH)") and the third option ("Automatically open new sessions in puTTY"). If you do this, you will be able to see putty.exe launched by winscp.exe.
My winscp.exe -> putty.exe command line looks like this (from the Process Explorer) :
Code: Select all
"C:\Programs\putty.exe" -pw test123& -load "WinSCP temporary session"
Here you can see that the "-pw" argument is not using quotes for the password and it is not causing problems.
So, in order to go forward with the investigation of this problem you should :
- First make sure you have a working login for the server and that you are able to connect at least using the puTTY
- Update your Total Commander, SFTP plugin, libeay32.dll and libssh2.dll, WinSCP and puTTY to the latest versions
- See the logs in the Total Commander and WinSCP
- Configure the WinSCP to use the puTTY and see the arguments which are used to start it
If you need a quick fix for this problem and your puTTY connection is working, use the
Tunnelling both in the WinSCP and the Total Commander.
EDIT #2: Added links 
