l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SSH revised


From: Marcus Brinkmann
Subject: Re: SSH revised
Date: Sun, 26 Mar 2006 22:12:24 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Sat, 25 Mar 2006 10:08:20 +0100,
Tom Bachmann <address@hidden> wrote:
> Uhm, I hope I do not misunderstand you, but I take this as an invitation 
> to explain some of my thoughts.
> 
> As described in one of my mails [1] to coyotos-dev and somewhere on the 
> E language homepage [2] it is possible to implement transparent "remote" 
> capabilities, i.e. caps that are invoked like normal local ones but that 
> actually invoke servers on other machines over the net. There seem to be 
> some tricky minor problems (mostly related to the split of knowledge 
> between the invoking app and the forwarder(s) and the split of knowledge 
> between the forwarder(s) and the server invoked) if you dig into 
> details, but all in all it is possible.
> 
> The next point is that the implementation described allows transparent 
> encryption of traffic.
> 
> So a secure remote shell fitting IMHO nicely into the common hurdish 
> object model would just be a remote cap to a terminal on an other machine.

I see.  That's certainly interesting, and I would like to see it
happen at some time.  But one nice things about the internet is that
it allows heterogenous interoperation, ie, the two systems don't need
to run the same operating system.  Of course, you could still achieve
that by having a program on the alien system that emulates
capabilities.  But that would require at least to install a program,
which may already be too much of a requirement.

Another problem is that the remote machine would need to have the
drivers to use the local terminal.  There is a corresponding problem
in the Unix world, and that is that the remote machine needs to have
the terminfo entry for the local terminal.  It's annoying as hell.
Well, it would be feasible for a pty, I suppose, but beyond that, it
would be demanding.

These problems are probably not unsolvable.  For example, the terminfo
entry could be passed from the local to the remote machine, the same
could be done with driver code, at least if there is an architectural
match (if there is not, you can't do direct access anyway, and you
want a virtualized middle layer like VNC).  In light of this, I guess
my main point is that SSH and transparent remote object access are
solutions to different problems, and I don't think it would be
entirely fair to either to say that one of them is the way it ought to
be.
 
Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]