1RSSH(1) Derek D. Martin RSSH(1)
2
6 rssh - restricted secure shell allowing only scp and/or sftp
7
9 rssh [ options... ] [ ... ]
10 rssh -v
11
13 rssh is a restricted shell for providing limited access to a host via
14 ssh(1), allowing a user whose shell is configured to rssh to use one or
15 more of the command(s) scp(1), sftp(1) cvs(1), rdist(1), and rsync(1),
16 and only those commands. It is intended primarily to work with OpenSSH
17 (see http://www.openssh.com), but may work with other implementations.
18 The system administrator should install the shell on the restricted
20 system. Then the password file entry of any user for whom it is
21 desireable to provide restricted access should be edited, such that
22 their shell is rssh. For example:
23 luser:x:666:666::/home/luser:/usr/bin/rssh
25 If invoked with the -v option, rssh will report its version, and exit.
27 All other arguments to rssh are those specified by the remote ssh(1)
28 client, and aren't of much concern to the average user. The arguments
29 provided must be what a shell on the remote end would receive in order
30 to pass control to scp(1), sftp(1), etc. If rssh receives arguments
31 which do not conform, it will emit an error message and exit. If the
32 program the user is trying to run is not allowed, or contains syntax
33 which will try to execute a shell command (such as a command substitu‐
34 tion), it will also emit an error and exit.
35 rssh has a configuration file, rssh.conf(5), which allows some of the
37 behavior of rssh to be customized. See that man page for details.
38
40 Read this section with exceptional care, or you may put your system at
41 risk!
42 Using rssh With CVS
44 If you are using rssh to allow CVS access, it should be noted that it
45 is not possible to prevent a user who is very familiar with CVS from
46 bypassing rssh and getting a shell, unless the user does not have write
47 access in the repository. Obviously, the user must have write access
48 to the repository in order to update it, which allows them to upload
49 arbitrary programs into the repository. CVS provides several mecha‐
50 nisms for executing such arbitrary programs... The only reasonably
51 safe way to use rssh with CVS is to use the chroot jail facilities to
52 place the CVS repository within a chroot jail. Please see below and
53 all relevant documentation for details of how to set up chroot jails.
54 Note that users will still be able to get shell access within the jail;
55 the only protection which is provided is that they can not escape the
56 jail. I have been pursuaded to retain support for CVS because this
57 protection is better than no protection. You have been warned. Use CVS
58 at your own risk.
59 Potential root Compromise With Old Versions
61 Before rssh 2.3.0, if a regular user had shell access to a machine
62 where rssh was installed, a root compromise was possible due to
63 rssh_chroot_helper allowing a user to arbitrarily chroot(2) to anywhere
64 on the filesystem. It is possible to mitigate this attack against
65 affected versions of rssh using strict access controls to files, by
66 making sure that the user can not write to any file on the same parti‐
67 tion as system executables, and that any partition where they can write
68 files does not allow execution of SUID programs. As of rssh 2.3.0,
69 this attack has been prevented by preventing arbitrary chroot(), if
70 your jail is set up securely. In particular, make sure that regular
71 users can not write to directories inside the jail which contain the
72 copied binaries. That should be obvious, but it needs to be said.
73 Though it should not be strictly necessary, to further protect your
74 system from possible compromise, it is also advisable to follow the
75 section below, entitled "Safeguards Against Bypassing rssh".
76 Safeguards Against Bypassing rssh
78 rssh is designed to interact with several other programs. Even if rssh
79 is completely bug-free, changes in those other programs could possibly
80 result in methods to circumvent the protection that rssh is intended to
81 provide. It is important for you, the system administrator, to stay
82 current on the services you make available with rssh, to be sure that
83 these commands do not provide mechanisms to allow the user to run arbi‐
84 trary commands. Also, while the goal of every release is to be bug
85 free, no one is perfect... There may be undiscovered bugs in rssh
86 which might allow a user to circumvent it.
87 You can protect your system from those who would take advantage of such
89 weaknesses. This is not required for rssh to work properly, but it is
90 a really good idea. There are six basic steps:
91 1. protect all non-administrator accounts with rssh (i.e. no
93 regular user should have shell access to the server)
94 2. place your users in a chroot jail
96 3. limit the binaries which live in the jail to the absolute
98 minimum required
99 4. mount their home filesystem with the noexec/nosuid option
101 (i.e. use separate partitions in the jail for user home
102 directories and all other files, if possible/reasonable)
103 5. create a group for rssh users, and limit executable
105 access to the binaries to users in that group.
106 6. use standard file permissions carefully and appropriately
108 If possible, make sure that no regular user has any kind of shell
110 access to the system other than through rssh. Otherwise, users with
111 shell access could potentially exploit undiscovered bugs in
112 rssh_chroot_helper to gain root access to the server.
113 rssh gives the system administrator the ability to place the users in a
115 chroot jail. See details in the man page for rssh.conf and in the file
116 CHROOT which is distributed with the source code. If you want to
117 ensure users can not run arbitrary programs, use a chroot jail, and be
118 sure not to put any programs other than what are absolutely necessary
119 to provide the service you are trying to provide. This prevents them
120 from running standard system commands.
121 Then, make sure the user's files inside the jail are on a seperate
123 filesystem from your system's executables. If possible in your envi‐
124 ronment, make sure you mount this filesystem using the noexec and
125 nosuid options, if your operating system provides them. This prevents
126 the users from being able to execute programs which they have uploaded
127 to the target machine (e.g. using scp) which might otherwise be exe‐
128 cutable, and prevents SUID programs from respecting the SUID bits.
129 Note that these options necessitate the users' files are on separate
130 partitions from the binaries and libraries that live in the jail.
131 Therefore you will need at least 2 partitions for your jail to do this
132 properly (one for the system binaries in the jail, the other for the
133 user directories).
134 Additionally, create a group, for example "rsshuser", for rssh users.
136 Put all your users who will be restricted by rssh in that group. Set
137 the ownership and permissions on rssh and rssh_chroot_helper so that
138 only those users can execute them. The following commands should
139 illustrate:
140 # groupadd rsshuser
142 # chown root:rsshuser rssh rssh_chroot_helper
143 # chmod 550 rssh
144 # chmod 4550 rssh_chroot_helper
145 Lastly, use standard Unix/POSIX file permissions to ensure they can not
147 access files they should not be able to within the chroot jail.
148 Command Line Parser
150 As of rssh version 2.2.3, the program must parse out the complete com‐
151 mand line to avoid command line options which cause the execution of
152 arbitrary programs (and hence bypass the security of rssh). In order
153 to keep the program source code sane, the parser is a little over-zeal‐
154 ous about matching command line options. In practice, this probably
155 will not be an issue, but in theory it is possible.
156 If you run into a problem where rssh refuses to run, claiming to be
158 rejecting insecure command line options which were not specified, try
159 changing your command line such that all short options are specified as
160 single-letter option flags (e.g. -e -p instead of -ep) and make sure
161 you separate arguments from their respective options by a space (e.g.
162 -p 123 instead of -p123). In virtually all cases, this should solve
163 the problem. Admittedly, an exhaustive search was not performed, but
164 no problematical cases were found which were likely to be common.
165 The alternative would have been to include a complete command-line
167 parser for rcp, rdist, and rsync; this was way out of the scope of this
168 project. In practice, the existing parser should suffice. If, how‐
169 ever, you find cases where it does not, please post details to the rssh
170 mailing list. Details about how to post to the mailing list can be
171 found at the rssh homepage.
172 OpenSSH Versions and Bypassing rssh
174 Prior to OpenSSH 3.5, sshd(8) will generally attempt to parse files in
175 the user's home directory, and may also try to run a start-up script
176 from the user's $HOME/.ssh directory. rssh does not make use of the
177 user's environment in any way. The relevant command is executed by
178 calling execv(3) with the full path to the command, as specified at
179 compile time. It does not depend upon the user's PATH variable, or on
180 any other environment variable.
181 There are, however, several problems that can arise. This is due
183 entirely to the way the OpenSSH Project's sshd works, and is in no way
184 the fault of rssh. For example, one problem which might exist is that,
185 according to the sshd(8) man page from at least some releases of
186 OpenSSH, the commands listed in the $HOME/.ssh/rc file are executed
187 with /bin/sh instead of the user's defined shell. This appears not to
188 be the case on the systems the author had available to test on; com‐
189 mands were executed using the user's configured shell (rssh), which did
190 not allow the execution. However if it is true on your system, then a
191 malicious user may be able to circumvent rssh by uploading a file to
192 $HOME/.ssh/rc which will be executed by /bin/sh on that system. If any
193 releases (of OpenSSH) are, in fact, vulnerable to this problem, then it
194 is very likely that they are only old, outdated versions. So long as
195 you are running a recent version of OpenSSH, this should not be a prob‐
196 lem as far as I can tell.
197 If your sshd is vulnerable to this attack, there is a workaround for
199 this problem, though it is pretty restrictive. The user's home direc‐
200 tory absolutely must not be writable by the user. If it is, the user
201 can use sftp to remove the directory or rename it, and then create a
202 new one, and fill it up with whatever environment files they like. For
203 providing file uploads, this means a user-writable directory must be
204 created for them, and they must be made aware of their inability to
205 write into their home directory other than in this location.
206 A second problem is that after authenticating the user, sshd also reads
208 $HOME/.ssh/environment to allow the user to set variables in their
209 environment. This allows the user to completely circumvent rssh by
210 clever manipulation of such environment variables as LD_LIBRARY_PATH or
211 LD_PRELOAD to link the rssh binary against arbitrary shared libraries.
212 In order to prevent this from being a problem, as of version 0.9.3, by
213 default rssh is now compiled statically. The restrictive work-around
214 mentioned above will also defeat this sort of attack.
215 As of OpenSSH 3.5, sshd now supports the option PermitUserEnvironment
217 which is set to "no" by default. This option allows restricted shells
218 like rssh to function properly without requiring them to be linked
219 statically. As of rssh version 1.0.1, the configure script should
220 detect that OpenSSH 3.5 is present, and disable the default of static
221 compilation.
222
224 None. =8^)
225 A Note About Getting Help
227 If you are having trouble getting rssh working, or you think you've
228 found a bug, please use the mailing list, and do not e-mail me
229 directly. You must sign up for the list in order to post. Information
230 about how to sign up is available on the rssh homepage. If you mail me
231 directly with questions, I will almost certainly ignore you, or at the
232 very least ask you to repost your question on the mailing list. Please
233 also feel free to provide feedback about rssh on the mailing list,
234 whether positive or negative (especially negative).
235 Security Problems
237 The only exception to the above is if you believe you have found a
238 security problem with rssh. If that is the case, then please do con‐
239 tact me privately. If you are unable to find my direct contact info,
240 post a message on the mailing list requesting that I contact you about
241 a potential security problem. Security problems should be dealt with
242 privately, so that the threat can be properly assessed, and so as not
243 to needlessly endanger the installations of rssh in production environ‐
244 ments. I take security problems seriously, and will work to resolve
245 them as quickly as possible.
246 N.B.:
248 Before you e-mail me (or the mailing list) with questions, be sure to
249 THOROUGHLY read all of the following files: README, INSTALL, CHROOT,
250 SECURITY. All of these files are distributed with the rssh source
251 code, as well as all binary packages of rssh. If you downloaded a
252 binary package, these files should be located wherever your distribu‐
253 tion keeps its documentation files (usually /usr/share/doc/rssh-ver‐
254 sion/ or something similar). Also THOROUGHLY read the man pages for
255 rssh(1), and rssh.conf(5). Finally, if you are still having problems,
256 read the FAQ at http://www.pizzashack.org/rssh/faq.shtml. If it is
257 clear to me that you have not read these documents, I will ignore you.
258 In most cases, these documents will already have everything you need to
259 get rssh working, and I won't be able to explain it any better on a
260 mailing list than I did in those documents...
261
263 rssh.conf(5), sshd(8), ssh(1), scp(1), sftp(1).
264man pages 1 Aug 2010 RSSH(1)