My proof-of-concept doesn't have packet authentication. But I have
considered this, and have a design in mind where, as part of the session
initiation, an authentication key is generated. The problem is that this
requires an enhanced client that can encapsulate Mosh packets with this
authentication header. I could rig that up with a "relay helper agent", and
have considered doing so.

It'd be great if, as you suggest, Mosh included an authentication header,
so that the use of a relay would not require a specialized client or "relay
helper agent".

On Mon Mar 31 2014 at 11:47:49 AM, Keith Winstein <kei...@mit.edu> wrote:

> I like the idea of a relay or proxy -- the problem I've been having is
> that it's hard for the relay to let the client roam securely unless it can
> verify that datagrams coming in from a new source address are authentic.
> But it can't verify that unless it has the plaintext session key, which (1)
> ideally it would not have (2) even if you did give it to the proxy, how
> would you set up the UX to do that in a sane way?
>
> Perhaps in a protocol revision, we should thing about using an Ed25519
> signature so that a chain of proxies along the way can authenticate the
> datagram without also needing to be able to decrypt.
>
> -Keith
>
>
> On Mon, Mar 31, 2014 at 11:41 AM, Richard Perry Woodbury III <
> rpwoo...@mybox.org> wrote:
>
>> Your intuition about the lag-friendly interface being rendered useless is
>> correct. It is critical for the client and server to be on opposite sides
>> of the source of lag. Otherwise you get really bizarre effects, like
>> predictive text getting erased and then redrawn in a flash.
>>
>> I've been contemplating a Mosh Relay that uses a basic NAT traversal
>> technique, so it can run on any machine with public Internet access and
>> doesn't require any special network configuration. I have a
>> proof-of-concept working. If there's sufficient interest, I may flesh it
>> out.
>>
>> Richie
>>
>> On Mon Mar 31 2014 at 4:12:42 AM, David Seaward <dseaward...@gmail.com>
>> wrote:
>>
>>> Hi Vincent and Mark,
>>>
>>> Thanks for your feedback, it was very helpful. I will look into an SSH
>>> intermediary (mosh-client > mosh-server > ssh > endpoint) as a
>>> solution.
>>>
>>> My primary motivation is the lag-friendly mosh interface, rather than
>>> the connection per se, which makes me wonder if both the mosh client
>>> and server could be on my local machine, which itself makes the
>>> tunneled/ProxyCommand ssh connection with a regular tunnel or similar.
>>> The connection benefits are obviously lost, but I suspect even the
>>> lag-friendly interface would be rendered useless. An experiment for
>>> another day.
>>>
>>> I have summarized your helpful responses as an answer to my SU
>>> question. Thanks again!
>>>
>>> David
>>>
>>> On Fri, Mar 28, 2014 at 6:10 PM, Vincent Lefevre
>>> <vincent-m...@vinc17.net> wrote:
>>> > On 2014-03-28 17:08:00 +0200, David Seaward wrote:
>>> >> Ah, this is more complicated than I thought :D
>>> >>
>>> >> I thought it was going to be one of:
>>> >>
>>> >> a) mosh-client - ssh - ssh - mosh-server
>>> >>
>>> >> ...where "ssh - ssh" may be some kind of transparent hop, or
>>> >>
>>> >> b) mosh-client - mosh-? - mosh-? - mosh-server
>>> >>
>>> >> ...with funky configuration on the hops.
>>> >
>>> > With stone (or similar UDP repeater), if I understand correctly,
>>> > I was thinking of:
>>> >
>>> >   mosh-client - stone - mosh-server
>>> >
>>> > or
>>> >
>>> >   mosh-client - stone - stone - mosh-server
>>> >
>>> > for 2 gateways.
>>> >
>>> > --
>>> > Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
>>> > 100% accessible validated (X)HTML - Blog: <
>>> https://www.vinc17.net/blog/>
>>> > Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>>> > _______________________________________________
>>> > mosh-users mailing list
>>> > mosh-users@mit.edu
>>> > http://mailman.mit.edu/mailman/listinfo/mosh-users
>>>
>>> _______________________________________________
>>> mosh-users mailing list
>>> mosh-users@mit.edu
>>> http://mailman.mit.edu/mailman/listinfo/mosh-users
>>>
>>
>> _______________________________________________
>> mosh-users mailing list
>> mosh-users@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/mosh-users
>>
>>
>
_______________________________________________
mosh-users mailing list
mosh-users@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-users

Reply via email to