OK, I'm _Really_ behind in my suse-security reading. I hope everybody hasn't already moved past this onto better things. On Tue, 6 Nov 2001, Boris Lorenz wrote:
Hi,
On 06-Nov-01 Thorsten Marquardt wrote:
Hi List,
I like to offer some customers a kind off sftp account but to deny any login to this accounts. So I thought about having /bin/false as shell in /etc/passwd but this prevents sftp to. What can I do?
www.ssh.com offer a shell called ssh-dummy-shell, which provides any hooks for secure file transfer via sftp, but denies access to a real shell. Just replace the std shell entry in your /etc/passwd with it.
Other shells (e. g. /bin/false) won't work because sftp actually uses a normal ssh tunnel to transmit data, so it needs a more special treatment like std ftp.
This ssh-dummy-shell is part of the SSH server package, and also of the Windows Client-Pack (which also includes all server components).
However, the Win-Client-Pack isn't free.
Thanks in advance
Thom
Boris Lorenz
---
I tried the ssh-dummy-shell from ssh.com but it didn't interoperate with openssh although it worked perfectly on some of our systems that were running ssh.com's SSH server. I didn't try a PAM approach. The way I solved this (on Solaris with Openssh) was to set the sftp-only user's shell to be the sftp-server binary (/usr/local/libexec/sftp-server on my Solaris openssh build). I did not have to add this to /etc/shells. I haven't tried this on a SuSE box. The above solution has been working for several months without a hitch. My sftp-only users are connecting with ssh.com's commercial winblows ssh client, v. 3.0.x but I tested it with v 2.4 and also with linux and solaris openssh clients. If I missed some security implication in the above approach let me know. :) John Ritchie