Unfortunately, this approach is not going to work. The
sudo su USER command only affects the scripting session, not the SCP session you established later. Even though both sessions run over the same SSH connection, they are distinct. To make this work, you would have to start the
scp command in the same session where you executed "sudo su USER" (perhaps you are doing something like this in WinSCP), but this is not going to work with
Scripting sessions because those have a pseudo-terminal allocated, which would interfere with SCP traffic... Instead, you have to open an
SshChannel and use
RequestExec, but more on that below. If you can, please send us a communication log from WinScp - if we knew exactly which commands you issue there, we would be able to let you know how to reproduce the same with Rebex libraries.
We already investigated a similar scenario several years ago, so I'm sharing our findings here. It mostly deals with
sftp, although the same applies to
scp as well.
This is possible with many Unix boxes (just tested it on Debian Linux with OpenSSH), but requires some changes to "sudo" configuration files. A long explanation follows…
The SFTP protocol is actually one of the subsystem (sub-protocols) of SSH (other subsystems are 'remote exec' and 'remote shell'), and authentication occurs at the SSH level. Unfortunately, SSH protocol itself doesn't support any additional su-like authentication, although it's of course possible to execute these commands inside the 'remote exec' or 'remote shell' subsystems. Unfortunately, you can't execute these commands in the SFTP subsystem and it doesn't offer any similar functionality either. (The "firstname.lastname@example.org" protocol extension makes this possible, but it's not widely supported.)
However, some SSH/SFTP implementations such as OpenSSH make it possible to "execute" SFTP server using the 'remote exec' subsystem – this works on most Linux boxes, for example. To take advantage of this using Rebex SFTP, you would use the following code:
// connect and authenticate to the SSH/SFTP server
var ssh = new SshSession();
// open an SSH channel
SshChannel channel = ssh.OpenSession();
// execute the SFTP server (works on Debian Linux with OpenSSH)
// bind Sftp object to the channel
Sftp sftp = new Sftp();
// try listing files using the Sftp object
This executes an SFTP session under the logged-on user account.
Unfortunately, although it seems quite straightforward to simply execute something like
su userB -c /usr/lib/sftp-server instead (and send the password and receive response if needed before proceeding to SFTP), this usually does not work. The
su command fails with an error message of
su: must be run from a terminal error message (which can be read using
channel.Receive method). The error is reported because
su is supposed to only be run by users connected through a terminal… Although it's possible to request a terminal by calling
RequestExec(), making it possible to actually authenticate to
sudo, this has a nasty side effect of making the SFTP session unusable (because pseud-terminals cannot handle binary input/output streams).
The same applies to
sudo as well by default, but fortunately,
sudo is very configurable and the requirement can even be disabled for a single command (even for a single user) – see this forum post for details. By adding the following lines to
/etc/sudoers file, I was able to run SFTP as root simply by logging in as
userA and calling
channel.RequestExec("sudo /usr/lib/sftp-server") – the
!requiretty option disables the terminal requirement, while
sudo's password prompt for the
userA ALL=(ALL) NOPASSWD:/usr/lib/sftp-server
Although we are not very familiar with
sudo's configuration options, it looks like it is possible to configure it to execute a command as non-root user as well.