On Thu, Aug 14, 2008 at 03:33:51PM -0400, Paul Clements wrote: > Wouter Verhelst wrote: > > On Wed, Aug 13, 2008 at 09:58:50AM -0400, Paul Clements wrote: > >> Wouter Verhelst wrote: > >> > >>> What we came up with is this: > >>> - Server sends a random number as a way to challenge the client for a > >>> password > >>> - Client constructs something based on the IP address, password, and the > >>> random number the server sent, pumps it through a secure hash > >>> algorithm, and sends that back. > >>> - Server constructs the same thing and pumps it through the same > >>> algorithm. If the output matches, we're authenticated; if it doesn't > >>> match, we're not. > >>> Thoughts, anyone? > >> But why build that into nbd? You can stunnel the nbd connection, and it > >> takes care of authentication and encryption. And no messy code added to > >> nbd. > > > > That's a bit of a hack, isn't it? It'd blow up the requirements on the > > client side too, which I'm not very fond of (requires libssl and > > libwrap, and seems to want some perl stuff, which I don't think can be > > done from an initrd). Also, is it possible to run stunnel on the server > > side in such a way that it'll accept different authentication for > > different ports? After all, nbd-server can serve multiple connections > > from the same server process now. > > You're right, there are environments where using a generic tunneling > mechanism (or VPN) is overkill, but I like the flexibility of being able > to just set up the compression/encryption/etc. and everything that goes > over the tunnel automatically takes advantage of it.
That's still possible, of course. But making it the recommended and even only possible way if what you want is authentication and/or encryption? I don't think that's a good thing to do. > None of the apps have to have compression/encryption embedded in them, > which is nice (especially in the case of nbd, where that code would > have to be in the kernel). That's true; but since the authentication I'm talking about is done entirely in the handshake, it wouldn't need to be done in the kernel, at all. If the protocol is changed to do encryption too, it of course would; but I'm not suggesting that. > The tunnel could be run somewhere besides the actual client and server > systems too, if desired. Sure. [...] -- <Lo-lan-do> Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
