Mostly legacy... SSH was a "drop in" replacement for the insecure BSD r* commands (rsh, rcp, rlogin). It was originally based off of that code, and that was how rcp worked. RCP would call rsh to create the connection, and the remote connection's rsh would call rcp, but it would use the shell because the path to the rcp executable was seldom the same between systems or even over time on the same system. I suspect that there might be other reasons for the shell -c execution, but it's been a long time since I hacked on sshd or r* commands, so I can't really say for sure. Have you tried using the internal-sftp subsystem? I think this should do what you're trying to do (assuming you're using openssh)... satch On 5/22/08 9:47 AM, "Cathey, Jim" <jcathey@xxxxxxxxx> wrote: > We have an application-specific 'shell' that is completely unrelated to > Bourne/C-shell world, yet we would like sftp to work. What we've found > is > that sshd (in session.c) EXPECTS that ANY shell be able to execute > "anyshell > -c /path/to/sftp" and have it end up execing sftp. Ours won't, nor for > that > matter, does rbash, since sftp has slashes in the path. > > This seems like a coding error to me, why should session.c not do the > old-school canonical Unix-ey thing of trying to exec(command) first, > before > going on to try exec(shell, "-c", command), if its ultimate purpose was > to > execute command? Is there a reason, or is this just a long-standing > 'bug'? > What purpose does first trotting through a user's Bourne-y shell serve? > > -- Jim >
