SFTP: "Please remove the write protection!"

[MarkFilipak]

I can't SFTP. Total Commander 7.04a + Christian's SFTP beta used to work.

MY CONFIGURATION NOW:
=================
Total Commander 7.55a + SFTP 1.0 final.
d:\totalcmd\plugins\wfx\sftpplug\libeay32.dll dated 2010-06-23.
d:\totalcmd\plugins\wfx\sftpplug\libssh2.dll dated 2010-08-18.
WinXP Pro SP3.

If I try to upload to my server I get an alert box titled "Error uploading file!" If I try to simply rename a file I get "Please remove the write protection!". Here is the log:
========================
Connecting to: www.xxxxxxxxxxx.com
IP address: 65.xxx.xxx.xxx:22
Server fingerprint:
DE xx xx xx xx xx xx xx xx xx xx xx xx xx xx C3
Supported authentication methods: publickey,gssapi-with-mic,password
Auth via public key for user: xxxxxxxxxxx
CONNECT \markfilipak on www.xxxxxxxxxxx.com
Get directory: \var\www\html
Get directory: \var\www\html\xp
Rename from: \var\www\html\xp\WinXP-SP3-Updates.zip
Rename to:\var\www\html\xp\WinXP-SP3-Updates.zip-
Rename FAILED: SFTP Protocol Error

A clue: SFTP via password using Tunnelier works, but of course I'd rather use Total Commander.

I could attack this with wireshark, but perhaps someone can save me the trouble (and the learning curve regarding SFTP protocol).

Thanks!
Mark.

[karlchen]

Hello, Mark.

Which beta version was the last that worked for you?
The reason for asking is that the last beta version, v0.98 dated 2010.05.19, and the current final version, v1.00 dated 2010.06.29, hold the same binary file sftpplug.wfx.
sftpplug.wfx 200.704 19.05.2010 12:02 -a--

I cannot remember ever having experienced the problems which you explain using sftplug.wlx v0.98. - But I will try out the final version 1.0 and report back.

Oh, by the way, the libcurl DLLs which I have been using during the past few months are:

[face=courier]libeay32.dll .. 1.546.364 23.06.2010 07:17 -a--
libssh2.dll ..... 176.640 23.06.2010 07:22 -a--
libssl32.dll .... 346.759 23.06.2010 07:17 -a--[/face]

To the best of my knowledge, this corresponds exactly to the version 7.21.0 specified on the T.C. File System Plugin webpage.
It seems as if you are using the libcurl DLLs v7.21.1. It brings along an updated version of the libssh2.dll:
libssh2.dll 179.200 18.08.2010 17:12 -a--
This may be relevant with respect to the problems which you experience. It may be not. - Cannot tell before having (re-)tested

1. the SFTP plugin v0.98 using libcurl v7.21.0
2. the SFTP plugin v0.98 using libcurl v7.21.1
3. the SFTP plugin v1.00 using libcurl v7.21.0
4. the SFTP plugin v1.00 using libcurl v7.21.1

Kind regards,
Karl
--
P.S.:
Just to avoid any potential confusion which I may have caused to any readers: libssl32.dll is not needed for SFTP, only for FTPS. It is present in the list of my libCurl.dll files, because I had tried out FTPS in the past.

[MarkFilipak]

Hi Karl!

I found curl 7.21.0 at http://www.gknw.de/mirror/curl/win32/

I will try it tonight (while you sleep there in Germany).

I'll post the results here.

Thanks! Mark.

PS: I don't know which beta of SFTPplugin I previously used. My previous installation was at least a year old. - M.

[karlchen]

Hello, Mark.

To cut the results of my tests short:

Testing environment:
+ Windows 2003 Std SP2, 32-bit (sorry, no XP SP3 available currently)
+ Total Commander 7.55a
+ SFTP plugin v1.0 (final)
+ libCurl DLLs v7.21.1

+ sFTP server: HP-UX 11.31 64-bit

+ SFTP connection settings in T.C.:
... servername:port
... (logon credentials specified interactively)
... compress data: off
... use SCP for data transfer: on (on or off irrelevant here)

Uploading files:
Works perfectly provided my HP-UX account has got rwx permissions on the target folder.
Else I will be told "Error uploading file!"

Renaming files:
Works perfectly provided my HP-UX account has got rwx permissions on the target folder.
Else I will be told "Please remove the write protection!"

Based on the tests which I have performed, the SFTP plugin v1.0 plus libCurl 7.21.1 works flawlessly for me.

So, as far as I can tell, the error messages which you receive:

If I try to upload to my server I get an alert box titled "Error uploading file!" If I try to simply rename a file I get "Please remove the write protection!".

might be caused by missing access privileges.

This would not explain, however, the error message about protocol errors. I have not received such error messages.

Kind regards,
Karl

[MarkFilipak]

It's so kind of you to help me, Karl. Thank you!

Here's 3 attempts to log in.
- Log-on as markfilipak with password succeeds but file rename fails with "SFTP Protocol Error".
- Log-on as markfilipak with key succeeds but file rename fails with "SFTP Protocol Error".
- Log-on as root with key succeeds and file rename succeeds.
- They all succeed using Tunnelier.
- Log-on to a friend's server using his root password succeeds and file rename succeeds.
- I don't think authentication is an issue.
- In all cases, the file attributes are 644.
- I don't think permissions is an issue.

Connect as markfilipak to www.xxxxxxxxxxx.com using password authentication:
========================
Connecting to: www.xxxxxxxxxxx.com
IP address: 65.xxx.xxx.xxx:22
Server fingerprint:
DE xx xx xx xx xx xx xx xx xx xx xx xx xx xx C3
Supported authentication methods: publickey,gssapi-with-mic,password
Authentication via password for user: markfilipak
CONNECT \markfilipak (password) on www.xxxxxxxxxxx.com
Get directory: \var\www\html
Get directory: \var\www\html\xp
Rename from: \var\www\html\xp\WinXP-SP3-Updates.zip
Rename to:\var\www\html\xp\WinXP-SP3-Updates.zip-
Rename FAILED: SFTP Protocol Error

Connect as markfilipak to www.xxxxxxxxxxx.com using key authentication:
========================
Connecting to: www.xxxxxxxxxxx.com
IP address: 65.xxx.xxx.xxx:22
Server fingerprint:
DE xx xx xx xx xx xx xx xx xx xx xx xx xx xx C3
Supported authentication methods: publickey,gssapi-with-mic,password
Auth via public key for user: markfilipak
CONNECT \markfilipak (key) on www.xxxxxxxxxxx.com
Get directory: \var\www\html
Get directory: \var\www\html\xp
Rename from: \var\www\html\xp\WinXP-SP3-Updates.zip
Rename to:\var\www\html\xp\WinXP-SP3-Updates.zip-
Rename FAILED: SFTP Protocol Error

Connect as root to www.xxxxxxxxxxx.com using key authentication:
========================
Connecting to: www.xxxxxxxxxxx.com
IP address: 65.xxx.xxx.xxx:22
Server fingerprint:
DE xx xx xx xx xx xx xx xx xx xx xx xx xx xx C3
Supported authentication methods: publickey,gssapi-with-mic,password
Auth via public key for user: root
CONNECT \root (key) on www.xxxxxxxxxxx.com
Get directory: \var\www\html
Get directory: \var\www\html\xp
Rename from: \var\www\html\xp\WinXP-SP3-Updates.zip
Rename to:\var\www\html\xp\WinXP-SP3-Updates.zip-
Get directory: \var\www\html\xp
Rename from: \var\www\html\xp\WinXP-SP3-Updates.zip-
Rename to:\var\www\html\xp\WinXP-SP3-Updates.zip
Get directory: \var\www\html\xp

Is it time to break out wireshark?

Thanks for your help. - Mark.

PS: I'm using ver 7.21.1 of libeay32.dll & libssh2.dll with TC 7.55a on WinXP-SP3.

[karlchen]

Hello, Mark.

I agree that if

• using SFTP client A you can perform uploads and renaming operations under your account
• using SFTP client B you fail to perform uploads and renaming operations under your account

then it is extremely unlikely that folder and file permissions can be the source of the problem.

Also the error message about SFTP protocol errors when using the T.C. SFTP plugin give a strong hint that the source must be something else.

As the T.C. SFTP plugin works fine for me on several different Windows machines, I start wondering whether the source of the trouble with the T.C. SFTP plugin may not be the presence of the Tunnelier software.

Maybe this software intercepts all SSH traffice in such a way that a second SFTP client like the T.C. plugin does not function properly any longer. This might be the case if you run Tunnelier as a service.

Yet, as I have not used Tunnelier myself so far, this is just an assumption based on the description on how Tunnelier can be used on their homepage.

Kind regards,
Karl

[MarkFilipak]

Once again, thanks for your patient help, Karl.

Your reasoning is sound but ill informed. Let me give you the details:
1 - Tunnelier is a simple application, not a service, and does not run any threads except while it is executing, so it cannot interfere except when it is executing.
2 - The SFTPplugin exhibits the problem when Tunnelier is NOT executing, and in fact it exhibits the problem immediately after a clean boot.

Clean boot: 1 application (notepad) & 34 processes running (including taskmon.exe & notepad.exe).
Launch TC: 2 applications (notepad & TC) & 35 processes running (including taskmon.exe, notepad.exe & TOTALCMD.EXE).
TC SFTP connect: (no change in running applications & processes).
TC rename remote file: Fails with "Please remove the write protection!" alert box & "Rename FAILED: SFTP Protocol Error" log entry (no change in running applications & processes).
TC SFTP disconnect: (no change in running applications & processes).
Quit TC: 1 application (notepad) & 34 processes running (including taskmon.exe & notepad.exe).

As you can see, TC SFTP using sftpplug fails after a clean boot. Now, regarding Tunnelier...

Launch Tunnelier: 2 applications (notepad & Tunnelier) & 35 processes running (including taskmon.exe, notepad.exe & Tunnelier.exe).
Tunnelier SFTP connect: (no change in running applications & processes).
Tunnelier rename remote file: Succeeds (no change in running applications & processes).
TC SFTP disconnect: (no change in running applications & processes).
Quit Tunnelier: 1 application (notepad) & 35 processes running (including taskmon.exe, notepad.exe & Tunnelier.exe).

As you can see, though Tunnelier does indeed leave itself in memory, it cannot be the source of this problem. Note that it is the same version of Tunnelier that I used back in the days when TC SFTP used to work (i.e., TC 7.04a & sftpplug beta).

-- TIME TO BREAK OUT WIRESHARK AND SEE WHAT'S ACTUALLY HAPPENING --
Launch wireshark, capture port 22.

TC: 59 total packets
- SFTP connect: 52 packets (call them TC1-52)
+ Rename remote file: 7 packets (call them TC53-59).

Tunnelier: 53 total packets
- SFTP connect: 45 packets (call them Tunnelier1-45)
+ Rename remote file: 8 packets (call them Tunnelier46-53).

Comparison of TC53-59 -vs- Tunnelier46-53:

Code: Select all

Type of packet .................................. TC ......................... Tunnelier

SSH encrypted client req. ....................... 53=(Seq: 3504, Ack: 9351) .. 46=(Seq: 2682, Ack: 3307)
SSH encrypted server resp. ...................... 54=(Seq: 9351, Ack: 3588) .. 47=(Seq: 3307, Ack: 2750)

TCP [ACK] unencrypted client resp. ........................................... 48=(Seq: 2750, Ack: 3343)

SSH encrypted client req. ....................... 55=(Seq: 3588, Ack: 9435) .. 49=(Seq: 2750, Ack: 3343)
SSH encrypted server resp. ...................... 56=(Seq: 9435, Ack: 3688) .. 50=(Seq: 3343, Ack: 2914)

TCP [ACK] unencrypted client resp. .............. 57=(Seq: 3688, Ack: 9519) ............................
SSH [TCP Retransmission] encrypted server resp. . 58=(Seq: 9435, Ack: 3688) ............................
TCP [TCP Dup ACK 57#1] unencrypted client resp. . 59=(Seq: 3688, Ack: 9519) ............................

SSH encrypted client req. .................................................... 51=(Seq: 2914, Ack: 3411)
SSH encrypted server resp. ................................................... 52=(Seq: 3411, Ack: 3030)
TCP [ACK] unencrypted client resp. ........................................... 53=(Seq: 3030, Ack: 3495)

How to interpret this?? I would guess that the client-req./server-resp. should proceed: dirlist, filename, newname.
The 1st succeeds for both but it looks like the 2nd from TC fails (perhaps because of the missing TCP [ACK]?).

As an experiment, in [Configuration > Operation] I unchecked "Select only the file name when renaming (not the extension)" and tried it again but that did not solve the problem.

I'm in pretty deep water here. I guess I could decrypt the message bodies - after all, I have all the keys - but as of now, I'm hoping that the wire captures above will cause the solution to jump out and bite someone knowledgeable.

Best Regards - Mark.

PS (update): I just re-ran the Tunnelier test to see if it's repeatable, and it looks like Tunnelier46-48 above were perhaps just a keep-alive. So the "missing" TCP [ACK] may not be related. Oh, well. I'm mystified.

PPS: I re-ran just the rename part of the TC test and got this (copied directly from wireshark with IP xxx'ing)

Code: Select all

No.     Time        Source                Destination           Protocol Info
      1 0.000000    172.xx.xxx.xxx        65.xxx.xxx.xxx        SSH      Encrypted request packet len=84

Frame 1 (138 bytes on wire, 138 bytes captured)
Ethernet II, Src: AskeyCom_59:ee:8a (00:90:96:59:ee:8a), Dst: Dell_fb:9d:0c (00:1d:09:fb:9d:0c)
Internet Protocol, Src: 172.xx.xxx.xxx (172.xx.xxx.xxx), Dst: 65.xxx.xxx.xxx (65.xxx.xxx.xxx)
Transmission Control Protocol, Src Port: pipes (1465), Dst Port: ssh (22), Seq: 1, Ack: 1, Len: 84
SSH Protocol

No.     Time        Source                Destination           Protocol Info
      2 0.556032    172.xx.xxx.xxx        65.xxx.xxx.xxx        SSH      [TCP Retransmission] Encrypted request packet len=84

Frame 2 (138 bytes on wire, 138 bytes captured)
Ethernet II, Src: AskeyCom_59:ee:8a (00:90:96:59:ee:8a), Dst: Dell_fb:9d:0c (00:1d:09:fb:9d:0c)
Internet Protocol, Src: 172.xx.xxx.xxx (172.xx.xxx.xxx), Dst: 65.xxx.xxx.xxx (65.xxx.xxx.xxx)
Transmission Control Protocol, Src Port: pipes (1465), Dst Port: ssh (22), Seq: 1, Ack: 1, Len: 84
SSH Protocol

No.     Time        Source                Destination           Protocol Info
      3 0.611363    65.xxx.xxx.xxx        172.xx.xxx.xxx        TCP      ssh > pipes [ACK] Seq=85 Ack=85 Win=11760 Len=0 SLE=1 SRE=85

Frame 3 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: Dell_fb:9d:0c (00:1d:09:fb:9d:0c), Dst: AskeyCom_59:ee:8a (00:90:96:59:ee:8a)
Internet Protocol, Src: 65.xxx.xxx.xxx (65.xxx.xxx.xxx), Dst: 172.xx.xxx.xxx (172.xx.xxx.xxx)
Transmission Control Protocol, Src Port: ssh (22), Dst Port: pipes (1465), Seq: 85, Ack: 85, Len: 0

No.     Time        Source                Destination           Protocol Info
      4 0.879305    65.xxx.xxx.xxx        172.xx.xxx.xxx        SSH      [TCP Retransmission] Encrypted response packet len=84

Frame 4 (138 bytes on wire, 138 bytes captured)
Ethernet II, Src: Dell_fb:9d:0c (00:1d:09:fb:9d:0c), Dst: AskeyCom_59:ee:8a (00:90:96:59:ee:8a)
Internet Protocol, Src: 65.xxx.xxx.xxx (65.xxx.xxx.xxx), Dst: 172.xx.xxx.xxx (172.xx.xxx.xxx)
Transmission Control Protocol, Src Port: ssh (22), Dst Port: pipes (1465), Seq: 1, Ack: 85, Len: 84
SSH Protocol

No.     Time        Source                Destination           Protocol Info
      5 0.880415    172.xx.xxx.xxx        65.xxx.xxx.xxx        SSH      Encrypted request packet len=100

Frame 5 (154 bytes on wire, 154 bytes captured)
Ethernet II, Src: AskeyCom_59:ee:8a (00:90:96:59:ee:8a), Dst: Dell_fb:9d:0c (00:1d:09:fb:9d:0c)
Internet Protocol, Src: 172.xx.xxx.xxx (172.xx.xxx.xxx), Dst: 65.xxx.xxx.xxx (65.xxx.xxx.xxx)
Transmission Control Protocol, Src Port: pipes (1465), Dst Port: ssh (22), Seq: 85, Ack: 85, Len: 100
SSH Protocol

No.     Time        Source                Destination           Protocol Info
      6 1.151629    65.xxx.xxx.xxx        172.xx.xxx.xxx        TCP      ssh > pipes [ACK] Seq=85 Ack=185 Win=11760 Len=0

Frame 6 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Dell_fb:9d:0c (00:1d:09:fb:9d:0c), Dst: AskeyCom_59:ee:8a (00:90:96:59:ee:8a)
Internet Protocol, Src: 65.xxx.xxx.xxx (65.xxx.xxx.xxx), Dst: 172.xx.xxx.xxx (172.xx.xxx.xxx)
Transmission Control Protocol, Src Port: ssh (22), Dst Port: pipes (1465), Seq: 85, Ack: 185, Len: 0

No.     Time        Source                Destination           Protocol Info
      7 1.152039    65.xxx.xxx.xxx        172.xx.xxx.xxx        SSH      Encrypted response packet len=84

Frame 7 (138 bytes on wire, 138 bytes captured)
Ethernet II, Src: Dell_fb:9d:0c (00:1d:09:fb:9d:0c), Dst: AskeyCom_59:ee:8a (00:90:96:59:ee:8a)
Internet Protocol, Src: 65.xxx.xxx.xxx (65.xxx.xxx.xxx), Dst: 172.xx.xxx.xxx (172.xx.xxx.xxx)
Transmission Control Protocol, Src Port: ssh (22), Dst Port: pipes (1465), Seq: 85, Ack: 185, Len: 84
SSH Protocol

No.     Time        Source                Destination           Protocol Info
      8 1.431232    172.xx.xxx.xxx        65.xxx.xxx.xxx        TCP      pipes > ssh [ACK] Seq=185 Ack=169 Win=16396 Len=0

Frame 8 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: AskeyCom_59:ee:8a (00:90:96:59:ee:8a), Dst: Dell_fb:9d:0c (00:1d:09:fb:9d:0c)
Internet Protocol, Src: 172.xx.xxx.xxx (172.xx.xxx.xxx), Dst: 65.xxx.xxx.xxx (65.xxx.xxx.xxx)
Transmission Control Protocol, Src Port: pipes (1465), Dst Port: ssh (22), Seq: 185, Ack: 169, Len: 0

I don't pretend to understand any of this... (the TC SFTP rename failed of course). - M.

[karlchen]

Hi, Mark.

I just read that Tunnelier can be run as a service. nd I thought maybe you do this and Tunnelier intercepts all the SSH traffic. - This is not the case. - Hypothesis proven wrong.

Result:
Now I am clueless, because I have not experienced the problem so far and cannot reproduce it.

I wonder whether the operating system of theSFTP server machine and(or the version of the SSH daemon on that server machine might play a role. - I can only test towards different HP-UX servers, all running 64-bit versions of HP-UX 11.11, 11.23 or 11.31.

As far as your Wireshark logfles are concerned: I will happily leave the interpretation to some network experts.

Kind regards,
Karl
--
Over and out for the moment, reason see above.

[karlchen]

Hello, Mark.

I would like to come back to the hypothesis explained in a previous post:
The error messages are caused by insufficient access privileges.

Why do I return to this hypothesis? Because on RHEL5.5 (Redhat Linux Enterprise 5.5) the error messages "Error uploading file!" and "Please remove the write protection!" will be followed by the error message "SFTP Protocol Error."

Hypothesis #2:
Unknowlingly you might be using saved logon credentials in Tunnelier for an account who has got the required privileges to perform the upload and rename operations.
Unknowlingly you might be using saved logon credentials with the T.C. SFTP plugin for a different account who has not got the required privileges to perform the upload and the rename operations.

Your target machine is a Linux Redhat machine. Et voilà, you will receive the error messages which I received, too, when I tried to upload to a folder where I had not write permissions, and when I tried to rename a file in a folder where I had got no write permissions.

Kind regards,
Karl
--
Over and out again, as this is the last non-network-technical hypothesis.

[MarkFilipak]

Karl, you're a genius.

I came back here to write that I solved the problem and discovered your latest message. Of course you are right.

I feel so embarrassed!!

Sure, the markfilipak pubkey is found in /root/.ssh/authorized_keys, but that doesn't give user=markfilipak write privilege to /var/www/html. Only user=root has write privilege there. Duh!

I logged in as user=root with TC+sftpplug and all was joy. Of course, with Tunnelier I was always user=root, so it worked.

What shall we do with this thread? Is there a way to kill it so that other people won't see how stupid I can be?

Thanks, Karl. Sorry I wasted your time - Mark.

[karlchen]

Hello, Mark.

Glad to learn you have found the source of your problem and the solution.
Who of us has not overlooked the most obvious solution for a long time? If I remember right it was last on my list as well.

"genius": It will not be hard to find a lot of people who will absolutely disagree full-heartedly.
kill the thread: This can only be done by the moderators and the site admin.

Kind regards,
Karl