[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