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 "sftp-su@vandyke.com" 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();
ssh.Connect("server01");
ssh.Authenticate("userA", "password");
// open an SSH channel
SshChannel channel = ssh.OpenSession();
// execute the SFTP server (works on Debian Linux with OpenSSH)
channel.RequestExec("/usr/lib/sftp-server");
// bind Sftp object to the channel
Sftp sftp = new Sftp();
sftp.Bind(channel.ToSocket());
// try listing files using the Sftp object
Console.WriteLine(string.Join("\n", sftp.GetRawList()));
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 channel.RequestPseudoTerminal()
before RequestExec()
, making it possible to actually authenticate to su
or 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 NOPASSWD
disables sudo
's password prompt for the sftp-server
executable:
userA ALL=(ALL) NOPASSWD:/usr/lib/sftp-server
Defaults:userA !requiretty
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.