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@xxxxxxxxx> wrote: > On Fri, Apr 10, 2020 at 8:27 PM Peter Stuge <peter@xxxxxxxx> 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@xxxxxxxxxxx > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
