sftp without without a valid shell?
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? Thanks in advance Thom -- ------------------------------------------------------------------- bye bye (c) by Thom | Thorsten Marquardt | EMail: THOM@kaupp.chemie.uni-oldenburg.de | Member of the pzt project. | http://kaupp.chemie.uni-oldenburg.de/pzt -------------------------------------------------------------------
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?
Thanks in advance
Thom
use pam/logins.conf, etc. http://www.seifried.org/lasg/ discusses this type of thing. Kurt Seifried, kurt@seifried.org A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://www.seifried.org/security/
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> ---
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. 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
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> ---
I have openssh-2.9.9p1 with SuSE6.4 distro and it works for me ----- Original Message ----- From: "Boris Lorenz" <bolo@lupa.de> To: <suse-security@suse.com> Sent: Tuesday, December 04, 2001 4:38 PM Subject: RE: [suse-security] sftp without without a valid shell?
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> ---
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
I have openssh-2.9.9p1 with SuSE6.4 distro and it works for me ----- Original Message ----- From: "Boris Lorenz" <bolo@lupa.de> To: <suse-security@suse.com> Sent: Tuesday, December 04, 2001 4:38 PM Subject: RE: [suse-security] sftp without without a valid shell?
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> ---
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
On Tue, 4 Dec 2001, Boris Lorenz wrote:
Hi John,
On 01-Dec-01 John Ritchie wrote:
[much stuff cut]
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.
I remember encountering this error while testing but I got around it somehow. I'm thinking it had to do with versions of openssh (or maybe I saw that on the commercial SSH server?) or misconfigured sshd_config (sftp subservice not turned on?) or something like that. I'm sorry I don't remember the details; it's been several months and I didn't document it so it's gone. Sorry I can't be more exact. I tested using the sftp-server as shell on a SuSE 7.0 machine with openssh 2.9.9p2-27 and it worked for me. What version of ssh are you using? John
Yup, On 09-Dec-01 John Ritchie wrote:
On Tue, 4 Dec 2001, Boris Lorenz wrote:
Hi John,
On 01-Dec-01 John Ritchie wrote: [...] 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.
I remember encountering this error while testing but I got around it somehow. I'm thinking it had to do with versions of openssh (or maybe I saw that on the commercial SSH server?) or misconfigured sshd_config (sftp subservice not turned on?) or something like that. I'm sorry I don't remember the details; it's been several months and I didn't document it so it's gone. Sorry I can't be more exact.
I tested using the sftp-server as shell on a SuSE 7.0 machine with openssh 2.9.9p2-27 and it worked for me. What version of ssh are you using?
my test box runs an older 2.0.13 sshd, patched, on top of a 2.2.20 kernel. I will give it a try with the latest ssh version (unpatched, stable) and post the results. Btw., my sshd2_config looks good, sftp is enabled of course. It works neatly with the ssh-dummy-shell and std shells (sh, bash, ksh, etc.).
John
Boris Lorenz <bolo@lupa.de>
On 6 Nov 01, at 10:39, Thorsten Marquardt wrote:
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?
Install a dummy-shell. mfg ar -- mailto:andreas@rittershofer.de http://www.rittershofer.de PGP-Public-Key http://www.rittershofer.de/ari.htm
On 6 Nov 01, at 10:39, Thorsten Marquardt wrote:
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?
Hi Andreas! On Tue, 06 Nov 2001, Andreas Rittershofer wrote: put /bin/false in /etc/shells and set /bin/false as shell [discl: not tested] -- teodor
Hi, On 06-Nov-01 Teodor Cimpoesu wrote:
Hi Andreas! On Tue, 06 Nov 2001, Andreas Rittershofer wrote:
On 6 Nov 01, at 10:39, Thorsten Marquardt wrote:
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? put /bin/false in /etc/shells and set /bin/false as shell [discl: not tested]
this works with ftp, but not with sftp, which is part of the ssh package. I've gone thru all the options two years ago... /bin/false, /bin/noshell, my own (perl-)shells, to no avail. Only ssh-dummy-shell does the trick. If there's an alternative to it, I would be happy to learn.
-- teodor
Boris Lorenz <bolo@lupa.de> ---
Hi Boris! On Wed, 07 Nov 2001, Boris Lorenz wrote:
Hi,
On 06-Nov-01 Teodor Cimpoesu wrote:
Hi Andreas! On Tue, 06 Nov 2001, Andreas Rittershofer wrote:
On 6 Nov 01, at 10:39, Thorsten Marquardt wrote:
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? put /bin/false in /etc/shells and set /bin/false as shell [discl: not tested]
this works with ftp, but not with sftp, which is part of the ssh package.
I've gone thru all the options two years ago... /bin/false, /bin/noshell, my own (perl-)shells, to no avail. Only ssh-dummy-shell does the trick.
If there's an alternative to it, I would be happy to learn.
[another not tested rant :)] maybe: auth required /lib/security/pam_shells.so instead of: auth required /lib/security/pam_nologin.so in /etc/pam.d/sshd? -- teodor
Hi Boris! On Wed, 07 Nov 2001, Boris Lorenz wrote:
Hi,
On 06-Nov-01 Teodor Cimpoesu wrote:
Hi Andreas! On Tue, 06 Nov 2001, Andreas Rittershofer wrote:
On 6 Nov 01, at 10:39, Thorsten Marquardt wrote:
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? put /bin/false in /etc/shells and set /bin/false as shell [discl: not tested]
this works with ftp, but not with sftp, which is part of the ssh
For pam stuff: http://www.samag.com/documents/s=1161/sam0009a/0009a.htm you can easily set it up so that a user cannot log in via ftp/etc, but sftp is PART of ssh, so it greatly complicates things. Simply limit them to 1 process or something and they won't be able to fire up a shell. Kurt Seifried, kurt@seifried.org A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://www.seifried.org/security/ ----- Original Message ----- From: "Teodor Cimpoesu" <teo@gecadsoftware.com> To: <suse-security@suse.com> Sent: Wednesday, November 07, 2001 2:00 PM Subject: Re: [suse-security] sftp without without a valid shell? package.
I've gone thru all the options two years ago... /bin/false,
/bin/noshell, my own
(perl-)shells, to no avail. Only ssh-dummy-shell does the trick.
If there's an alternative to it, I would be happy to learn.
[another not tested rant :)] maybe: auth required /lib/security/pam_shells.so instead of: auth required /lib/security/pam_nologin.so in /etc/pam.d/sshd?
-- teodor
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Yup, On 07-Nov-01 Teodor Cimpoesu wrote:
Hi Boris! On Wed, 07 Nov 2001, Boris Lorenz wrote:
Hi,
On 06-Nov-01 Teodor Cimpoesu wrote:
Hi Andreas! On Tue, 06 Nov 2001, Andreas Rittershofer wrote:
On 6 Nov 01, at 10:39, Thorsten Marquardt wrote:
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? put /bin/false in /etc/shells and set /bin/false as shell [discl: not tested]
this works with ftp, but not with sftp, which is part of the ssh package.
I've gone thru all the options two years ago... /bin/false, /bin/noshell, my own (perl-)shells, to no avail. Only ssh-dummy-shell does the trick.
If there's an alternative to it, I would be happy to learn.
[another not tested rant :)] maybe: auth required /lib/security/pam_shells.so instead of: auth required /lib/security/pam_nologin.so in /etc/pam.d/sshd?
yeah, the PAM thing... Trouble is I *LOATHE* PAM... Don't know why. Maybe I suck at it ;) I still use ssh-dummy-shell. Works cleanly. However, thanks to teo and Kurt for the tips. I will visit some sites and think about it.
-- teodor
Boris Lorenz <bolo@lupa.de> ---
Boris Lorenz wrote: [SNIP]
I still use ssh-dummy-shell. Works cleanly.
I looked at this, but as I use OpenSSH I couldn't see a way to do it. Is there a compiled version around one could use? I don't fancy dumping OpenSSH in favour of SSH. Cheers, Laurie. -- --------------------------------------------------------------------- Laurie Brown laurie@brownowl.com PGP key at http://pgpkeys.mit.edu:11371 ---------------------------------------------------------------------
participants (8)
-
Andreas Rittershofer -
Boris Lorenz -
John Ritchie -
José Luis Ledesma -
Kurt Seifried -
Laurie Brown -
Teodor Cimpoesu -
Thorsten Marquardt