SSH/SCP驱动的内核模块
我和我的同事有一个项目，制作一个驱动程序，该驱动程序将提供对远程驱动器的访问，就像它是本地驱动器一样（使用 SSH/SCP）。驱动器通常应该被视为一个驱动器，并且操作可以仅限于简单的文件操作（复制、移动、删除），而没有文件列表等。驱动器应该是一个 Linux 内核模块（也许不完全是......）。
我们设法收集了一些信息和想法，也许有人可以验证它们，或者推动我们走向一个好的方向？
我们考虑将其分成两个组件：
- 一个实现虚拟驱动器的内核模块，
- 一个负责 SSH/SCP 通信的用户空间守护进程，
因为我们无法想象在内核模块中实现 SSH 通信（是的，这可能是可能的，但是..)。
对于 SSH/SCP 通信，我们认为可以使用 libssh。 关于在内核模块中实现虚拟驱动器，我们找到了一个教程。
另一种情况是内核和用户空间之间的通信。我们还发现了一篇 文章 讨论了这个问题，其中有很多可能性，例如 UDP 套接字或网联。
通过这个解决方案，我们可以忘记内核模块中任何与 SSH/SCP 相关的内容 - 它将对内核透明。
我们的思想好吗？也许有一些我们没有预见到的警告？这是正确的方法吗，或者也许有更好/更简单的方法（但仍然与linux内核相关，因为那是该项目的主要领域;））？我们应该使用哪些想法？非常感谢链接:)
编辑：这是我们必须为大学课程做的一个项目 - 所以问题不是找到一个已经实施的解决方案，而是做你自己的解决方案。
Me and my colleague have a project, to make a driver which will provide access to a remote drive like it was a local drive (using SSH/SCP). The drive should be seen normally as a drive, and operations can be limited to simple file operations (copy, move, remove), without file listing etc. The driver should be a linux kernel module (maybe not entirely..).
We managed to gather some informations and ideas, and maybe someone could verify them, or push us to a good direction?
We thought about splitting it into 2 components:
- a kernel module implementing a virtual drive,
- a user-space daemon responsible for SSH/SCP communication,
because we can't imagine implementing SSH communication in a kernel module (YES it probably is POSSIBLE, but..).
For SSH/SCP communication we think we can use libssh.
About implementing virtual drives in kernel module we found a tutorial.
Another case is communication between kernel and user-space. We also found an article discussing this, with many possibilities like UDP sockets or NETLINK.
With this solution, we could forget about any SSH/SCP related stuff in kernel module - it will be transparent to the kernel.
Is our thinking good? Maybe there are some caveats we didn't forseen? Is this the right way, or maybe there is a better/simpler method (but still related to the linux kernel, because that's the main field of the project ;)) ? Which ideas we should use? Links much appreciated :)
EDIT: It's a project we have to do for an university class - so it's not the problem to find an already implemented solution, but to do your own..
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可能想看看FUSE，尤其是SSHFS。这基本上就是你所描述的，已经实现了。
You may want to have a look at FUSE and especially SSHFS. That's basically what you describe, already implemented.
然后不要在内核内部进行加密。
传统观点认为内核代码应该非常小，对于学生来说更是如此（因为内核代码很难调试，并且其中的错误会导致整个系统崩溃）。
研究了一下FUSE正在做的事情，并在项目中提到它。
然后，让您的内核模块保持较小的规模并与用户空间守护进程进行通信（以简单、高效、未加密的方式），正如您最初猜测的那样。
也许你不需要做内核代码，而只需要做用户部分（你必须弄清楚老师对你的期望是什么）。然后，您只需重新实现FUSE的SSHFS示例，就可以使用FUSE已经提供的机制。
不要谈论虚拟驱动器，而要谈论用户空间文件系统。
Then don't do the encrypting inside the kernel.
A conventional wisdom is that kernel code should be quite small, and this is even more true for students (because kernel code is hard to debug, and bugs inside it crash the entire system.).
Study a bit was FUSE is doing, and mention it in the project.
Then, have your kernel module stay small and communicate (in a simple, efficient, unencrypted way) with a user-space daemon, as you guessed initially.
Perhaps you are not required to do kernel code, but just the user part (you have to find out what the teachers are expecting from you). Then, you just have to re-implement the SSHFS example of FUSE, and you can use the machinery already provided by FUSE.
And don't speak of virtual drives, speak of a user-space filesystem.
我认为你不需要任何内核模块，因为你可以使用 FUSE 。
I think you don't need any kernel module since you can use FUSE for that.