Hi, some time ago we had a similar problem but we used scp/openssh for file transfer instead of s-ftp. to get rid of the usual problems with special characters we give our scp user only a restricted shell (smrsh - taken from the sendmail package), with strips all illegal characters for us and gives the user only commands that we define. the only command that he is allowed is a shell script that calls a copy of scp (with the '-t' switch to tell scp to receive a file). here i a quick and dirty howto: 1. create a special user for the scp file transfer with least possible rights 2. get the latest sendmail package and compile it. 3. get, compile and configure the latest openssh package (openssh is optional, our solution should work with every ssh version) 4. cp the smrsh binary from the sendmail package somewhere in your path (i.e. /usr/local/bin) 5. edit /etc/passwd to give your new scp user /usr/local/bin/smrsh as login shell 6. create a dummy directory (the new user must be able to go here, so use: r-xr-xr-x, owner/group root) 7. cp the scp binary in this directory (i.e. as scp.bak) and change the file permissions so that our scp user has only execute rights 8. now go to the directory where the allowed commands for the restricted shell are (/usr/adm/sm.bin is the default dir) and create a shell script named 'scp' that looks like this #!/bin/sh /dummy_directory_with_a_copy_of_scp_binary/scp.bak -t ~ please note the "~" at the end of the line. this allows the user to copy files only in his home directory not somewhere in our system. -> voila, the only thing, the new user can do is copy files with scp into his home directory i hope this helps. if you run into problems or find any security risks using this solution please send me some feedback. ciao Rainer Huber -------------------------
* bolo@lupa.de wrote on Tue, Jul 18, 2000 at 17:42 +0200:
due to our security policy we can not provide our users with telnet/ftp but with ssh/sftp to do their stuff on our servers. Now the question arose wether it would be possible to only allow sftp-connections _without_ shell access.
The manpage is somewhat imprecise in this matter. The term `shell' should
read `interactive shell'.
It's a shell's task to look for executables in the system if the
executable is called without a slash in the first word of the commandline.
This is why sshd starts the login shell, gained from the seventh field of
the respective line in /etc/passwd, and leaves this problem up to the
shell. Other approaches might impose security risks.
Btw, while we're at it: This (login-) shell sources ~/.ssh/config (plus
the system-wide one) _without_ creating a new context/subshell (!).
What you could do is the following: Try to set the user's login shell to
the sftp client program's path. Another option: Set the login shell to a
script which contains `exec /path/to/sftp-client options'.
If you consider trying either method, you should be aware of what this
client is capable of. You may end up having some escape or site exec
possibilities.
Thanks,
Roman Drahtmuller.
--
- -
| Roman Drahtmuller