[PLUG] setting up SSH to chrrot to user homeDir

Josh Orchard josh at emediatedesigns.com
Sat Jul 22 11:06:50 UTC 2006


Tim,

Thanks for all the help.  I understand all that I have to do.  I have 
rbash setup and working.  I've set up the new bin folder and working on 
setting up the needed binaries. 

One last question.  Can I put 'cd' in the bin directory and have it not 
change directories out of the homeDir?  Or is their a way to limit a cd 
command so they can at least change directories inside a homeDir? 

Thanks for all the help.

Josh


Tim Slighter wrote:
> Please make the following corrections to the aliases as the alias 
> command does not accept "/".
>
> alias sh='rbash'
> alias csh='rbash'
> alias ksh='rbash'
> alias tcsh='rbash'
> alias unalias='rbash'
> alias chsh='rbash'
>
>
> etc.....
>
> If you want to lock out shell access in mail, just drop in a .mailrc 
> file in their home directory with "unset shell" in it and chattr +i 
> the file and you should be all set.  I just did it on my system with a 
> new user and they cannot escape the shell or working directory.
>
> On 7/21/06, *Tim Slighter* <tcslighter at gmail.com 
> <mailto:tcslighter at gmail.com>> wrote:
>
>     There is one thing i thought of that can bite you in the behind
>     and that is the ssh keys.  when you generate the user's ssh keys
>     (ssh-keygen -t dsa), make sure that the keys go directly into the
>     users home directory and not into ~/.ssh or the user will never be
>     able to successfully ssh to the
>     system.  Because remember that rbash does not allow cd into any directory except the working directory.
>
>
>     On 7/21/06, *Tim Slighter* < tcslighter at gmail.com
>     <mailto:tcslighter at gmail.com>> wrote:
>
>         pretty easy, just use the alias command in their .bashrc file
>         like this
>
>         alias sh='/bin/rbash'
>         alias ksh='/bin/rbash'
>         alias csh='/bin/rbash'
>         alias bash='/bin/rbash'
>         alias tcsh='/bin/rbash'
>         alias unalias='/bin/rbash'
>
>         And add to that any other shells that might possibly be on the
>         system such as ash or zsh etc...then make both .bashrc and
>         .bash_profile immutable using chattr +i /home/user1/.bashrc
>         and chattr +i /home/user1/.bash_profile.  Make you test
>         everything out first that you have implemented before you do
>         the chattr or you have to chattr -i all of them, make your
>         changes and then back to immutable.  The way I did it is by
>         allowing them access to very few binaries such as vi, ls, cat,
>         grep and mail (you can definitely add others) and I copied all
>         of these files into a new directory /usr/progs and then put
>         that directory as the only path in their .bashrc and
>         .bash_profile files.  Be careful about dropping vi in their as
>         that will allow them an escape shell so you might have to
>         download vim, but if you already have it then do the same
>         thing as with bash and copy the vim binary to rvim and then
>         copy that to the /usr/progs directory.  Also check the mail
>         utility if you are going to use it to make there is no escape
>         shell or you will also have to address that issue.  the less
>         access you give them to programs, the less likely they are to
>         break out of a shell.  You may also want to prevent them from
>         accessing the chsh utility and might have to alias that to
>         '/bin/rbash' as well.  Then just test it out locally using
>         your extra screen consoles (alt - F2 - alt - F3 etc..) and log
>         in as that user and try anything and everything possible to
>         break out of your shell and to also break out of your working
>         directory.  Eventually you will get it and then you can chattr
>         +i those two files.
>
>
>         On 7/21/06, *Josh Orchard* < josh at emediatedesigns.com
>         <mailto:josh at emediatedesigns.com>> wrote:
>
>             Tim,
>
>             Reading backwards on post this sounds like the only option
>             there is.
>             Too bad. I would have liked an easier way to accomplish
>             this.  I like
>             SSH but do to it's nature of sharing the entire computer
>             file system I
>             have elected to not allow it.  Now I need to and I'm
>             trying to judge
>             rather to just allow and trust all SSH users or find a
>             more secure way
>             of giving them access but locking their ability.
>
>             When you mentioned that you did a Chattr on the files I'm
>             unfamiliar
>             with this.  I see it is like chmod but I think not the
>             same.  I see by
>             putting a +i with chattr on a file that prevents a user
>             from modifying
>             the files.  Hmm, okay the more I write the more I
>             understand.  Perhaps I
>             could do this without too much more.
>
>             How do I get the other shells to re-route back to rbash?
>
>             Thanks,
>
>             Josh
>
>             Tim Slighter wrote:
>             > The rbash idea is a good one but there are still many
>             more steps to
>             > take to
>             > make sure the user stays within that shell and within the
>             confines of
>             > their
>             > home directory.  You have to create a directory somewhere
>             like /usr/progs
>             > and put the binaries and only the binaries that you want
>             the user to have
>             > access to and then declare that directory and the users
>             only path in
>             > their
>             > .bash_profile or .bashrc or both.  Better off if any
>             programs with
>             > potential
>             > shell escapes like pine, vi, emacs etc, are all replaced
>             with a
>             > restricted
>             > version of the binary such as rvi or rvim, etc.  You will
>             also need to
>             > declare restrictive aliases for each user to prevent them
>             access to any
>             > other shells so declare an alias for ksh to /bin/rbash
>             and csh ->
>             > /bin/rbash, so what you are doing here is making sure
>             that any shell they
>             > attempt to get to will always put them back into and keep
>             them in rbash.
>             > Make sure also that you prevent them from using the
>             unalias command by
>             > declaring that to /bin/rbash as well and then you must
>             prevent the
>             > user from
>             > modifying the file so do a chattr +i on the .bashrc or
>             .bash_profile
>             > files
>             > in their home directories.  I did manage to do this but
>             it was a pain and
>             > quite a bit of work and a lot of trial and error.  Feel
>             free to ask
>             > questions if you need help with this.
>             >
>             > On 7/21/06, Larry Brigman < larry.brigman at gmail.com
>             <mailto:larry.brigman at gmail.com>> wrote:
>             >>
>             >> On 7/20/06, Josh Orchard < josh at emediatedesigns.com
>             <mailto:josh at emediatedesigns.com>> wrote:
>             >> > Hello all,
>             >> >
>             >> > Been looking about the wonderful web and reading about
>             how I could
>             >> > achieve this but all that I've found makes it sound
>             like I need to
>             >> setup
>             >> > yet another customer product of sorts.  So...
>             >> >
>             >> > Is there a way that I can configure SSHD to allow
>             clients to login but
>             >> > be chrooted to their home directory?
>             >> >
>             >> > FTP does this well and I would like to have it do the
>             same for SSHD.
>             >> > I'm actually surprised this isn't a configuration
>             option on OpenSSH as
>             >> > it would make sense that you would want to allow
>             certain shell access
>             >> > but not allow all people to go about browsing your
>             entire server.
>             >> >
>             >> > So, is this possible?  Do I need some sort of custom
>             SSH or is there
>             >> > another program I can use to give secure Shell access?
>             >> >
>             >>
>             >> What about setting the users shell to rbash or bash -r.
>             >>
>             >> >From the bash man page:
>             >> RESTRICTED SHELL
>             >>        If bash is started with the name rbash, or the -r
>             option is
>             >> supplied at
>             >>        invocation,  the  shell becomes restricted.  A
>             restricted
>             >> shell is
>             >> used
>             >>        to set up an environment more controlled than the
>             >> standard  shell.   It
>             >>        behaves  identically  to bash with the exception
>             that the
>             >> following
>             >> are
>             >>        disallowed or not performed:
>             >>
>             >>              changing directories with cd
>             >>              setting or unsetting the values of SHELL,
>             PATH, ENV, or
>             >> BASH_ENV
>             >>              specifying command names containing /
>             >>              specifying  a  file  name containing a / as
>             an argument to
>             >> the .
>             >>                 builtin command
>             >>              Specifying a filename containing a slash as an
>             >> argument  to  the
>             >>                 -p option to the hash builtin command
>             >>              importing  function  definitions  from  the
>             shell
>             >> environment
>             >> at
>             >>                 startup
>             >>              parsing the value of SHELLOPTS
>             >> from  the  shell  environment  at
>             >>                 startup
>             >>              redirecting  output using the >, >|, <>,
>             >&, &>, and >>
>             >> redirec-
>             >>                 tion operators
>             >>              using the exec builtin command to replace
>             the shell with
>             >> another
>             >>                 command
>             >>              adding  or  deleting builtin commands with
>             the -f and -d
>             >> options
>             >>                 to the enable builtin command
>             >>              Using
>             >> the  enable  builtin  command  to  enable  disabled  shell
>             >>                 builtins
>             >>              specifying the -p option to the command
>             builtin command
>             >>              turning off restricted mode with set +r or
>             set +o
>             >> restricted.
>             >> _______________________________________________
>             >> PLUG mailing list
>             >> PLUG at lists.pdxlinux.org <mailto:PLUG at lists.pdxlinux.org>
>             >> http://lists.pdxlinux.org/mailman/listinfo/plug
>             <http://lists.pdxlinux.org/mailman/listinfo/plug>
>             >>
>             > _______________________________________________
>             > PLUG mailing list
>             > PLUG at lists.pdxlinux.org <mailto:PLUG at lists.pdxlinux.org>
>             > http://lists.pdxlinux.org/mailman/listinfo/plug
>             >
>             _______________________________________________
>             PLUG mailing list
>             PLUG at lists.pdxlinux.org <mailto:PLUG at lists.pdxlinux.org>
>             http://lists.pdxlinux.org/mailman/listinfo/plug
>             <http://lists.pdxlinux.org/mailman/listinfo/plug>
>
>
>
>




More information about the PLUG mailing list