New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ssh port forwarding doesn't work #337

Open
staticfloat opened this Issue Oct 21, 2012 · 19 comments

Comments

Projects
None yet
@staticfloat
Copy link

staticfloat commented Oct 21, 2012

I believe this is because of the fact that mosh-server takes over from sshd and sshd quits, therefore the tunnel disappears just after it is made. It would be nice if mosh could keep sshd alive if -L or -R are present in the --ssh argument

@sessyargc

This comment has been minimized.

Copy link

sessyargc commented Oct 22, 2012

I think this would be good if you connect and disconnect per session. If you use mosh to connect only once, one foreseeable problem is when the remote device changes IP address while roamin. mosh is able to auto-negotiate the new IP address ... one of mosh's goals (How Mosh works) ... but the tunnel would be good as dead in this case.

@keithw

This comment has been minimized.

Copy link
Member

keithw commented Oct 22, 2012

I don't want to add a feature to mosh that unexpectedly stops working once the client roams for the first time. If we add port forwarding, it will need to roam (like the rest of mosh). We wouldn't just leave the SSH connection up to break later.

@staticfloat

This comment has been minimized.

Copy link

staticfloat commented Oct 22, 2012

Good points, and mosh obviously can't auto-reconnect the SSH tunnel because
of authentication issues, right?
On Oct 21, 2012 11:16 PM, "Rommel Custodio" notifications@github.com
wrote:

I think this would be good if you connect and disconnect per session. If
you use mosh to connect only once, one foreseeable problem is when the
remote device changes IP address while roamin. mosh is able to
auto-negotiate the new IP address ... one of mosh's goals (How Mosh works)
... but the tunnel would be good as dead in this case.


Reply to this email directly or view it on GitHubhttps://github.com//issues/337#issuecomment-9653535.

@omry

This comment has been minimized.

Copy link

omry commented Apr 3, 2015

why wouldn't mosh be able to reconnect the tunnel as well?

@brainstorm

This comment has been minimized.

Copy link

brainstorm commented Sep 17, 2015

Yeah, I would like to drop those lines in my ~/.ssh/config:

Host somehost
    HostName example.com
    LocalForward 5558 example.com:5558
    User admin

And be able to have that local tunneling done with mosh too. Is it that different from a plain SSH connection that drops and recovers?

@brainstorm

This comment has been minimized.

Copy link

brainstorm commented Oct 7, 2015

I opened a $50 bounty for this issue:

https://www.bountysource.com/issues/4471419-ssh-port-forwarding-doesn-t-work

Should anyone solve this one or related ones like issue #120

@dwwoelfel

This comment has been minimized.

Copy link

dwwoelfel commented Jun 30, 2016

The bounty for this feature is up to $200, now.

@mharradon

This comment has been minimized.

Copy link

mharradon commented Nov 11, 2016

I threw in a bit, up to $235.

Could anybody familiar with the Mosh codebase comment on the expected difficulty of this addition? Perhaps point out the relevant files? That might make it easier for somebody to take a crack at it.

@wittrup

This comment has been minimized.

Copy link

wittrup commented Dec 18, 2016

I currently use some ugly "auto"ssh script that run ssh like this:

reverse=$(( ((RANDOM<<15)|RANDOM) % 63001 + 2000 ))
/usr/bin/ssh -o ExitOnForwardFailure=yes$identity_file -N -R $reverse:localhost:22 -p $port $host; } 2>&1

Having mosh do that for my network of raspberry pi would be awesome. Bounty increased.

@claui

This comment has been minimized.

Copy link

claui commented Jul 26, 2017

The bounty has now reached $300.

@MisterTea

This comment has been minimized.

Copy link

MisterTea commented Sep 20, 2017

FYI: port forwarding works in Eternal Terminal with the -t option. https://mistertea.github.io/EternalTCP/

@brainstorm

This comment has been minimized.

Copy link

brainstorm commented Sep 21, 2017

@MisterTea sure, but my HPC cluster has only mosh server(s) installed so far... I reckon that with ET they would have to install yet another service? If ET works well against Mosh server, that would solve the issue for me, if not, this bounty is still relevant to me ;)

@MisterTea

This comment has been minimized.

Copy link

MisterTea commented Sep 21, 2017

@brainstorm Yep, ET is it's own server that you have to install. Where I work we have 100s of engineers using ET, but it's up to your use case to decide whether it works well for you.

@bkarlson

This comment has been minimized.

Copy link

bkarlson commented Oct 3, 2017

Does not look like ET supports remote (-R) tunneling either
MisterTea/EternalTerminal#59

@d4l3k

This comment has been minimized.

Copy link

d4l3k commented Jul 10, 2018

I just took a look at some of the Mosh source code to see how hard this would be to implement reconnecting streams. From my naive perspective, it seems like the Mosh protocol doesn't map very cleanly to adding extra network streams since the protocol is designed to only have one stream each way.

To add TCP like support you'd have to create a new state syncronizer that acts like a TCP connection (probably based off of Network::UserStream() since that's a reliable connection).

But you're still stuck with the issue that mosh only allows one stream each way. Looks like there's three main ways to do this:

  • Create multiple Network::Transport connections, one for each TCP/UDP stream. This would require some major refactors to how mosh connections get established since they assume one ip/port per session.
  • Modify Network::Transport to support multiple senders and receivers. This seems like a huge pain since it's using C++ templates and having an arbitrary number of streams seems painful.
  • Create a multiplexer stream that can multiplex multiple streams over the existing connection. This seems like the easiest since it doesn't involve modifying much of the existing code base.

All of these options would likely break backwards compatibility.

@brainstorm

This comment has been minimized.

Copy link

brainstorm commented Sep 20, 2018

@d4l3k Would you mind putting together a patch for your last suggestion if that's the easiest and most pragmatic? Happy to see this issue solved for good (and you get paid from Bountysource) ;)

@d4l3k

This comment has been minimized.

Copy link

d4l3k commented Sep 21, 2018

@brainstorm I did throw together a PR has a few small issues (like using modern syntax). No one has looked at it or commented at all.

#986

@andersk

This comment has been minimized.

Copy link
Member

andersk commented Sep 21, 2018

@d4l3k Did you notice that it didn’t pass the automated CI test?

@NightMachinary

This comment has been minimized.

Copy link

NightMachinary commented Oct 15, 2018

MisterTea/EternalTerminal#59 now has this feature implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment