cheesyking wrote:All I want them to do is login with putty so that they can tunnel a connection to an internal webserver on another machine.
...
I'd really like a way of restricting some users so they can only tunnel to a specific host on the internal network but anything is better than nothing.
If you want them to tunnel via ssh port forwarding, you can actually do this quite handily using only stuff built in to OpenSSH, and you won't need a restricted shell at all. All you need to do is set up an authorized key for each of the users to connect (or a shared one if they all have the same privs) and then use the authorized_keys directives to limit the power of the connection. As a simple example, you could put something like this before the keys:
permitopen="10.1.1.1:80",command="somecommand",no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss AAA...
The permitopen only allows them to set up ssh port forwarding to that host and port. You can put multiple clauses if you want. In that case, they don't need shell access at all, and the command= specifies a command to run on connection. For somecommand some have suggested a simple script like this:
#!/bin/bash
tail -f /dev/null
or just using cat. In either case, the result is the same: they are forced to run a command that does nothing but are still allowed to initiate port forwarding to a specific host/port combination. Then just lock the user account using passwd so the user can't login normally with password auth.
Edit: the reason we need to run some command that just sits there forever and does nothing is because you are using Putty. If you were using the OpenSSH client, you could just set the command to /bin/true and the client could use ssh -Nf to simply set up forwarding in the background. Unless they've fixed it now, Putty will close the connection and the forwarding when the remote program returns.
