similar to: openssh and chroot

Hi all, I am running Debian Etch. I've compiled openssh-5.0p1 with pam support. I'd like to use a chrooted sftp environment for my users and also log their sftp file transfers. Currently file transfer logging stops working when I implement a jail. Logging from within the chroot seems like a useful feature. I hope it makes it in sooner rather than later. Here's the contents of my

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

Le Jeudi 11 Avril 2002 21:09, m.ibarra at cdcixis-na.com a ?crit : > I was curious to know if you had any luck in getting openssh's sftp > server properly configured to allow chrooted sftp logins? I have had > no success and need something quickly. Dear Mike, Unfortunately, I did not succeed to have it work. I got in contact with James Dennis <jdennis at law.harvard.edu>, who

Hello Folks, I'm trying to replace an FTP with several hundred users with something secure. My requirements: - transfers must be logged - users should not have any access to other users' directories - users should land in a writable directory - users should be chrooted I've been trying to get this working with OpenSSH and the internal SFTP server, but it does not

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

Hi there, let me just ask if you know some good way to set up user chrooting in such a way, that each sftp user has its chroot directory entry somewhere (whatever path) and gets chrooted there upon its login? Maybe such feature is planned? Thanks... K.

Hello, Is there any security reason why the last component of a chroot path is required to be owned by root and not by the user that is chroot-ed into that path? I have tried to think of a reason, but cannot find any except for when several accounts are chrooted into the same directory. But if that is not the case, then, is there any security consideration? If not, then it seems to me that

Hi, I need to make a custom code change in sftp-server module to copy the received file outside the chroot-setup. I am trying to chroot repeatedly to get physical root directory and the copy received file to a directory outside chrooted directory. The children processes are owned by the sftp-user and so, sftp child process does not have permission to escape out of chroot. Is there a simple way

At the risk of beating a dead horse, I'd like to see the chroot security checks relaxed a bit. On newer Linux kernels, there's a prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) that prevents privilege elevation (via setuid binaries, etc) for the caller and all of its descendants. That means that chroot(untrusted directory), prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0), setreuid(uid, uid), execve(a

Hi Damien, Thank you. I read the rationale. Just to summarize, a user writeable chroot target is considered dangerous if: 1) the user has another way of gaining non-chrooted access to the system 2) is able to create hardlinks to setuid-binaries outside of the chroot tree 3) there are bugs somewhere that allow privilige escalation or remote execution of other programs While all these

Folks, I've been tasked to find a solution that will create file-transfer-only accounts that are jailed or chrooted to a specific directory. (Not an uncommon task, I think.) Using the OpenSSH server and the OpenSSH scp client program, I can achieve the goal of having a file transfer only account jailed to a specified directory, by using the "scpjail" script (attached) as a

Hello, I was trying to build a chrooted sftp account when I faced a problem. The chroot is done with the patch present in the contrib subdirectory in the portable version (I'm under linux slackware current). My problem is that verifying access rights on directories and files are too tight and then I couldn't have the following things : The user sftp, with primary group sftp, is chrooted

Hi, I have trouble setting up chrooted SFTP for our user. I got the basic SFTP chroot working, user is chrooted to its home directory, I've added /home/userb/etc directory with dummy passwd, group and localtime files. The problem is that instead of only accessing its own files, I need the user to be able to remove another users files. I have web application which runs as different user, the

https://bugzilla.mindrot.org/show_bug.cgi?id=2048 Priority: P5 Bug ID: 2048 Assignee: unassigned-bugs at mindrot.org Summary: Make chrooted sftp more user friendly using bind mount (solution suggested) Severity: enhancement Classification: Unclassified OS: Linux Reporter: harviecz at gmail.com

Currently, sshd requires the chroot directory to be owned by root. This makes it impossible to chroot users into their own home directory, which would be convenient for sftp-only users. Is there a particular reason why, in safely_chroot() in session.c, if (st.st_uid != 0 || (st.st_mode & 022) != 0) fatal("bad ownership or modes for chroot "

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

Hi, A question regarding chroot, internal-sftp, and time zones: Is it possible to get the time stamps presented by the chrooted internal-sftp to always be aligned with the system global time zone setting? What is the reason this not done by default, that is couldn't the chrooted internal-sftp inherit the time zone information from the SSH daemon? /John -- John Olsson Ericsson AB

Hi! I want to set a OpenSSH server which restricts some users to only chrooted SFTP, while others have full/normal ssh, scp and sftp access. Most or all guides on the web say that I should enable the config line "Subsytem sftp internal-sftp" among other things, but I've found out that this only causes non-restricted users to not be able use SFTP at all, only the chrooted users.

Hi, I've posted this question on ServerFault, but no answer has been found (http://serverfault.com/questions/431329/user-cant-sftp-after-chroot). I have version 1:5.3p1-3ubuntu7 To sum up: I want to chroot the user sam. Things I have done: - add user 'sam' to group 'users' - added Subsystem sftp internal-sftp to /etc/ssh/sshd_config (at the bottom) - added a Match : -- Match

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: