Nice thought, but, I can tell you that it won't work (without code
changes). The problem is the underlying "protocol" for finding a
console. Assume conserver listens on port 782....
CLIENT (console) SERVER (conserver)
--------------------------- ---------------------------------------
connect to master conserver
on port 782
accept connection on port 782
ask for console 'foo'
if 'foo' is not local (distributed setup)
respond with remote console hostname
(console client starts over with new
master conserver)
else (is local)
respond with random high-numbered port
connect to conserver on
random high-numbered port
accept connection on high-numbered port
authenticate, chat, etc...
--------------------------- ---------------------------------------
So, ask you can see, while the first connection is to a known port, the
real work is all done with a random high-numbered port (each conserver
child process opens it's own randomly-allocated socket) which is passed
to the client dynamically.
I hope this helped clear up what's going on and show you where the
gotchas are. If you come up with a nice way to make the data
encrypted, I'd love to hear about it (I and others have been wanting
this feature for a long time). Hopefully I or someone will be able to
implement encryption bits sometime soon (emphasis on "someone", knowing
my schedule).
Bryan Stansell
On Wed, Feb 14, 2001 at 01:13:51PM +0000, Iain Rae wrote:
> Hi,
>
> has anyone tried encrypting the session between console and conserver using
> something like port forwarding under ssh or stunnel?
>
>
> --
> Iain Rae
> Computing Officer
> Division of Informatics
> Edinburgh University
>
>
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users