Re: [Nbd] Easier use, authentication

[Christian Jaeger <chrjae@...17...>]

(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 <w@...112...>:
> 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@...945... 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.