similar to: chroot to dir per user?

Hello, I wanted to set my own time intervals for shutdown. {poweroff,return,paused.return}, so I had to change sources, where it has been set in a hard way. poweroff: Sxx\r return: Zxx\r paused.return: SxxRyyyy\r Solution A: Why not adding an info about these commands in a generic way and issuing shutdown.{poweroff.xx,return.xx,paused.return.xxyyyy} Solution B: Why not creating a special

Hello, Perhaps you could give some information here or redirect me, because it was not clear while reading manuals: how can connection timeout be set for sshd? Problem is, when some system is hibernated and it resumes, connections are dead. Mostly I made a successful workaround, but would be nice to know... Also, which version of ssh(d) support df on sshfs? I hope, is not a problem to enlighten

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 Timo, hi all others! In fact, I've only read one person claiming that IPv6 support opens up "too many backdoors" [1], but anyway, as I intend to run just particular services, please give me your opinion if it's insecure to have a dovecot server, which is accessed through a public IPv6 address... (or note just shortly what else could give a firm ground to such claims...) [1]

I run a sshd host solely to allow employees to tunnel secure connections to our internal hosts. Some of which do not support encrypted protocols. These connections are chroot'ed via the following in /etc/ssh/sshd_config Match Group !wheel,!xxxxxx,yyyyy AllowTcpForwarding yes ChrootDirectory /home/yyyyy X11Forwarding yes Where external users belong to group yyyyy (primary). We

Hello, this is one more unfortunate case, when I run into problems with some non-standard configuration: if authorized keys file for user %u is /keys/%u or /keys/%u/.ssh/authorized_keys, I receive an error: sshd: Authentication refused: bad ownership or modes for directory / ! Whats the cure? I can't keep those files into /home easily... /Please let me know by cc to this mail address,

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

https://bugzilla.mindrot.org/show_bug.cgi?id=177 Joshua Pettett <devel at homelinkcs.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|sshd |sftp-server AssignedTo|openssh-bugs at mindrot.org |unassigned-bugs at mindrot.org --- Comment

People, There is an imap client, which runs with user1 uid, but when its accessed to watch a maildir, whose (and its contents) ownership is user1:user1, this error occurs: dovecot: IMAP(user1): fchown(/path/user1/dovecot-uidlist.tmp, -1, 12(mail)) failed: Operation not permitted (egid=1000(user1), group based on /path/user1) dovecot.conf contains this line: mail_privileged_group = mail

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

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

Hi, I configured openssh 5.1p1 for sftp server. Here the specifications in sshd_config file: Subsystem sftp internal-sftp Match Group sftp ForceCommand internal-sftp ChrootDirectory /home/%u AllowTcpForwarding no When a user is logged in, he can't upload his document and he receives this message: carlo at Music:~$ sftp user at 213.217.147.123 Connecting to

Hello everyone, We have some chrooted sftp-only users on a CentOS release 6.6 server. The server had been logging their actions, but after recent updates the logs have stopped. The server correctly logs non-chrooted users: Sep 14 17:47:24 vsecure4 sshd[1981]: Accepted publickey for jcours from 192.168.10.166 port 42545 ssh2 Sep 14 17:47:24 vsecure4 sshd[1981]: pam_unix(sshd:session):

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! 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, 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

Hi list, my thanks to developers of nouveau first: I wonder how you put it together this far, where there's quite enough to appreciate! This question I have: strangely I can get each of 2 cards to work separately for a dualseat PC by toggling on/off fbcon=map: kernel option (compiled with CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY) -- by doing so I can have each card initialized and start

https://bugzilla.mindrot.org/show_bug.cgi?id=1951 Bug #: 1951 Summary: Add home directory facility for chrooted environments Classification: Unclassified Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: sshd

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 "

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