(I've accidentally first sent this as a private reply instead of to the list; I need to be more careful using the gmail web UI.)
2011/9/25 Wouter Verhelst <[email protected]>: > Can you explain that a bit? I don't see how you could make that easier, > to be honest, but ideas are always welcome. I haven't really thought it through either yet, mostly because I first wanted to check what existing solutions I might have missed. So these are half-baked ideas: One use case I imagine (maybe the one that solves it for me) is to use ssh as command connection to start a server instance. Like, I run a script on the client which runs "ssh me@fileserver nbd-server filepath some-options" (probably non-root user; might even be a restricted shell only allowing nbd-server with certain paths/arguments to be called). This uses a more secure connection to do the most sensitive decisions like which file to serve, and the server system could thus be more trusty on what to allow. The idea is not to need any configuration file at all on the server. A secret value (random string) for the challenge-response authentication could be passed over this ssh connection too, read from stdin (to avoid showing it up in the process table). On the client, the script would need to run nbd-client in a way that allocates the next free nbd device automatically, and tells which it is (similar to "losetup -fs file"). IIRC that's not possible currently, but I might be wrong, as mentioned I haven't started to try to script it yet. I envision to then write a simple (custom) script that takes a file path from an sshfs mount of the server filesystem, maps it to a serverside path and then calls the above to get that file as an nbd device path. The mapping could be hardcoded for my case; but it could also read /proc/mounts and figure out the server plus server-side base of the mount point automatically and hence be usable for everybody. > TCP hijacking isn't exactly difficult, Unless the ARP mapping table is set up statically on both server and guest (correct?). Even though that would be a pain to maintain, it would at least make it *possible* to prevent men in the middle. An idea might also be to send checksums with each message plus a secret and serial number, to make men in the middle impossible. Of course the question then becomes how much cheaper that can be than full-blown encryption (including checksumming). My fileserver with Atom D510 @ 1.66GHz hashes about 102 MB/sec with "openssl sha1"; it transfers about 90 MB/s traffic using netcat over the gbit ethernet (not sure why not more, would have to check); and transfers about 15 MB/s over ssh with compression off and using blowfish encryption. These numbers seem to make this idea quite attractive; although this test isn't fair since hash setup costs for each of the smaller messages will cost cpu not included here, and sha1 isn't really secure anymore (the newer hashes are about half as fast in openssl). > That's what the -persist option was meant for, Ah, I've missed this! I'll try it. Christian. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
