I would personally rather see a new subsystem written instead of
mangling "sftp" further into something it was never designed to do. It
fails at being sshfs because of all the hackery required need to make it
a proper "filesystem" remote protocol.
And I know a lot of the current OpenSSH/OpenBSD developers agrees with
me on this. Which is why newer sftp RFCs haven't been implemented that
try and mangle it into a filesystem protocol.
Ben
Dr. Nagy Elemér Kár oly wrote:
Dear Peter, dear list,
An interesting scenario is when the user stores encrypted files on a server without the server admin and other users
having access to the files. This could be implemented on the client side by encrypting the files before sending to the
server and decrypting it while receiving - and this could be done by the SSH client. I would like that feature - very
much. It would make "automagic" possible - storing encrypted files with autofs for transparent encrypted network file
storage. Sounds really awesome.
It would be nice if the server would tell the client which key the client used to encode the files - this could be
implemented many ways, one approach is to write the public key / fingerprint to the beginning of the file before the
actual content or to have a meta file next to the actual file. I see less practical use with password authentication, but
a timestamp or the first two characters of the password as the meta would also help the forgetful persons like me.
I would really like SFTP/SSHFS take over other network file storage protocols. This could be a killer feature to achieve
that.
Best wishes:
Elmar
_______________________________________________
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
