internal-sftp + chroot [was: Parallel transfers]

[kevin martin]

Then use another tool to achieve the results you want (like vsftpd).  Seems
like you're making a mountain out of a molehill.
---


Regards,

Kevin Martin


On Fri, Apr 10, 2020 at 11:08 PM Nico Kadel-Garcia <nkadel at gmail.com> wrote:

> On Fri, Apr 10, 2020 at 8:27 PM Peter Stuge <peter at stuge.se> wrote:
> >
> > 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.
>
> Because I can achieve it with manual tuning does not make it the best
> approach.
>
> * It puts OpenSSH at risk of accidental misconfiguration disabling he
> daemon from starting. Been there, done that.
> * Editing sshd_config manually  puts updates at risk of failure. If an
> update overwrites this file, the restricted sftp access is suddenly
> generalized with whatever access you provided before with full shell
> access *unless* you go to  variety of extra steps that require extra
> work to manage, such as running  distinct sshd with a distinct
> sshd_config and only exposing that, or putting authorized_keys
> somewhere effective, or disabling shells, etd. Been there, done that.
> * It creaes a set of maintenance issues, such as whether my admin
> account gets shell access, or distinct sftp access so I can test this
> service.
>
> Segregating browseable upload and download access is easier qne less
> likely to interfere with critical admin access if it's entirely
> distinct from OpenSSH. Fatal configuration mistakes are too easy. Been
> there, done that.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>