You will generate a key on the users machine via whatever ssh client they are using. pUTTY for example has a utility to do this exact thing. It will generate both a private and public key.
The contents of the public key file generated will be placed in the authorized_keys file.
Next you need to make sure that the ssh client is configured to use the private key that generated the public key. It's fairly straight forward, but slightly different depending on the client being used.
You'll probably want to set the user's shell to the restricted shell. Unset the PATH variable in the user's ~/.bashrc or ~/.bash_profile, and they won't be able to execute any commands. Later on, if you decide you want to allow the user(s) to execute a limited set of commands, like less or tail for instance, then you can copy the allowed commands to a separate directory (such as /home/restricted-commands) and update the PATH to point to that directory.
I'm able to set up the authorized_keys file with the public key to log
in. What I'm not sure about is the additional information I need to
restrict what that account is allowed to do. For example, I know I can
put commands such as:
Besides authorized_keys option like no-X11-forwarding, there actually is exactly one you are asking for: permitopen="host:port". By using this option, the user may only set up a tunnel to the specified host and port.
For the details of the AUTHORIZED_KEYS file format refer to man sshd.
On Ubuntu 11.10, I found I could block ssh commands, sent with and without -T, and block scp copying, while allowing port forwarding to go through.
Specifically I have a redis-server on "somehost" bound to localhost:6379 that I wish to share securely via ssh tunnels to other hosts that have a keyfile and will ssh in with:
This will cause the redis-server, "localhost" port 6379 on "somehost" to appear locally on the host executing the ssh command, remapped to "localhost" port 16379.
On the remote "somehost" Here is what I used for authorized_keys:
The no-pty trips up most ssh attempts that want to open a terminal.
The permitopen explains what ports are allowed to be forwarded, in this case port 6379 the redis-server port I wanted to forward.
The command="/bin/echo do-not-send-commands" echoes back "do-not-send-commands" if someone or something does manage to send commands to the host via ssh -T or otherwise.
From a recent Ubuntu man sshd, authorized_keys / command is described as follows:
command="command"
Specifies that the command is executed whenever this key is used
for authentication. The command supplied by the user (if any) is
ignored.
Attempts to use scp secure file copying will also fail with an echo of "do-not-send-commands" I've found sftp also fails with this configuration.
I think the restricted shell suggestion, made in some previous answers, is also a good idea.
Also, I would agree that everything detailed here could be determined from reading "man sshd" and searching therein for "authorized_keys"
I set the restricted user's shell to this program.
I don't think the restricted user can execute anything, even if they do ssh server command, because the commands are executed using the shell, and this shell does not execute anything.
Note that we use rbash (restricted-bash) to restrict what the user can do: the user cannot cd (change directory) and cannot set any environment variables.
Then we edit the user's PATH env variable in /home/sshtunnel/.profile to nothing - a trick that will make bash not find any commands to execute:
PATH=""
Finally we disallow the user to edit any files by setting the following permissions:
chmod 555 /home/sshtunnel/
cd /home/sshtunnel/
chmod 444 .bash_logout .bashrc .profile