MAN page from RedHat EL 7 rssh-2.3.3-2.el7.rf.x86_64.rpm
Section: Derek D. Martin (1)
Updated: 1 Aug 2010Index
rssh - restricted secure shell allowing only scp and/or sftp
is a restricted shell for providing limited access to a host via ssh
(1), allowing a user whose shell is configured torssh
to use one or more of the command(s) scp
(1), and rsync
(1), and only
those commands. It is intended primarily to work with OpenSSH (seehttp://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 providerestricted access should be edited, such that their shell is rssh
If invoked with the -v
will report its version, and exit. All other arguments to rssh
are those specified by the remote ssh
(1) client, and aren't of muchconcern to the average user. The arguments provided must be what a shell onthe remote end would receive in order to pass control to scp
(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 syntaxwhich will try to execute a shell command (such as a command substitution), itwill also emit an error and exit.rssh
has a configuration file, rssh.conf
(5), which allows some of thebehavior of rssh
to be customized. See that man page for details.
SECURITY NOTESRead this section with exceptional care, or you may put your system at risk!
Using rssh With CVS
If you are using rssh
to allow CVS access, it should be noted that it isnot possible to prevent a user who is very familiar with CVS from bypassingrssh
and getting a shell, unless the user does not have write access inthe repository. Obviously, the user must have write access to the repositoryin order to update it, which allows them to upload arbitrary programs into therepository. CVS provides several mechanisms for executing such arbitraryprograms... The only reasonably safe way to use rssh
with CVS is to usethe 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 upchroot jails. Note that users will still be able to get shell accesswithin the jail
; the only protection which is provided is that they can notescape the jail. I have been pursuaded to retain support for CVS because thisprotection 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 wherersshwas installed, a root compromise was possible due to rssh_chroot_helperallowing a user to arbitrarily chroot(2) to anywhere on the filesystem.It is possible to mitigate this attack against affected versions of rsshusing strict access controls to files, by making sure that the user can notwrite to any file on the same partition as system executables, and that anypartition where they can write files does not allow execution of SUIDprograms. As of rssh 2.3.0, this attack has been prevented bypreventing arbitrary chroot(), if your jail is set up securely. Inparticular, make sure that regular users can not write to directories insidethe jail which contain the copied binaries. That should be obvious, but itneeds to be said. Though it should not be strictly necessary, to furtherprotect your system from possible compromise, it is also advisable to followthe section below, entitled "Safeguards Against Bypassing rssh".
Safeguards Against Bypassing rsshrssh
is designed to interact with several other programs. Even if rssh iscompletely bug-free, changes in those other programs could possibly result inmethods to circumvent the protection thatrssh
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 thatthese commands do not provide mechanisms to allow the user to run arbitrarycommands.
Also, while the goal of every release is to be bug free, no oneis 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 suchweaknesses. This is not required for rssh
to work properly, but it is areally good idea. There are six basic steps:
- protect all non-administrator accounts with rssh (i.e. no regular user should have shell access to the server)
- place your users in a chroot jail
- limit the binaries which live in the jail to the absolute minimum required
- mount their home filesystem with the noexec/nosuid option (i.e. useseparate partitions in the jail for user home directories and all other files,if possible/reasonable)
- create a group for rssh users, and limit executable access to the binaries tousers in that group.
- use standard file permissions carefully and appropriately
If possible, make sure that no regular user has any kind of shell access tothe system other than through rssh
. Otherwise, users with shell accesscould 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 chrootjail. See details in the man page forrssh.conf
and in the fileCHROOT
which is distributed with the source code. If you want to ensure users cannot run arbitrary programs, use a chroot jail, and be sure not to put anyprograms other than what are absolutely necessary to provide the service youare trying to provide. This prevents them from running standard systemcommands.Then, make sure the user's files inside the jail are on a seperate filesystemfrom your system's executables. If possible in your environment, make sureyou mount this filesystem using thenoexec
options, if your operating system provides them. This prevents the users frombeing able to execute programs which they have uploaded to the target machine(e.g. using scp) which might otherwise be executable, and prevents SUIDprograms from respecting the SUID bits. Note that these options necessitatethe users' files are on separate partitions from the binaries and librariesthat live in the jail. Therefore you will need at least 2 partitions for yourjail to do this properly (one for the system binaries in the jail, the otherfor the user directories).Additionally, create a group, for example "rsshuser", for rssh users. Put allyour users who will be restricted by rssh in that group. Set the ownershipand permissions on rssh and rssh_chroot_helper so that only those users canexecute them. The following commands should illustrate:
- # groupadd rsshuser
# chown root:rsshuser rssh rssh_chroot_helper
# chmod 550 rssh
# chmod 4550 rssh_chroot_helper
Lastly, use standard Unix/POSIX file permissions to ensure theycan not access files they should not be able to within the chroot jail.
Command Line Parser
As of rssh
version 2.2.3, the program must parse out the complete command line to avoidcommand line options which cause the execution of arbitrary programs (andhence bypass the security of rssh
). In order to keep the program sourcecode sane, the parser is a little over-zealous about matching command lineoptions. In practice, this probably will not be an issue, but in theory it ispossible. If you run into a problem whererssh
refuses to run, claiming to be rejecting insecure command line options whichwere not specified, try changing your command line such that all short
options are specified as single-letter option flags (e.g. -e -p instead of-ep) and make sure you separate arguments from their respective options by aspace (e.g. -p 123 instead of -p123). In virtually all cases, this shouldsolve the problem. Admittedly, an exhaustive search was not performed, but noproblematical cases were found which were likely to be common.The alternative would have been to include a complete command-line parser forrcp, rdist, and rsync; this was way out of the scope of this project. Inpractice, the existing parser should suffice. If, however, you find caseswhere it does not, please post details to the rssh mailing list. Detailsabout how to post to the mailing list can be found at the rssh homepage.
OpenSSH Versions and Bypassing rssh
Prior to OpenSSH 3.5, sshd
(8) will generally attempt to parse files inthe user's home directory, and may also try to run a start-up script from theuser's$HOME/.ssh
does not make use of the user's environment in any way. The relevant commandis executed by calling execv
(3) with the full path to the command, asspecified at compile time. It does not depend upon the user's PATH variable,or on any other environment variable.There are, however, several problems that can arise. This is due entirely tothe way the OpenSSH Project's sshd works, and is in no way the fault ofrssh
. For example, one problem which might exist is that, according tothe sshd
(8) man page from at least some releases of OpenSSH, thecommands listed in the$HOME/.ssh/rc
file are executed with/bin/sh
instead of the user's defined shell. This appears not to be the case on thesystems the author had available to test on; commands were executed using theuser's configured shell (rssh
), which did not allow the execution.However if it is true on your system, then a malicious user may be able tocircumventrssh
by uploading a file to$HOME/.ssh/rc
which will be executed by /bin/sh
on that system. If any releases (of OpenSSH) are, in fact, vulnerable to thisproblem, then it is very likely that they are only old, outdated versions. Solong as you are running a recent version of OpenSSH, this should not be aproblem as far as I can tell.If your sshd is
vulnerable to this attack, there is a workaround for this problem, though itis pretty restrictive.The user's home directory absolutely must not be writable by the user.
If it is, the user can use sftp to remove the directory or rename it, and thencreate a new one, and fill it up with whatever environment files they like. Forproviding file uploads, this means a user-writable directory must be created forthem, and they must be made aware of their inability to write into their homedirectory other than in this location.A second problem is that after authenticating the user, sshd also reads$HOME/.ssh/environment
to allow the user to set variables in their environment. This allows the userto completely circumvent rssh
by clever manipulation of such environment variables asLD_LIBRARY_PATH
to link the rssh binary against arbitrary shared libraries. In order toprevent this from being a problem, as of version 0.9.3, by defaultrssh
is now compiled statically. The restrictive work-around mentioned above willalso defeat this sort of attack.As of OpenSSH 3.5, sshd
now supports the optionPermitUserEnvironment
which is set to "no" by default. This option allows restricted shells likerssh
to function properly without requiring them to be linked statically. As ofrssh
version 1.0.1, the configure script should detect that OpenSSH 3.5 is present,and disable the default of static compilation.
A Note About Getting Help
If you are having trouble gettingrssh
working, or you think you've found a bug, please use the mailing list, anddo not e-mail medirectly
. You must sign up for the list in order to post. Information about how to signup is available on the rssh homepage. If you mail me directly with questions,I will almost certainly ignore you, or at the very least ask you to repostyour question on the mailing list. Please also feel free to provide feedbackabout rssh on the mailing list, whether positive or negative (especiallynegative).
The only exception to the above is if you believe you have found a securityproblem with rssh
. If that is the case, then please do
contact meprivately. If you are unable to find my direct contact info, post a message onthe mailing list requesting that I contact you about a potential securityproblem. Security problems should be dealt with privately, so that the threatcan be properly assessed, and so as not to needlessly endanger theinstallations of rssh
in production environments. I take securityproblems seriously, and will work to resolve them as quickly as possible.
Before you e-mail me (or the mailing list) with questions, be sure to THOROUGHLY
read all of the following files: README, INSTALL, CHROOT, SECURITY. All ofthese files are distributed with the rssh source code, as well as all binarypackages of rssh
. If you downloaded a binary package, these filesshould be located wherever your distribution keeps its documentation files(usually /usr/share/doc/rssh-version/ or something similar). Also THOROUGHLY
read the man pages for rssh
(1), and rssh.conf
(5). Finally, if youare still having problems, read the FAQ athttp://www.pizzashack.org/rssh/faq.shtml.
If it is clear to me that you havenot read these documents, I will ignore you. In most cases, these documentswill already have everything you need to get rssh working, and I won't be ableto explain it any better on a mailing list than I did in those documents...
- SECURITY NOTES
- Using rssh With CVS
- Potential root Compromise With Old Versions
- Safeguards Against Bypassing rssh
- Command Line Parser
- OpenSSH Versions and Bypassing rssh
- A Note About Getting Help
- Security Problems
- SEE ALSO
This document was created byman2html,using the manual pages.