can you prevent SFTP client from using chmod?

[MarioL]

Hi, I'm using TCP/IP 5.6 eco 2 on OpenVMS 8.2

The SFTP server that I connect to from this VMS server is configured to deny chmod usage.

sftp> put testfile.txt

chmod_dest_before_transfer: ./testfile.txt (dst): permission denied (server msg: 'Permission denied')

testfile.txt

| 3.3kB |   3.3 kB/s | TOC: 00:00:01 | 100%

sftp> exit

The file does transfer, but I get that warning message.

When I use SCP to put the file, it looks like this:

tcpip$ssh_scp2.exe: warning: chmod_dest_before_transfer: ./testfile.txt (dst): permission denied (server msg: 'Permission denied')

testfile.txt                   | 3.3kB |   3.3 kB/s | TOC: 00:00:01 |

100%

%TCPIP-E-SSH_FC_ERR_PERM, no permission to access file

Is there some way to make the sftp client not try to chmod the file?

Any help would be appreciated.

[MarkOfAus]

Hello,

I am not sure what you specifically mean:

The SFTP server that I connect to from this VMS server is configured to deny chmod usage.

And then:

Is there some way to make the sftp client not try to chmod the file?

How can the client chown within ssh? As far as I am aware, the server controls the ownership and there is no facility for the client to do anything. This is counter-intuitive.

Perhaps you could show the entire command process, including throwing in a couple of -vvv on the command line to get a lot of information.

I would suggest, however, that permissions to the directory you are sftp-ing to are invalid.

Perhaps you could show your sshd_config settings for this particular user/group?

Also, showing more information that doesn't logically conflict. Stating:

The file does transfer, but I get that warning message.

When it clearly shows it fails doesn't help.

Cheers

Mark

[MarioL]

Hi Mark,  thank you for your reply.

here is the whole thing using the SFTP command:

ALADN2> sftp eald01@sftpserver
Access to this system is restricted to authorised users ONLY.
Unauthorised users may be subject to criminal or civil prosecution
under the laws of New Zealand or under the laws of the country from which
unauthorised access took place
sftp> ls -l
drwxrwx---    2 1525     1525         4096 Apr 29 04:36 transfers
sftp> put testfile.txt
chmod_dest_before_transfer: ./testfile.txt (dst): permission denied (server msg: 'Permission denied')
testfile.txt                                                                          |  3.3kB |   3.3 kB/s | TOC: 00:00:01 | 100%
sftp> ls -l
drwxrwx---    2 1525     1525         4096 Apr 29 04:36 transfers
-rw-r--r--    1 1525     1525         3405 May 13 23:08 testfile.txt
sftp> rm testfile.txt
sftp> exit

same thing using the SCP command

ALADN2> scp testfile.txt eald01@sftpserver:
Access to this system is restricted to authorised users ONLY.
Unauthorised users may be subject to criminal or civil prosecution
under the laws of New Zealand or under the laws of the country from which
unauthorised access took place
tcpip$ssh_scp2.exe: warning: chmod_dest_before_transfer: ./testfile.txt (dst): permission denied (server msg: 'Permission denied')
testfile.txt                    |  3.3kB |   3.3 kB/s | TOC: 00:00:01 | 100%


%TCPIP-E-SSH_FC_ERR_PERM, no permission to access file
ALADN2> sftp eald01@sftpserver
Access to this system is restricted to authorised users ONLY.
Unauthorised users may be subject to criminal or civil prosecution
under the laws of New Zealand or under the laws of the country from which
unauthorised access took place
sftp> ls -l
drwxrwx---    2 1525     1525         4096 Apr 29 04:36 transfers
-rw-r--r--    1 1525     1525         3405 May 13 23:12 testfile.txt
sftp> rm testfile.txt
sftp> exit

as you can see the file does transfer, but it gives those warning/error messages.

The client isn't using chown to change the owner of the file, but it does appear to try and use chmod to change file permissions.

I'll do the SCP command again using -v option

ALADN2> scp "-v" testfile.txt eald01@sftpserver:
tcpip$ssh_scp2.exe:Scp2/SCP2.C:1984: CRTL version (SYS$SHARE:DECC$SHARE ident) is: V8.2-00
tcpip$ssh_scp2.exe:Scp2/SCP2.C:2018: unable to get window size parameters.
tcpip$ssh_scp2.exe:SshAppCommon/SSHAPPCOMMON.C:313: Allocating global SshRegex context.
tcpip$ssh_scp2.exe:Scp2/SCP2.C:794: Received error "SSH_FC_OK"., msg: Globbing successful.
tcpip$ssh_scp2.exe:Scp2/SCP2.C:877: Starting transfer...
tcpip$ssh_scp2.exe:/LIBROOT/tech/ml/testfile.txt
tcpip$ssh_scp2.exe:SshFCTransfer/SSHFC_TRANSFER.C:2463: File list has 2 files.
tcpip$ssh_scp2.exe:SshFCTransfer/SSHFC_TRANSFER.C:301: Establishing source connection.
tcpip$ssh_scp2.exe:SshFileCopy/SSHFILECOPY.C:1062: Making local connection.
tcpip$ssh_scp2.exe:Ssh2SftpServer/SSHFILEXFERS.C:2074: Received SSH_FXP_INIT
tcpip$ssh_scp2.exe:Ssh2SftpServer/SSHFILEXFERS.C:2119: version is 999
tcpip$ssh_scp2.exe:Ssh2SftpServer/SSHFILEXFERS.C:2181: Sending SSH_FXP_VERSION with sftp-version@openvms.hp.com as 3
tcpip$ssh_scp2.exe:SshFileXferClient/SSHFILEXFERC.C:1432: ssh_file_client_receive_proc: coming in with extension data, OpenVMS host
tcpip$ssh_scp2.exe:SshFileXferClient/SSHFILEXFERC.C:1478: vms_plus_sftp_version = 3
tcpip$ssh_scp2.exe:SshFileCopy/SSHFILECOPY.C:1001: Connection to local, ready to serve requests.
tcpip$ssh_scp2.exe:SshFCTransfer/SSHFC_TRANSFER.C:323: Establishing destination connection.
tcpip$ssh_scp2.exe:SshFileCopy/SSHFILECOPY.C:1072: Connecting to remote host. (host = sftpserver, user = eald01, port = NULL)
tcpip$ssh_scp2.exe:Scp2/SCP2.C:2669: argv[0] = /sys$system/tcpip$ssh_ssh2
tcpip$ssh_scp2.exe:Scp2/SCP2.C:2669: argv[1] = -l
tcpip$ssh_scp2.exe:Scp2/SCP2.C:2669: argv[2] = eald01
tcpip$ssh_scp2.exe:Scp2/SCP2.C:2669: argv[3] = -v
tcpip$ssh_scp2.exe:Scp2/SCP2.C:2669: argv[4] = -x
tcpip$ssh_scp2.exe:Scp2/SCP2.C:2669: argv[5] = -a
tcpip$ssh_scp2.exe:Scp2/SCP2.C:2669: argv[6] = -o
tcpip$ssh_scp2.exe:Scp2/SCP2.C:2669: argv[7] = clearallforwardings yes
tcpip$ssh_scp2.exe:Scp2/SCP2.C:2669: argv[8] = -o
tcpip$ssh_scp2.exe:Scp2/SCP2.C:2669: argv[9] = passwordprompt %U@%H's password: 
tcpip$ssh_scp2.exe:Scp2/SCP2.C:2669: argv[10] = -o
tcpip$ssh_scp2.exe:Scp2/SCP2.C:2669: argv[11] = nodelay yes
tcpip$ssh_scp2.exe:Scp2/SCP2.C:2669: argv[12] = -o
tcpip$ssh_scp2.exe:Scp2/SCP2.C:2669: argv[13] = authenticationnotify yes
tcpip$ssh_scp2.exe:Scp2/SCP2.C:2669: argv[14] = sftpserver
tcpip$ssh_scp2.exe:Scp2/SCP2.C:2669: argv[15] = -s
tcpip$ssh_scp2.exe:Scp2/SCP2.C:2669: argv[16] = sftp
debug: Connecting to sftpserver, port 22... (SOCKS not used)
debug: Ssh2/SSH2.C:2861: Entering event loop.
debug: Ssh2Client/SSHCLIENT.C:1609: Creating transport protocol.
debug: SshAuthMethodClient/SSHAUTHMETHODC.C:104: Added "publickey" to usable methods.
debug: SshAuthMethodClient/SSHAUTHMETHODC.C:104: Added "keyboard-interactive" to usable methods.
debug: SshAuthMethodClient/SSHAUTHMETHODC.C:104: Added "password" to usable methods.
debug: Ssh2Client/SSHCLIENT.C:1650: Creating userauth protocol.
debug: client supports 3 auth methods: 'publickey,keyboard-interactive,password'
debug: SshUnixTcp/SSHUNIXTCP.C:1390: using local hostname aladn2.VMS.WESTPAC.CO.NZ
debug: Ssh2Common/SSHCOMMON.C:541: local ip = 10.234.160.150, local port = 55944
debug: Ssh2Common/SSHCOMMON.C:543: remote ip = 10.234.178.17, remote port = 22
debug: SshConnection/SSHCONN.C:2311: Wrapping...
debug: SshReadLine/SSHREADLINE.C:3662: Initializing ReadLine...
debug: Remote version: SSH-2.0-OpenSSH_3.6.1p2
debug: OpenSSH: Major: 3 Minor: 6 Revision: 1
debug: Ssh2Transport/TRCOMMON.C:1817: All versions of OpenSSH handle kex guesses incorrectly.
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 20 to connection
debug: Ssh2Transport/TRCOMMON.C:2306: lang s to c: `', lang c to s: `'
debug: Ssh2Transport/TRCOMMON.C:2371: c_to_s: cipher aes128-cbc, mac hmac-sha1, compression none
debug: Ssh2Transport/TRCOMMON.C:2374: s_to_c: cipher aes128-cbc, mac hmac-sha1, compression none
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 30 to connection
debug: Remote host key found from database.
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 21 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 5 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 50 to connection
debug: Ssh2Common/SSHCOMMON.C:342: Received SSH_CROSS_STARTUP packet from connection protocol.
debug: Ssh2Common/SSHCOMMON.C:392: Received SSH_CROSS_ALGORITHMS packet from connection protocol.
Access to this system is restricted to authorised users ONLY.
Unauthorised users may be subject to criminal or civil prosecution
under the laws of New Zealand or under the laws of the country from which
unauthorised access took place

debug: server offers auth methods 'publickey'.
debug: Ssh2AuthPubKeyClient/AUTHC-PUBKEY.C:1677: adding keyfile "/LIBROOT/tech/ssh2/ID_DSA_2048_B" to candidates
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 50 to connection
Forced command: /usr/libexec/openssh/sftp-server
debug: Constructing and sending signature in publickey authentication.
debug: Ssh2AuthPubKeyClient/AUTHC-PUBKEY.C:869: ssh_client_auth_pubkey_send_signature: reading /LIBROOT/tech/ssh2/ID_DSA_2048_B
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 50 to connection
Forced command: /usr/libexec/openssh/sftp-server
debug: Ssh2AuthPubKeyClient/AUTHC-PUBKEY.C:1915: Public key authentication was successful.
debug: Ssh2Common/SSHCOMMON.C:310: Received SSH_CROSS_AUTHENTICATED packet from connection protocol.
debug: SshReadLine/SSHREADLINE.C:3728: Uninitializing ReadLine...
debug: Ssh2Common/SSHCOMMON.C:852: num_channels now 1
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 90 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 98 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 94 to connection
tcpip$ssh_scp2.exe:SshFileCopy/SSHFILECOPY.C:1001: Connection to remote host 'sftpserver', ready to serve requests.
tcpip$ssh_scp2.exe:SshFCTransfer/SSHFC_TRANSFER.C:396: Source file is "raw", and it needs to be parsed.
tcpip$ssh_scp2.exe:Ssh2SftpServer/SSHFILEXFERS.C:3189: Received SSH_FXP_STAT
tcpip$ssh_scp2.exe:Ssh2SftpServer/SSHFILEXFERS.C:3264: Statting file `/LIBROOT/tech/ml/testfile.txt'
tcpip$ssh_scp2.exe:SshFCTransfer/SSHFC_TRANSFER.C:561: Next source file is /LIBROOT/tech/ml/testfile.txt .
tcpip$ssh_scp2.exe:Ssh2SftpServer/SSHFILEXFERS.C:3189: Received SSH_FXP_STAT
tcpip$ssh_scp2.exe:Ssh2SftpServer/SSHFILEXFERS.C:3264: Statting file `/LIBROOT/tech/ml/testfile.txt'
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 94 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 94 to connection
tcpip$ssh_scp2.exe:SshFCTransfer/SSHFC_TRANSFER.C:215: Received error `No such file' (2).
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 94 to connection
tcpip$ssh_scp2.exe:Ssh2SftpServer/SSHFILEXFERS.C:2235: Received SSH_FXP_OPEN
tcpip$ssh_scp2.exe:Ssh2SftpServer/SSHFILEXFERS.C:2329: Downloading `/LIBROOT/tech/ml/testfile.txt'
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 94 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 94 to connection
tcpip$ssh_scp2.exe:SshFCTransfer/SSHFC_TRANSFER.C:215: Received error `Permission denied' (3).
tcpip$ssh_scp2.exe:Scp2/SCP2.C:1161: Received error SSH_FC_ERROR_PERMISSION_DENIED.
tcpip$ssh_scp2.exe: warning: chmod_dest_before_transfer: ./testfile.txt (dst): permission denied (server msg: 'Permission denied')
tcpip$ssh_scp2.exe:SshFCTransferCore/SSHFC_TRCORE.C:357: Starting transfer for file testfile.txt, destination ./testfile.txt
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 94 to connection
testfile.txt                    |  3.3kB |   3.3 kB/s | TOC: 00:00:01 | 100%
tcpip$ssh_scp2.exe:SshFCTransferCore/SSHFC_TRCORE.C:851: Writer finished.
tcpip$ssh_scp2.exe:SshFCTransfer/SSHFC_TRANSFER.C:1943: Destination file attributes not available or that file is not a regular fil.
tcpip$ssh_scp2.exe:SshFCTransfer/SSHFC_TRANSFER.C:2036: Finished with file ./testfile.txt.
debug: Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
tcpip$ssh_scp2.exe:Ssh2SftpServer/SSHFILEXFERS.C:2903: Received SSH_FXP_CLOSE
tcpip$ssh_scp2.exe:Ssh2SftpServer/SSHFILEXFERS.C:3007: Closed file `/LIBROOT/tech/ml/testfile.txt' (handle=728be5)
tcpip$ssh_scp2.exe:Scp2/SCP2.C:1118: Received error SSH_FC_OK, error message .

tcpip$ssh_scp2.exe:Scp2/SCP2.C:1295: Transfer ready
tcpip$ssh_scp2.exe:ssh_pipe_stream_destroy
tcpip$ssh_scp2.exe:SshAppCommon/SSHAPPCOMMON.C:326: Freeing global SshRegex context.


%TCPIP-E-SSH_FC_ERR_PERM, no permission to access file
ALADN2> sftp eald01@sftpserver
Access to this system is restricted to authorised users ONLY.
Unauthorised users may be subject to criminal or civil prosecution
under the laws of New Zealand or under the laws of the country from which
unauthorised access took place
sftp> ls -l
drwxrwx---    2 1525     1525         4096 Apr 29 04:36 transfers
-rw-r--r--    1 1525     1525         3405 May 13 23:22 testfile.txt
sftp> rm testfile.txt
sftp> exit

re: sshd_config setting.  Is that the config file for the remote sftp server?  I don't have access to that.

Cheers,

Mario

[Hoff]

Try again with a current version of sftp or at least a current ECO for the old version you're using — your transfer is pretty clearly picking up a . as a filename (from somewhere), and that's probably the trigger for the error.  

If you're on V8.anything, there's little reason not to go to V8.4 with current UPDATE and required patches, and with current TCP/IP Services and patches, if you have licenses for that.

[Steven Schweda]

> How can the client chown within ssh? [...]

   What's to stop it?  If I do an interactive ssh cession, I can
certainly send a chmod command.  Why should an scp or sftp client have
any trouble sending one?


> [...] your transfer is pretty clearly picking up a . as a filename
> (from somewhere), [...]

   Eh?  Where do you see that?


> Hi, I'm using TCP/IP 5.6 eco 2 on OpenVMS 8.2

> Try again with a current version of sftp or at least a current ECO for
> the old version you're using [...]

   That might be good advice.  I certainly have a newer ECO for that
TCPIP version around here:

  HP TCP/IP Services for OpenVMS Alpha Version V5.6 - ECO 5
  on a COMPAQ Professional Workstation XP1000 running OpenVMS V8.3    

alp $ ssh -"V"
alp$dkc0:[sys0.syscommon.][sysexe]tcpip$ssh_ssh2.exe: SSH Secure ShellOpenVMS (
V5.5) 3.2.0 on COMPAQ Professional Workstation  - VMS V8.3

So my stuff is newer than yours (and the line numbers in my "-v"
diagnostic messages are different).

   Do we know what the software on the remote server is?

   Can you get the same warning if you transfer the file to the VMS
system itself instead of to the (mysterious) "sftpserver"?  I don't see
a chmod warning on my system when I do that, but there's more than one
difference between your environment and mine in that case.

   Does the file being transferred already exist on the remote system?
(Copy something with a different name which doesn't exist?)

   I know nothing about this scp/sftp software, but I can imagine that
if the destination file already exists, the client might want to add
write permission to it before trying to overwrite it.  An sftp session
might let you see details about what exists on the remote server, but an
scp copy in the other direction might tell you if the file exists.

> [...] -vvv on the command line to get a lot of information.

   "-vv" or "-vvv" might be more interesting than a mere "-v".

[Volker Halle]

Mario,

if you look at the filename given in the sftp error message: ' ./testfile.txt', there may be some problem with the way the SFTP client specifies or obtains the remote directory name. I had a similar problem with the SFTP client in TCPIP V5.7 ECO3G, where a 'GET filename' did not find the file, which a 'PUT filename' had just copied.

The workaround for that problem was to explicitly provide the remote directory name.

In your case, you could try to explicitly set the remote directory name before the put operation.

Volker.

[MarioL]

Hi.. sorry I took so long to get back to this.. but I've now got TCPIP patched to   

HP TCP/IP Services for OpenVMS Alpha Version V5.6 - ECO 5
  on a COMPAQ AlphaServer DS20E 833 MHz running OpenVMS V8.2    

ssh -"V" shows
aladn2$dkb0:[sys0.syscommon.][sysexe]tcpip$ssh_ssh2.exe: SSH Secure Shell OpenVMS (V5.5) 3.2.0 on COMPAQ AlphaServer DS20E 833 MHz - VMS V8.2
(so no change there)

It hasn't fixed this chmod issue though.  To restate the issue: the operators of the SFTP server have explicitly denied execution of chmod (for security reasons?).  When I put a file on to the server, I get an error because my sftp (and scp) client is trying to chmod the file.
This happens whether the file already exists at the destination or not.

huh.. while testing a bigger file, I just found out something new...
putting a file with file permissions (RWD,RWD,R,) to the server didn't cause the chmod error to come up.
The other file I had been trying so far has permissions (RWED,RWED,RE,)

After some experimenting, it would appear that it only tries to chmod when the source file has an execute permission. The other permissions don't matter.  (note: the transferred file always ends up with -rw-r--r-- on the sftp server)

So.. not sure where I'm going with this.  I guess I have a workaround now.. set the file protection before sending it to the sftp server.