similar to: OpenSSH + chroot + SELinux = broke

Hi, (please CC me as I'm not subscribed to the list) If compiled with SELinux support, OpenSSH 4.8 current cvs fails for accounts where the new ChrootDirectory option is active : debug1: PAM: establishing credentials debug3: PAM: opening session debug2: User child is on pid 1695 debug3: mm_request_receive entering debug1: PAM: establishing credentials debug3: safely_chroot: checking

Currently I have a RH6.1 host with selinux enabled On this I am running a LXC container with ubuntu (without selinux) with OpenSSH_5.3p1 Debian-3ubuntu4, OpenSSL 0.9.8k 25 Mar 2009 when I try to do a ssh connection to the lxc container I get : ... debug1: Next authentication method: password root at 192.168.2.11's password: debug1: Authentication succeeded (password). debug1: channel 0: new

Hi, Is anyone chrooting users that connect through SSH? I looked for it on Google and I basically saw several methods: - OpenSSH 5 supports ChrootDirectory (FC9 apparently has RPMs that probably could be rebuilt under CentOS 5) - There seem to be several patches for OpenSSH 4.x to do the chroot, the most popular seems to be http://chrootssh.sf.net/ - There appears to be a pam_chroot - There are

Note: I am digest subscriber so if you could copy me directly on any reply to the list I would appreciate it very much. I sent this to the OpenSSH list (secureshell at securityfocus.com) yesterday and received no response so I am asking here in hopes that someone else has run across this problem on CentOS. We have encountered a situation that requires sftp access to one of our server by an

Hope ya'all can help! Been reading and reading, and adjusting... to no avail. We need to have chroot'd SFTP activities logged on a file server and for whatever reason, I simply cannot get it to log with users that are chroot'd (this is necessary for auditing and HIPAA - so it is pretty important) I have tried with Fedora 11/12 and even an older Fedora 8 server, the same results: 1.

The sshd server has what I think is a serious flaw. There appears to be no way to turn off remote command execution. (someone please correct me if I am wrong). We have a server which uses a chroot jail, and rbash to severely limit what users can do on our system. The remote command bypasses all of that. ie. ssh user at host cat /etc/passwd will display the password file for the live system

[Not subscribed to this list, so please respond directly if you need to speak to me] In man5/sshd_config.5, a permissible keyword in a 'Match' block is missing. It currently lists only: AllowTcpForwarding, Banner, ForceCommand, GatewayPorts, GSSApiAuthentication, KbdInteractiveAuthentication, KerberosAuthentication, PasswordAuthentication, PermitOpen, PermitRootLogin,

https://bugzilla.mindrot.org/show_bug.cgi?id=2036 Priority: P5 Bug ID: 2036 Assignee: unassigned-bugs at mindrot.org Summary: Add %g user group name parameter for ChrootDirectory Severity: enhancement Classification: Unclassified OS: Linux Reporter: sue at pennine.com Hardware: ix86 Status:

Hello, I'm new to the list, but hopefully I've done enough digging around that I don't get yelled at too terribly ;) We're looking to implement a chrooted environment for allowing users to scp files from servers. That's basically the only functionality that we need in this case. We're looking to chroot the user and/or remove any chance that the account can login via

Under "ChrootDirectory" there is a line that says, "This path, and all its components, must be root-owned directories that are not writable by any other user or group." When I first read this "all its components" seemed to mean that all directories and files within this directory must be root owned and root only writable. This seemed odd as I would not be able to

Hi I'm using Centos 5 with Openssh-5.0p1 installed (and OpenSSL 0.98b and Zlib 1.2.3-3). I've managed to get a chroot'd SFTP session using ChrootDirectory and the new built-in SFTP subsystem. However, when I use SSH to connect to the same account the session hangs rather than closing the connection. This happens whether or not I use /sbin/nologin /bin/false or even /bin/sh

Hello, I'm aware of the fact that ChrootDirectory requires that the target directory is root-owned, and I think I've mostly understood why that is necessary, at least within the context of someone who has full shell access. However, I am wondering if that possibility for privilege escalation still exists with a configuration like this: Match Group sftp ForceCommand internal-sftp

https://bugzilla.mindrot.org/show_bug.cgi?id=1461 Summary: session.c: don't chdir() after chroot() if chroot_path==pw->pw_dir Classification: Unclassified Product: Portable OpenSSH Version: 5.0p1

https://bugzilla.mindrot.org/show_bug.cgi?id=2289 Bug ID: 2289 Summary: arandom(4) as documented in sshd_config(5)?s ChrootDirectory option does not exist on all platforms Product: Portable OpenSSH Version: 6.7p1 Hardware: Other OS: All Status: NEW Severity: enhancement

I see that there is a new sshd_config in the latest updates. Since I have altered the original file, this one got installed as .rpmnew It has two changes: > #AddressFamily any So does this make it default to IPv4 only? > #ChrootDirectory none Chroot is now an option for SSH?

I'm running OpenSSH 5.1p1 on openSUSE 10.3 (i586) and I want to setup chroot jails for certain SFTP-only users. I use the following lines in my sshd_config file: Match Group sftponly ChrootDirectory /home/chroot-%u ForceCommand internal-sftp It works great. The problem is that some of my users need umask 002 for their uploads. I tried a few ways to achieve this: * set umask in sshrc,

Hello, I've tried many places, finally ending up here to ask my question: why is it so vital that the directory used with the ChrootDirectory directive is root-owned? Like many people I'm trying to use this in a webhosting environment where several users get sftp-only access to some directory, usually something like /home/user/web/part-of-website. I can be sure that there are no setuid

On Sat, 11 Nov 2023, Bob Proulx wrote: > I am supporting a site that allows members to upload release files. I > have inherited this site which was previously existing. The goal is > to allow members to file transfer to and from their project area for > release distribution but not to allow general shell access and not to > allow access to other parts of the system. > >

Hello, I would like to know how would I go about in using a connection type variable with the sshd_config. What would be the consequences,security,problem with doing such a thing. What I would like to accomplish is something like: Match Group Users ChrootDirectory "sftp/ssh" /home/%u ForceCommand "sftp/ssh" internal-sftp AllowTcpForwarding "sftp/ssh" no Where

I've configured OpenSSH_5.3p1 to only allow sftp connections (openssh chroot functionality). i.e. Subsystem sftp internal-sftp Match group sftpusers ChrootDirectory /chroot/%u X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp So far everything works correctly with sftp but when a user ssh's or scp's to the box the login