similar to: Running OpenSSH in a chroot without mounted proc on Linux

Hi, it seems the 2.5.0p1 announcement on www.openssh.com went out a little bit too early ;). Just curious, why 2.4 was skipped? I don't believe this is just to have a higher version number than the competition ;). I see 2.5.0 is there, but no 2.5.0p1 yet even on ftp.openbsd.org itself. Looking at the CVS tree, I see the two bugs I reported to this list some time ago (with no response) are

Hi everybody. I got a problem here. I want to use chroot + sshd service. env: RHEL 5.2 tail -1 /etc/pam.d/sshd session required pam_chroot.so debug tail /etc/security/chroot.conf terry /users ssh terry at 192.168.20.11 faile tail /var/log/secure Jun 7 05:05:40 node1 sshd[5397]: pam_chroot(sshd:session): chroot(/users) succeeded <- chroot /users succeeded Jun

Hello, looking at the pty handling in OpenSSH 2.3.0p1 (hasn't changed much in CVS, as far as I can tell after a quick look at it), I can see that if the system provides both /dev/ptmx and openpty() types of pty interface, the latter is preferred. This is the case on Linux with glibc 2.1.3 and most likely later versions too. However, openpty() is documented to be dangerous - quote from the

On Sun, May 4, 2008 at 12:00 PM, Dan Yefimov <dan at nf15.lightwave.net.ru> wrote: > On Sun, 4 May 2008, john wrote: > > > > What exact steps have you taken to accomplish what Damien proposed? > > > > > Yes sorry Dan, I should have been specific. > > > > I created a file in my chroot root called /home/dev/auth.log > > > > Then I

You must mean your most wanted feature. Mine is the integration of Simon's GSS patches. Nico -- > -----Original Message----- > From: Jean-Michel POURE [mailto:jm.poure at freesurf.fr] > Sent: Friday, May 17, 2002 7:35 AM > To: Markus Friedl; openssh-unix-dev at mindrot.org > Subject: OpenSSH 3.2.2 released : chroot > > > Le Vendredi 17 Mai 2002 00:36, Markus

I went through the chroot/selinux review when Centos6 came out. I went with selinux and no chroot. I don't have too much of an issue with systemd; I am learning it as I go. I am putting up a Samba4 AD with Bind-DLZ backend. The Samba wiki explicitly calls out no chroot and kind of explains why. so I come out on the selinux side. On 09/09/2015 09:09 PM, Tom Robinson wrote: > Hi All,

Hi All, I'm migrating a CentOS 6 bind instance (chrooted) to a CentOS 7 box and am curious of people's opinions on chrooting vs selinux as a way of securing bind. The bind-chroot on CentOS 7 also comes with a script (/usr/libexec/setup-named-chroot.sh) that sets up the much maligned systemd and, through bind mounts, creates and extra level of chroot hierarchy giving:

Hi there, everyone; I've had a few requests for an updated version of my chroot patch. (the version found in contrib is outdated) So, here it goes, updated to 2.3.0p1; "chroot.diff" is a plain diff for session.c (apply, compile and go). "chroot+configure.diff" is the same patch, plus an option to "configure" for enabling/disabling chroot support (./configure

I am wondering what modifications to the chroot patch in the contrib directory for openssh would be necessary for it to be accepted into the standard release. Is anybody currently working on chroot for openssh? I would be willing to work on improving and testing the patch if I knew it would become a standard part of openssh. My main interest in a chrooted openssh is to provide chrooted sftp so I

openssh-2.9.9p2 assumes that pid_t, uid_t, gid_t, and mode_t are no wider than int. GCC complains about this assumption on 32-bit Solaris 8 sparc, where these types are 'long', not 'int'. This isn't an actual problem at runtime on this host, as long and int are the same width, but it is a problem on other hosts where pid_t is wider than int. E.g., I've heard that 64-bit

After upgrading to openssh-2.5.2p2, my users were unable to login using ssh Protocol 1. Entries like this were showing up in syslog: Apr 5 19:29:45 maple sshd[16726]: Accepted password for anthonyu from ::ffff:192.168.0.2 port 1019 Apr 5 19:29:45 maple sshd[16726]: fatal: stat(/dev/pts/1 19:29:45 sshd[16726]: Accepted password for anthonyu) failed: No such file or directory Apr 5 19:29:45

Dear sirs, I tried to compile openssh-5.0p1 on a IRIX machine with gcc. "/sbin/uname -a" gives: IRIX o2 6.5 07202013 IP32 mips and "/sbin/uname -R" gives: 6.5 6.5.30f "gcc -v" gives: Reading specs from /usr/freeware/lib/gcc-lib/mips-sgi-irix6.5/3.3/specs Configured with: ../configure --prefix=/usr/freeware --enable-version-specific-runtime-libs --disable-shared

Hello, I'm trying to add a feature to the ssh daemon. It consists in log all the buffer session between client and server side into a log file. I've coded a shell that works with pipes, it opens 2 fds for each std (you can see code at the end) and so the communication can be transferred to the client end point, the server side and to the log file. My goal is to patch it into ssh, but for

http://bugzilla.mindrot.org/show_bug.cgi?id=779 Summary: Chroot environment for sftp client crazy Product: Portable OpenSSH Version: 3.7.1p2 Platform: Other URL: http://aixpanish.com OS/Version: AIX Status: NEW Severity: normal Priority: P2 Component: sftp-server AssignedTo:

Hi all: I'm looking to chroot sftp; but not chroot ssh sessions. I came across some info that said this is possible. But after searching this list's archives and Google, I was rather confused about the different patches for chrooting, and couldn't find anything that appeared to only chroot sftp. Is such a patch available? Can someone point me in the right direction? Erik

I've been trying to get openssh to play nicely with chroot()'ed accounts (on Red Hat Linux 7.1), but so far, I haven't had much success. I can stick this line in /etc/pam.d/sshd: session required /lib/security/pam_chroot.so debug onerr=fail For slogin, this works great. But scp and sftp don't apply the chroot, because they don't invoke do_pam_session(). Even worse, I

At the moment, if you start an rsyncd that's not running as root using default settings it will have some trouble. rsyncd tries to use chroot by default, but this will always fail if it's not started by root. It does emit an error message in this case, but I wonder if some people find this a bit confusing until they discover the setting. I have in the past. It might be better that if

The way this was last supplied to this list (2002-07-13) has the chroot after the call to 'setpcred'. In AIX 4.3.3 the call to setpcred changes the uid and eff. uid to the user attempting to logon. Then the call to chroot( new_home ) fails because AIX requires that any user issuing the chroot subroutine be at root authority. Net result: attempting to do a chroot after the call to

--- helper/init.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/helper/init.c b/helper/init.c index 0ca3135..2b5dacf 100644 --- a/helper/init.c +++ b/helper/init.c @@ -163,8 +163,10 @@ main () chdir ("/"); - /* Run /init from ext2 filesystem. */ + mount_proc (); print_uptime (); + + /* Run /init from ext2 filesystem. */ execl

On Tue, Dec 01, 2015 at 04:58:11PM +0000, Richard W.M. Jones wrote: > On Tue, Dec 01, 2015 at 03:59:56PM +0100, Mateusz Guzik wrote: > > CHROOT_IN/OUT around commandvf are definitely problematic. chroot should be > > done in the child, which also removes the need to chroot out in the > > parent. > > The CHROOT_IN/OUT business does need to be rewritten. Every >