there are cheap virtual linux root servers that don't support encrypted filesystems, even if you have root, as even root cannot change the kernel or modules. And most sftp clients will allow you to set the server port, so no need to run as root at all. Why not run an encrypting sftp server at port 2222 as user demon? Just a secure box at yourserver:2222 you drop your files into. No infra structure needed except a port and some directory. And, to create an incremental backup of a bunch of encrypted files is way easier than a backup of an encrypted file system. Juergen Am Do., 13. Sep. 2018 um 21:17 Uhr schrieb Peter Stuge <peter@xxxxxxxx>: > > Jürgen Weber wrote: > > I wonder if sftp-server could encrypt files before writing to disc. > > This would make sshd a poor man's alternative for an encrypting > > filesystem on a server. > > What does the poor man want to gain with this encryption? > > > > How to get the crypto key from a client to be used by sftp-server? > > Upload the key to a /well/defined/key.pem virtual location? > > That can be implemented, but I don't know that it's a good idea. If > the poor man controls the server to implement something like that, then > the poor man can probably also just enable full disk crypto. > > > > Or can you access the ssh client certificate from sftp-server? > > SSH clients don't always use a certificate, nor always a key. > > > > Can sftp-server call a filter? > > No, but you can post-process uploaded files as the filesystem changes. > > > Or would one write a sftp-server replacement? > > You can, but the poor man needs root access to deploy that, and if he > is root then he's probably better off with full disk crypto. > > > //Peter > _______________________________________________ > 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