keypair auth and limiting access to sftp

James Ralston qralston+ml.openssh-unix-dev at andrew.cmu.edu
Tue Sep 18 07:06:42 EST 2001


On Sun, 16 Sep 2001 mouring at etoh.eviladmin.org wrote:

> Peter, you may want to check the current snapshot.  On 9/14 I
> included a patch from the OpenBSD tree on subsystem and key pairs.
>
> [..]
>    - markus at cvs.openbsd.org 2001/09/14
>      [session.c]
>      command=xxx overwrites subsystems, too
> [..]
>
> Hope this helps what you are doing.

Making sftp inaccessable to chroot'ed accounts is certainly one way to
prevent chroot'ed accounts from using sftp to break out of their
chroot jails, yes.

But it's not a very useful one.  I *want* the chroot'ed accounts to be
able to use sftp, because if they can't, then I'm going to have to
open up ftp in order to allow them to upload files.  (And if I have to
do *that*, I might as well just not even bother with openssh, and
instead tell the userse to just use telnet/ftp instead.)

I refuse to accept that the only way I can maintain the integrity of
my system's security is to drop ssh/sftp in favor of telnet/ftp.

After pondering the pam sources a bit more, here's a question: why
does sshd only bother to call do_pam_session() when allocating a pty?
If sshd instead were to always call do_pam_session() after the user
was authenticated, regardless of what the command to execute was, and
regardless of whether the user requested a pty or not, then that would
cause ssh, scp, sftp, and any future subsystems to implement
pam_chroot.so.

Would you accept a patch to make sshd always call do_pam_session()?

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA




More information about the openssh-unix-dev mailing list