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 ---

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 ---

I have openssh-2.9.9p1 with SuSE6.4 distro and it works for me ----- Original Message ----- From: "Boris Lorenz" To: 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 ---

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 ---

-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

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

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 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

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 ---