Man page for apt-get rssh Command
This tutorial shows the man page for man rssh in linux.
Open terminal with 'su' access and type the command as shown below:
Result of the Command Execution shown below:
RSSH(1) Derek D. Martin RSSH(1)
rssh restricted secure shell allowing only scp and/or sftp
rssh [ options... ] [ ... ]
rssh is a restricted shell for providing limited access to a host via
ssh(1), allowing a user whose shell is configured to rssh to use one or
more of the command(s) scp(1), sftp(1) cvs(1), rdist(1), and rsync(1),
and only those commands. It is intended primarily to work with OpenSSH
(see http://www.openssh.com), but may work with other implementations.
The system administrator should install the shell on the restricted
system. Then the password file entry of any user for whom it is
desireable to provide restricted access should be edited, such that
their shell is rssh. For example:
If invoked with the v option, rssh will report its version, and exit.
All other arguments to rssh are those specified by the remote ssh(1)
client, and aren't of much concern to the average user. The arguments
provided must be what a shell on the remote end would receive in order
to pass control to scp(1), sftp(1), etc. If rssh receives arguments
which do not conform, it will emit an error message and exit. If the
program the user is trying to run is not allowed, or contains syntax
which will try to execute a shell command (such as a command substitu
tion), it will also emit an error and exit.
rssh has a configuration file, rssh.conf(5), which allows some of the
behavior of rssh to be customized. See that man page for details.
Read this section with exceptional care, or you may put your system at
Using rssh With CVS
If you are using rssh to allow CVS access, it should be noted that it
is not possible to prevent a user who is very familiar with CVS from
bypassing rssh and getting a shell, unless the user does not have write
access in the repository. Obviously, the user must have write access
to the repository in order to update it, which allows them to upload
arbitrary programs into the repository. CVS provides several mecha
nisms for executing such arbitrary programs... The only reasonably
safe way to use rssh with CVS is to use the chroot jail facilities to
place the CVS repository within a chroot jail. Please see below and
all relevant documentation for details of how to set up chroot jails.
Note that users will still be able to get shell access within the jail;
the only protection which is provided is that they can not escape the
jail. I have been pursuaded to retain support for CVS because this
protection is better than no protection. You have been warned. Use CVS
at your own risk.
Potential root Compromise With Old Versions
Before rssh 2.3.0, if a regular user had shell access to a machine
where rssh was installed, a root compromise was possible due to
rssh_chroot_helper allowing a user to arbitrarily chroot(2) to anywhere
on the filesystem. It is possible to mitigate this attack against
affected versions of rssh using strict access controls to files, by
making sure that the user can not write to any file on the same parti
tion as system executables, and that any partition where they can write
files does not allow execution of SUID programs. As of rssh 2.3.0,
this attack has been prevented by preventing arbitrary chroot(), if
your jail is set up securely. In particular, make sure that regular
users can not write to directories inside the jail which contain the
copied binaries. That should be obvious, but it needs to be said.
Though it should not be strictly necessary, to further protect your
system from possible compromise, it is also advisable to follow the
section below, entitled "Safeguards Against Bypassing rssh".
Safeguards Against Bypassing rssh
rssh is designed to interact with several other programs. Even if rssh
is completely bug free, changes in those other programs could possibly
result in methods to circumvent the protection that rssh is intended to
provide. It is important for you, the system administrator, to stay
current on the services you make available with rssh, to be sure that
these commands do not provide mechanisms to allow the user to run arbi
trary commands. Also, while the goal of every release is to be bug
free, no one is perfect... There may be undiscovered bugs in rssh
which might allow a user to circumvent it.
You can protect your system from those who would take advantage of such
weaknesses. This is not required for rssh to work properly, but it is
a really good idea. There are six basic steps:
1. protect all non administrator accounts with rssh (i.e. no
regular user should have shell access to the server)
2. place your users in a chroot jail
3. limit the binaries which live in the jail to the absolute
4. mount their home filesystem with the noexec/nosuid option
(i.e. use separate partitions in the jail for user home
directories and all other files, if possible/reasonable)
5. create a group for rssh users, and limit executable
access to the binaries to users in that group.
6. use standard file permissions carefully and appropriately
If possible, make sure that no regular user has any kind of shell
access to the system other than through rssh. Otherwise, users with
shell access could potentially exploit undiscovered bugs in
rssh_chroot_helper to gain root access to the server.
rssh gives the system administrator the ability to place the users in a
chroot jail. See details in the man page for rssh.conf and in the file
CHROOT which is distributed with the source code. If you want to
ensure users can not run arbitrary programs, use a chroot jail, and be
sure not to put any programs other than what are absolutely necessary
to provide the service you are trying to provide. This prevents them
from running standard system commands.
Then, make sure the user's files inside the jail are on a seperate
filesystem from your system's executables. If possible in your envi
ronment, make sure you mount this filesystem using the noexec and
nosuid options, if your operating system provides them. This prevents
the users from being able to execute programs which they have uploaded
to the target machine (e.g. using scp) which might otherwise be exe
cutable, and prevents SUID programs from respecting the SUID bits.
Note that these options necessitate the users' files are on separate
partitions from the binaries and libraries that live in the jail.
Therefore you will need at least 2 partitions for your jail to do this
properly (one for the system binaries in the jail, the other for the
Additionally, create a group, for example "rsshuser", for rssh users.
Put all your users who will be restricted by rssh in that group. Set
the ownership and permissions on rssh and rssh_chroot_helper so that
only those users can execute them. The following commands should