Bug 3486 - SSH_ORIGINAL_COMMAND does not contan the original command anymore
Summary: SSH_ORIGINAL_COMMAND does not contan the original command anymore
Status: CLOSED WONTFIX
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: 9.0p1
Hardware: Other Cygwin on NT/2k/Win7-11
: P5 security
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-10-19 22:39 AEDT by Martin Rupp
Modified: 2023-03-17 13:38 AEDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Rupp 2022-10-19 22:39:43 AEDT
For some time ago I used the the possiblity to see the original command in the variable SSH_ORIGINAL_COMMAND. It worked very good.

E.g. if a user used a scp command to copy a file to target directory I was able to see that the user has invoked the scp command I was able to see the target directory in the variable SSH_ORIGNAL_COMMAND.

To evaluate the content of the SSH_ORIGINAL_COMMAND I have created a script to check if the user executes really this scp command and it was also possible to check if the target directory is the right one.

In newer versions of sshd the variable contains only "/usr/sbin/sftp-server" or "internal-sftp", dependent on the assignment of the "Subsystem"  definition in the /etc/sshd_config-file.

It was really a good method to ensure that user use really the scp command and doesn't use other targets (e.g. .ssh/authorized_key).

How can I get back the behaviour of sshd, that SSH_ORIGNAL_COMMAND contains really the orginal command (with some changes, because the variable contained in the past "scp -t <target-folder/target-file>" instead of the really command. but this was sufficient to see the important things like command and target folder.

I am able to disable all other security concerns via no-pty etc.

But I cannot ensure that the user really use only the foreseen folder.
Comment 1 Damien Miller 2022-10-20 09:49:19 AEDT
SSH_ORIGNAL_COMMAND is accurate: for the last few releases scp(1) has used the sftp protocol for file transfers, and the sftp protocol doesn't operate via the command-line as the scp/rcp protocol did.

So there's no way to get the paths back in SSH_ORIGINAL_COMMAND for newer scp clients. 

The only controls over file visibility that are available for sftp-server are sshd_config ChrootDirectory and file system permissions.
Comment 2 Martin Rupp 2022-10-29 21:44:33 AEDT
I cannot use the ChrootDirectory. I get an error.
I think the issue is Cygwin (no root user) and also the constraint that all components of the Chroot path must be owned by UID 0 and GID 0 and only be writeable by root.

Target path is /cygdrive/d/<subfolder1>/<subfolder2>

Also Chroot is not very secure in Cygwin.

It was so simple to filter the target path in SSH_ORIGINAL_COMMAND. I used only a simple script which I have assigned to the command part in the authorized keys.

I have also a very bad issue with sshd in Cygwin. I can copy files to folders where the transfer user, used in the scp command, has no write permission.

sshd is running under SYSTEM (= Local System).

If I use it without the filter of the correct information in SSH_ORIGINAL_COMMAND, users can copy files to all location on the Windows server. It is very unsecure and it is unuseable for me.

I need a solution as soon as possible.
Comment 3 Damien Miller 2023-03-17 13:38:08 AEDT
OpenSSH 9.3 has been released. Close resolved bugs