Folks, I've been tasked to find a solution that will create file-transfer-only accounts that are jailed or chrooted to a specific directory. (Not an uncommon task, I think.) Using the OpenSSH server and the OpenSSH scp client program, I can achieve the goal of having a file transfer only account jailed to a specified directory, by using the "scpjail" script (attached) as a forced command. However, if the client is using the SSH.COM's scp2 client program, the above technique does not work, since the commercial version uses sftp as the underlying method. So, the only solution I can see is to use one of the several chrooting patches that are floating around to the OpenSSH source, and set the user's shell to sftp-server. If I do this, I make it impossible to use the OpenSSH scp client ; all connections must be done using sftp clients. I am also tied to selecting and using one of these patches, which I admit, I do not have the technical ability to judge on their merits and potential weaknesses. I am phobic about using patches that are not part of the baseline code (especially for security-related software), as it creates one more thing to worry about. My question is, does anyone see a solution that I am missing here? Complaining to SSH.COM is not a solution, as it does not solve my problem. It is not in my power to force the user community to use only the OpenSSH implementation. I've seen many mails on this list lately talking about the pros and cons of including chroot-ability; the people who seem to feel that it is unnecessary have said that it is easy enough to implement outside of OpenSSH. I don't have the ability to do so; among the community of OpenSSH users, I doubt I'm alone in this. (As an aside, I'd appreciate it if people would look at the attached script, and let me know if they can see any obvious holes in it. I've tried unsuccessfully to break out if it is set up properly, but others may have more success.) Thanks, -S- -- Sandor W. Sklar - Unix Systems Administrator - Stanford University ITSS Non impediti ratione cogitationis. http://whippet.stanford.edu/~ssklar/ -------------- next part -------------- A non-text attachment was scrubbed... Name: scpjail Type: application/mac-binhex40 Size: 11846 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020521/cf77c2c8/attachment.bin
I'm sorry but I know I don't read binhex.
But assuming you did what has been discussed here before which is wrote
some from of program that detects the -c argument passed to it and accept
or deny the commands. This can work for sftp-server also. Because we
do ${SHELL} -c sftp-server just like one would expect.
- Ben
On Tue, 21 May 2002, Sandor W. Sklar wrote:
> Folks,
>
> I've been tasked to find a solution that will create
> file-transfer-only accounts that are jailed or chrooted to a specific
> directory. (Not an uncommon task, I think.)
>
> Using the OpenSSH server and the OpenSSH scp client program, I can
> achieve the goal of having a file transfer only account jailed to a
> specified directory, by using the "scpjail" script (attached) as
a
> forced command.
>
> However, if the client is using the SSH.COM's scp2 client program,
> the above technique does not work, since the commercial version uses
> sftp as the underlying method.
>
> So, the only solution I can see is to use one of the several
> chrooting patches that are floating around to the OpenSSH source, and
> set the user's shell to sftp-server. If I do this, I make it
> impossible to use the OpenSSH scp client ; all connections must be
> done using sftp clients. I am also tied to selecting and using one
> of these patches, which I admit, I do not have the technical ability
> to judge on their merits and potential weaknesses. I am phobic about
> using patches that are not part of the baseline code (especially for
> security-related software), as it creates one more thing to worry
> about.
>
> My question is, does anyone see a solution that I am missing here?
> Complaining to SSH.COM is not a solution, as it does not solve my
> problem. It is not in my power to force the user community to use
> only the OpenSSH implementation.
>
> I've seen many mails on this list lately talking about the pros and
> cons of including chroot-ability; the people who seem to feel that it
> is unnecessary have said that it is easy enough to implement outside
> of OpenSSH. I don't have the ability to do so; among the community
> of OpenSSH users, I doubt I'm alone in this.
>
> (As an aside, I'd appreciate it if people would look at the attached
> script, and let me know if they can see any obvious holes in it.
> I've tried unsuccessfully to break out if it is set up properly, but
> others may have more success.)
>
> Thanks, -S-
>
> --
> Sandor W. Sklar - Unix Systems Administrator - Stanford University
ITSS
> Non impediti ratione cogitationis.
http://whippet.stanford.edu/~ssklar/
On Mon, 27 May 2002 10:34:33 EDT, I wrote:> > Note: the above is completely untested! [...]...in fact, it wasn't even _proofread_. :-( Now that I've had my morning coffee, this is a little closer to what I had in mind. It's still not well-tested, but it's not quite as spectacularly wrong. #define JAIL "/path/to/jail" #define SHELL "/bin/sh" int main(int argc, char **argv) { if (chroot(JAIL) != 0) { perror("chroot"); } else if (chdir("/") != 0) { perror("chdir"); } else if (setuid(getuid()) != 0) { perror("setuid"); } else { execv(SHELL, argv); perror("execv"); } exit(1); } My apologies for not paying attention. <blush> -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican