using OpenSSH/SFTP to replace an FTP server securely

Ángel González keisial at gmail.com
Thu May 22 09:40:24 EST 2014


On 20/05/14 Damien Miller wrote:
> On Mon, 19 May 2014, ?ngel Gonz?lez wrote:
>
>> If you want something different, like chrooting them at /chrooted-users/foo,
>> you can use -d parameter in the ForceCommand, ie.
>>   ForceCommand internal-sftp -d /%u
> If you're willing to live with a single chroot directory and file
> permissions to keep users from each others' files then this is a great
> solution. It only requires a single /chrooted-users/dev/log listener
> too.
>
> -d
He had stated it was acceptable ;)


Nico Kadel wrote:
> The necessity for additional arcanery, of having non-user owned
> contents inside each working chrooted directory, and this kind of
> 'make one chroot, but rely on the users to correctly set permissions
> and block access to each other's content, even though they can see
> each other's directories by default" is exactly why the sftp chroot
> setup is not ideal.
Remember they don'r need +r on /home but just +x. They can still confirm
if a user exists, but puts the bar slightly higher. It isn't so extravagant
to require properly set permissions on your folder (I think that by using
posix acls you could forbid them to change the default)

But yes, it's not ideal, which leads to:

Damien Miller wrote:
> The syslog problem doesn't have a good solution right now. Maybe someone
> could write a patch to implement logging via the monitor, like what happens
> for the pre-auth process.
+1

Or it may be easier to leave open an fd to /dev/log.




More information about the openssh-unix-dev mailing list