Bwt, we didn't establish if you're using OpenSSH or SSH, the difference being if you're using SSH (ssh*.com/ssh*.fi) you prolly are entitled to Commercial Support.
Ok, by the "other way" you prolly mean the auth_key thing. IMO, how slim are chances that if you "chattered +iu" the whole user env, except for the dropzone, that they will be able to modify/add to the shell's env, or drop binaries in that allow execution?
I've got *no* expertise on HP-UX, so you'll have to work it out yourself, but I found this source in an NG. I modified it in the sense that I added comments in as a warning. Maybe this will help, else, using HP-UX, your prolly entitiled for Commercial Support there as well.
here it goes, HTH somehow:
Code:
============================================
/*
* $Id: scp2shell.c,v 1.1 2000/08/24 06:09:12 dean2 Exp $
*
* Copyright by the Board of Trustees of the University of South
* Carolina. This software may be distributed and used under the
* terms of the Gnu Public License (GPL) or the Perl Artistic License,
* whichever you prefer.
*
* N. Dean Pentcheff <dean2@biol.sc.edu>
* Biological Sciences, University of South Carolina, Columbia SC 29208 USA
*
* A substitute login shell that allows only ssh2 file transfers, but
* no shell commands. Designed to allow for a black-box Unix/Linux
* server that permits file storage and transfer, but does not permit
* Unix-style shell logins. Handles both scp and sftp.
*
* Works by recognizing the particular arguments that ssh2 uses for
* scp and sftp and appropriately fires off sftp-server. Any other
* arguments (or a lack of them) cause an immediate exit. This all
* assumes a standard installation of ssh2 on the host Unix computer.
*/
/* Full path to the sftp-server binary (installed as part of ssh2) */
#define SFTPSERVERPATH "/usr/local/bin/sftp-server"
#include <string.h>
#include <unistd.h>
int
main(int argc, char **argv) {
if (--argc == 2 &&
strcmp("-c", *++argv) == 0 &&
strcmp("sftp-server", *++argv) == 0) {
execl(SFTPSERVERPATH, SFTPSERVERPATH, NULL);
} exit(0);
}
/*
* $Log: scp2shell.c,v $
* Revision 1.1 2000/08/24 06:09:12 dean2
* Initial revision
*
*/
/*
*This is a good approach. Since sshd2 uses the target account's login
*shell when running anything on the user's behalf, restricting what the
*shell can do is the most foolproof method of restricting the account's
*capabilities. Placing a forced command in the authorization file won't
*help, for instance, because that too will be run by the shell, which will
*only run sftp-server.
*
*One thing to keep in mind is that your users will still be able to
*manipulate files in ~/.ssh2. They can't circumvent the sftp restriction,
*but they can open up their account to others, etc. This may or may not be
*what you intend. You can use UserConfigDirectory to change the location
*of the per-account server config files if you want.
*
*By the way, you have essentially re-written ssh-dummy-shell, which comes
*with SSH2. ssh-dummy-shell provides a couple more features; see the man
*page.
*/
============================================
using sftp without having a Shell on serverside
