similar to: ChrootDirectory security

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

Package: logcheck-database Severity: normal Tags: patch The rules in /etc/ignore.d/server/nagios contain the explicit version number "2". Now that lenny includes nagios3, those rules don't work anymore. Please change the rules to work for both nagios2 and 3. That can easily be done by replacing the 2 by (2|3) for example. -- System Information: Debian Release: lenny/sid APT

Hi Team, I am just a curious individual user who reviewed the OpenSSH;not working for a company. I was just wondering why there is a restriction for chroot directory to be owned by root. The line of code below in session.c show them. The basic UNIX security permissions provide a sufficient access control. Have you guys found a way to bypass security if the directory is not owned by root? -

Hi All, Could anyone explain what is "enhance SSH so that sftp chrooted user sessions are loged in to syslog"? What is "chrooted user sessions"? I'm sorry for the interruption and the laughable question. Thanks and Regards, Bin.Bai.

It seems the certificate-based login doesn't work on both sides of the remote connection when using scp? Scenario: User on PC A can SSH login to PCs B and C with his certificate, no password prompt. When User on PC A runs a scp operation from B to C he's asked for the password on C. Does the scp actually open a connection from B to C (User doesn't have a certificate on B)? This

Hello, First, a big thank you to the OpenSSH devs. _ /Problem Summary:/ _ Chroot and SELinux don't get along. This affects both the new (official) ChrootDirectory feature, as well as the older (3rd party) patch at http://chrootssh.sourceforge.net/. _ /History and repro:/ _ On March 21, 2008, Alexandre Rossi posted to this list with the subject: "*ChrootDirectory

Package: logcheck-database Version: 1.2.54 Severity: normal The included filters for cyrus (/etc/logcheck/ignore.d.server/cyrus) are very minimal. The cyrus-imapd-2.2 has a more extensive ruleset (there's a /etc/logcheck/ignore.d.server/cyrus2_2 file in that package). Please copy over the filters from cyrus-imapd-2.2. I'm running logcheck on a loghost, which doesn't run cyrus

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

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 "

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=3715 Bug ID: 3715 Summary: safely_chroot is a little too restrictive: noexec or nosuid should be enough Product: Portable OpenSSH Version: 9.8p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5

Hi, This is either a query or a feature request. I have a system where sftp users are chrooted using scponly, which while requiring much more setup than OpenSSH's internal-sftp method, has the useful feature of allowing an initial chroot to a subdirectory, typically the one used for file exchange. I've searched for a way to do the same thing with OpenSSH. So far haven't found it. If

Hi, According to the sshd_config manual page the option ChrootDirectory can be used to force a chroot:ed environment for the SSHD server. But as I understand the manual page this is a global setting and it is not possible to specify this per SSH subsystem. We are building a system where we need users to be able to log on from remote machines via SSH, but with the tweaks that we (for security

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

Hi, many people are having problems using SFTP with ChrootDirectory when the jail directory (or the path above) is not owned by root. The question is if chroot'ing to usual home directories can be allowed, even though they are owned by regular users. I know that this topic has been discussed on the list several times now, so I searched the list archives for posts that invalidate the

https://bugzilla.mindrot.org/show_bug.cgi?id=1726 Summary: ChrootDirectory doesn't work with SE Linux Product: Portable OpenSSH Version: 5.3p1 Platform: Other URL: http://bugs.debian.org/556644 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd

Hi all, I am using Match directive and internal-sftp to chroot sftp users into their directory. Connection and login works. I can change directories and put/get files. Also logging of the internal sftp-process works (created a /dev/log socket inside the chroot). As soon as I use the 'ls' command, nothing happens and the the process gets stuck. Listing files does work as soon as I remove

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. > >

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

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