similar to: Is there any method, with ChrootDirectory and internal-sftp, to automatically cd to a subdir on login?

Nico Kadel-Garcia wrote: > in places where I do not want OpenSSH server's tendency ro let > people with access look around the rest of the filesystem. If you want users to be able to use *only* SFTP then set a ChrootDirectory and ForceCommand internal-sftp in a Match for the user in sshd_config. //Peter

Hello, I'm trying to set up an sftp (sshfs) service accessible to users with a normal account on a server, but which would be restricted to a subset of the directory hierarchy normally accessible to the users in question, in practice a single directory. The idea would be to allow file access to this directory with a passwordless public key, but keep rest of the users file accessible only with

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

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

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

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

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

Hi, Has anyone even seen this before - an NFS mount through Gluster that gets the filesystem size wrong and is otherwise garbled and dangerous? Is there a way within Gluster to fix it, or is the lesson that Gluster's NFS sometimes can't be relied on? What have the experiences been running an external NFS daemon with Gluster? Is that fairly straightforward? Might like to get the

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

What is the intended behavior of the internal-sftp server when looking to resolve identity information for user via the nsswitch configured mechanisms? I am seeing different behavior between two packaged versions and am looking to understand what should be expected. Scenario: Utilizing a developed directory services plugin (dsplug), "ls" access on the sftp session fails with the

I see that support for AuthorizedKeysCommand has been added. The arguments supplied to the command is just the authenticating user. Can we add the SSH connection details (ie. source and destination IPs and ports) as well? This command seems to be the idea way of requiring one set of credentials from inside an organisation (say the user's own authorized_keys file) and another set from outside

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

Hi! I tried with all available options to disable forwarding-only connections, by: "AllowAgentForwarding no AllowTcpForwarding no" This had no effect, so what I got in effect was dummy connections. I would like to disable this "class" of connections altogether. The outcome will be that all authenticated connections will lead to a command, be it /usr/libexec/sftp-server

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

https://bugzilla.mindrot.org/show_bug.cgi?id=1715 Summary: Integrate patch to provide ability to force 'umask' in sftp-server Product: Portable OpenSSH Version: 5.3p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: sftp-server

Hi, We've got a fresh CentOS 5.4 box, and the only glitch so far is that /etc/init.d/smb doesn't start smbd. It claims it does - shows "[ok]" - but only nmbd ends up running. Even setting a higher debugging level in the smbd flags, nothing logs or shows on the console as to why smbd is immediatly quitting. To make it stranger, doing this works fine: . /etc/init.d/functions

Hello, i am using SFTP with CHROOT. I want to allow my users that they can upload and download with the sftp server, but they should never do an MKDIR! Is it possible to restrict commands and how can i do this? i only found material of modifing the source...and that is not the best way for me. regards Sonja Meyer sonne_meyer at yahoo.de

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

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