Openssh 4.9p1 - chroot jail - /dev/pts/3: Permission denied

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

I'm trying to set up openssh 4.9p1 to have my user logging into a
chroot jail.
OS is RHEL 4.0 and openssh was compiled from sources.
The chroot directory and their parents are owned by root and are not
word writable.
I have /proc /dev and /dev/pts mounted with -o bind in my jail.

Starting the server with -ddd I see the following errror in the logs
and the session is closed:

debug1: server_input_channel_req: channel 0 request shell reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug2: fd 3 setting TCP_NODELAY
debug2: channel 0: rfd 9 isatty
debug2: fd 9 setting O_NONBLOCK
debug3: fd 8 is O_NONBLOCK
debug1: Setting controlling tty using TIOCSCTTY.
/dev/pts/3: Permission denied
open /dev/tty failed - could not set controlling tty: Permission
debug1: Received SIGCHLD.

/dev/tty has permissions 0666.

in /var/log/messages I see:
Oct 19 21:59:13 pe423 sshd[25473]: Accepted password for aaa from port 36363 ssh2
Oct 19 21:59:13 pe423 sshd[25475]: Changed root directory to "/home/

I've done extensive researches on google, unfortunately, with no luck.

Has someone ever encountered this problem and can point me in the
right direction?

Any help is highly appreciated :)


Re: Openssh 4.9p1 - chroot jail - /dev/pts/3: Permission denied

Quoted text here. Click to load it

Stop right there. I used to publish patches for chroot jails way, way
back in OpenSSH development. (Just the patches, they were never
accepted upstream as being too potentially awkward on a very tightly
developed tool.) It's a nasty process, and I don't recommend it. If
all you need is upload/download in a cage, done securely, use vsftpd
with FTPS or WebDAV on HTTPS, both of which plenty of client tools

RHEL 4 is roughly 6 years old, RHEL 5 is over 3 years old. Backporting
OpenSSH that far is painful, and twisting your environment to support
chroot cages is even more awkward in such an out of date system.

Quoted text here. Click to load it

Yes. Don't do this. Explain what you're trying to achieve, and maybe
we can offer some pointers.

Re: Openssh 4.9p1 - chroot jail - /dev/pts/3: Permission denied

Hi Nico,

Thank you for your reply.

Quoted text here. Click to load it

Unfortunately, I've received the same advise already.

Quoted text here. Click to load it

I have to gain full access to a user to one of our systems.
The user needs to be able to edit or upload configuration files for a
daemon that runs 'self-contained' within the jail.
Furthermore he needs to be able to restart/reload the daemon and run
one other command via sudo.

Quoted text here. Click to load it

I imagined that and decided to give it a try anyway. I'm stick to REHL
4 due to some software that runs on top of it and will be migrated
some where in the future.

FYI: I've other (old) openssh installations patched with this patch[1]
and, as far as I can see, they're working fine.

Quoted text here. Click to load it

Thanks. Any suggestion is more than welcome :)


[1] /

Re: Openssh 4.9p1 - chroot jail - /dev/pts/3: Permission denied

Gabriele Paggi 697584 wrote:
Quoted text here. Click to load it

Any sysadmin with the root password or listed in the sudoers file can do
all of that without a chroot jail.  The application may be to run in a
jail but its administrative user does not need to.  Much less hassle
than building a chroot jail on an old system.

Re: Openssh 4.9p1 - chroot jail - /dev/pts/3: Permission denied

Quoted text here. Click to load it

Daemons need not run as root. They can be run via "su" as specified
users, or via xinetd as alternate users. (svnserve is often configured
this way.).

Which daemon? If it's xinetd based, or can be so configured, the
daemon will automatically run as a non-root user and grab whatever
configuration files you tell it are relevant. There also used to be
technologically interesting but hideously fragile tool for just this
purpose, written by Dan Bernstein, called daemontools. The fragility
was in the layout (which did not follow the File System Hierarchy and
made horrid management issues), and the tendency of typical user
written init scripts to be horrid. But it could work for a modest one

Even if the daemon is run by root, such as the Apache daemon, it
should be possible to allow your user sudo access to only that Apache
daemon. init script, and leave the relevant config files as owned by
him. I therefore suspect that you can readily avoid the "OpenSSH chrot
cage" issue.

Re: Openssh 4.9p1 - chroot jail - /dev/pts/3: Permission denied

Nico Kadel-Garcia wrote:
Quoted text here. Click to load it

Exactly.  The administrator's need is not the same as the application's
need.  It works fine for the administrator to have the root password for
"su -" or to use "sudo" with no need at all to be in an chroot jail and
use that access to control and configure an application that runs in a
chroot jail.

Quoted text here. Click to load it

As long as there are scripts or commands to start, stop and configure
the daemon in its chroot jail, the user running those commands has no
need for the jail.

Untrusted users are a different issue than controlling a daemon.  I've
used restricted shell for untrusted users on various other UNIX versions
but so far not on Linux.  It's getting to the point where I want a
custom untrusted account to do print queue maintenance as it's coming up
more and more.

Site Timeline