You could put the user in a chroot gaol. Or set their shell to 'while /bin/true ; do sleep 100 ; done' Tom On 0, Greg Norris <haphazard@kc.rr.com> wrote: > I looked into something similar to what you're describing for a project > at work. We setup a user account so that it could only connect via SSH > (OpenSSH 3.x in this case) using public-key authentication, and then > defined some restrictions in ~/.ssh/authorized_keys. The net result > was that the account could be used to establish tunnels to predefined > hosts, but little else. > > I don't have my notes handy at the moment, but I could dig them up > tomorrow and send you the particulars. > > > On Wed, Aug 14, 2002 at 12:34:45PM -0400, Mike Dresser wrote: > > I've got a series of remote locations that I need to be able to connect to > > from head office. > > > > I need to be able to give a user the ability to ssh in, using port > > forwarding(such as through putty), to a machine inside the firewall at > > the remote location. > > > > So I load up putty, setup the forward, and it works and all. > > > > Here's the catch.. There's a shell running in the background. How do I > > do this, without leaving a shell running around where the "untrusted" user > > can access it? > > > > There's an option in ssh to not allocate a pseudo-terminal, but I don't > > trust the user not to change that. I need something server-side for that > > user login. > > > > Mike > > -- Tom Cook Information Technology Services, The University of Adelaide "Not to limit itself to play in a sand vat." - Google translation of, "not to be stuck in a sandbox." Get my GPG public key: https://pinky.its.adelaide.edu.au/~tkcook/tom.cook-at-adelaide.edu.au
Attachment:
pgpRzo0sUnvaw.pgp
Description: PGP signature