I suggest to run another sshd daemon *inside the chroot environment*. That will allow to allocate a pseudo-terminal correctly. Since the chrooted environment has no access to pts of the parent system (where you want to run sshd) - you will not able to run such apps as GNU Screen (for an example) inside the chrooted environment until you run sshd inside it (also you have to mount /proc and /dev/pts). Check it out. Also if there some security holes will be founded in the future then cracking of the child sshd will not cause obtaining the parent system control.
Also you must note that if some user have root access in the chrooted envronment - then he can break it out and escape outside it. I suppose to use a modified linux kernel with grsecruity patches (http://grsecurity.net) - there is a lot of useful features include the chroot restrictions. On Thu, Apr 26, 2012 at 12:27 PM, Colin Watson <[email protected]> wrote: > On Thu, Apr 26, 2012 at 08:46:35AM +0200, Ph. Marek wrote: > > I asked on openssh-unix-dev, and they said that there's a patch already > > available: > > > http://lists.mindrot.org/pipermail/openssh-unix-dev/2012-April/030399.html > > > > > > Please integrate that into the debian packages, thank you so much. > > This patch makes configuration changes; I won't add any more such > patches to the Debian package until they've actually been committed > upstream, not merely discussed on the upstream mailing list. Darren has > upstream commit access, so if he's confident in that patch he's entirely > capable of committing it. > > -- > Colin Watson [[email protected]] > > > > -- > To UNSUBSCRIBE, email to [email protected] > with a subject of "unsubscribe". Trouble? Contact > [email protected] > Archive: > http://lists.debian.org/[email protected] > >
