I don't think Jim's message was quite a response to my earlier one -- if
you do use a proxy/NAT as I described, you do not need to use a bastion
host and you don't need the proxy to be aware of the internals of the SSP
protocol, or worry about keys, or decrypt anything. It can be pretty
oblivious t
Hello Thomas,
On Thu, Jul 12, 2018 at 8:58 PM, Thomas Buckley-Houston
wrote:
> Forgive me for not fully learning about UDP, I've Googled a little
> bit, but I'm sure I still have a lot of gaps in my knowledge. So
> because UDP is a connectionless protocol, every datagram has to
> contain the sou
Thanks Jim,
That really clears things up for me.
So but you're saying that Keith's idea of having the outgoing
datagram's source IP remapped is not possible?
I totally agree about the traditional approach of the "bastion host",
it's basically like having SSH act as the "load balancer" - as I'll
Excerpts from Thomas Buckley-Houston's message of July 13, 2018 3:58 pm:
> So
> because UDP is a connectionless protocol, every datagram has to
> contain the source IP in order for the receiver to send responses?
Every packet does have the source IP address in it, but not because it's a UDP
packe
Forgive me for not fully learning about UDP, I've Googled a little
bit, but I'm sure I still have a lot of gaps in my knowledge. So
because UDP is a connectionless protocol, every datagram has to
contain the source IP in order for the receiver to send responses?
It's not enough for either end to as
Hi Thomas,
Hmm, let me try to see if I can say it better. For an outgoing UDP datagram
(from a containerized mosh-server to a mosh-client), the mosh-server will
be sending the datagram from some private IP address (the container's IP
address, e.g. 10.0.0.5) and a source port that is probably going
Thanks so much for this idea, I really think it's the one, simple and scalable.
I haven't tried but I'm pretty sure the mosh-server's "MOSH CONNECT"
can be wrapped in plain BASH. I'm already in control of the SSH
connection as I'm using my own `ForceCommand` script.
Also I can still use this meth
How about a semi-smart (but mostly Mosh-oblivious) server-side proxy/NAT
that works like this:
- The proxy service has one public IP address and like 65,000 available UDP
ports.
- The proxy service can itself be redundant with failover...
- When a user wants to open a new Mosh connection, they Mos
Hey Keith, John, everyone,
Yeah the more this is looking like a quite a big hurdle. Especially
your point Keith about roaming IPs (which I'd forgotten), it's a
central feature of Mosh I don't want to lose.
So the only 2 options seems to be exposing multiple IPs for Round
Robin (or other smart DNS
Hi Thomas,
Glad you could provoke a very interesting discussion! But I'm still
confused -- how is "sticky IP-based routing" going to work after the client
roams to a new IP address (or to a new UDP source port)? When your system
seems an incoming UDP datagram from a previously unseen source IP:por
On Mon, Jun 25, 2018 at 06:10:58PM +0800, Thomas Buckley-Houston wrote:
> Thanks so much for the clarification.
>
> > UDP is connectionless
>
> That's the key here. So I have no choice but to use sticky IP-based
> routing. Round-robin DNS isn't an option I don't think, because I hope
> one day to
Thanks so much for the clarification.
> UDP is connectionless
That's the key here. So I have no choice but to use sticky IP-based
routing. Round-robin DNS isn't an option I don't think, because I hope
one day to be able to scale to thousands of servers.
And thanks so much for the heads up about
You may have a misunderstanding about how a Mosh session is set up. The
mosh script launches a mosh-server on the remote system via SSH;
mosh-server picks a port number and a random encryption key, and writes
them to stdout, where they go back over SSH to the mosh script; then the
mosh script
13 matches
Mail list logo
