Hi John, On 01-Dec-01 John Ritchie wrote:
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 <bolo@lupa.de> ---
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.
I've tried it on one of our linux boxes, and it doesn't work. The error: "Warning: ssh_packet_wrapper_input: invalid packet received: len 1819239269 closing the offending input channel." (Btw., the same error occurs with shells like false, noshell, etc.). Maybe Solaris "wraps" sftp/ssh sessions differently than Linux. According to sftp's (Linux-)man page, sftp uses a sub-system from sshd to transfer files securely. I don't know much about the ssh implementation on Solaris, tho.
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. :)
Hmm, couldn't think of any. AFAIK sftp was tested against some common security problems, just like ssh(d). Since sftp does not offer shell escapes, it should be no risk.
John Ritchie
Boris Lorenz <bolo@lupa.de> ---