ssh port forwarding doesn't work

[staticfloat]

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]

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]

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]

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" [email protected]
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]

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

[brainstorm]

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]

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]

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

[mharradon]

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]

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]

The bounty has now reached $300.

[MisterTea]

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

[brainstorm]

@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]

@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]

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

[d4l3k]

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]

@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]

@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]

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

[NightMachinery]

MisterTea/EternalTerminal#59 now has this feature implemented.

[Millak]

Is this something that is actually desired? I'm interested in working on this but I don't want to implement a solution if it's something deemed outside the scope of mosh. I read this thread¹ and I understand that this might be the case.

¹ #120

[senorsmile]

Is this something that is actually desired?
Very much yes. It might be outside the scope of mosh, but I for one would use it all the time.

[eminence]

@Millak thanks for checking in. I am not speaking for the entire mosh team, but my personal opinion is that a PR to implement port forwarding in mosh is not likely to be accepted. Here is my thinking:

• As outlined the in SSH agent issue you linked to, the project is quite conservative with regard to large new features or protocol changes, for reasons of security, compatibility, and maintainability. Not having every possible feature is itself a type of "feature".
• mosh has never tried to replicate every feature of ssh; it's always been focused on improving the interactive terminal experience.

I do agree and recognize that port forwarding is a powerful feature of ssh and it useful. My personal recommendation would be to think about starting a new project and think about the requirements for this feature:

• Is there a need to forward multiple ports over a single channel like SSH does?
• Does it need to handle links with high levels of packet loss?
• Does it need to handle client roaming? Server roaming? Both?
• To what extent is performance a requirement?
• What concerns are there about buffering data when the network if offline? (mosh kinda has this problem, but in practice it's a lot easier for a file-transfer running over a forwarded port to fill up buffers than someone typing into a keyboard)

Finally, I don't want the reluctance of the mosh project to accept a big new feature to hamper the development of a new feature that's arguably outside the scope of mosh.

[MisterTea]

I'm unsubbing from this thread but just a reminder that Eternal Terminal is exactly this "new project" https://mistertea.github.io/EternalTerminal/ :-). There is no free lunch: ET can't do type prediction and disconnect reporting on-screen because it's not a terminal emulator. But it's an option for people who need port forwarding.

[brainstorm]

@Millak I am very much still interested in that. Perhaps you could followup with @keithw on #986 and start planning/discussing that for mosh v2? I'm not sure what's the current status for that, perhaps the mosh-dev mailing list would be the best place to have this discussion (see #986 (comment)).

[galaxy001]

For this situation:

I want to connect to a machine(L) behind firewall, and I have a VPS.
I want to use mosh to connect from L to VPS and keep listening a port(P) on VPS.
Then, I can connect to VPS:P so that I can connect to L.
Mosh will help me to keep the connection on.

[shobhitg]

The total Bounty is $550 now.
https://www.bountysource.com/issues/4471419-ssh-port-forwarding-doesn-t-work

[drewwells]

If mosh wants to be only a core application without higher level features like port-forwarding, ssh-agent, etc. Then it really needs to rebrand as a library or provide extensions for adding these features. Recommending that people build forks of mosh to add core functionality is not a suitable long term strategy for getting wider adoption of mosh.

[d4l3k]

@drewwells It seems like there's no interest from the maintainers in adding port forwarding and it's unlikely we can change their mind given this thread.

I've since switched to Eternal Terminal and been quite happy with it.

[Jolg42]

Looks like this is a blocker for using VSCode Remote Extension microsoft/vscode-remote-release#334 😢

[maciekish]

I’d love to see this as well please.

[catskul]

Bounty is at $655.01USD

[achernya]

I'm sorry, what is the bounty comment supposed to mean?

[aatkinson]

I believe @catskul is referring to the bounty set on this very bug. See here for details: https://app.bountysource.com/issues/4471419-ssh-port-forwarding-doesn-t-work

[Sepero]

I don't want to use Bounty Source, but I want to contribute another $300 raising the bounty

Total to $955

I can make payment through PayPal or Monero or other. If you are a mosh developer and accept then please let me know, as I will send you half ($150) immediately to begin development, and the other half after changes are merged into master or a testing branch

My offer to accept this job expires Jan 1 2024

My Session Messenger ID:

05a3e56b415d89a6e67c210de3164cde95b843ba65ad2d2529be96dcea97474912

[tsunamaru]

+$50 on Bounty Source from me. Counting above contribution from @Sepero, the total is now at $1005.

[huyz]

What's the downside of BountySource? the 10% fee? Or these problems: bountysource/core#1586

[Sepero]

I've used Bounty Source before and had problems with them, so I'd rather not have that again. Thank you @tsunamaru for helping push the bounty over $1000

[tsunamaru]

Welp, I just read about Bountysource problems (thanks @huyz for pointing that out) and decided to ask PayPal for refund. I'm not sure if or when it'll be processed but regardless I will be happy pay my part to anybody after their changes is merged, would it be PayPal, crypto or any other suitable method.

[keithw]

Folks, I don't want anybody to waste their money here -- I don't think the issue is about money; it's about changes people are asking for in the Mosh/SSP protocol. These protocol changes would have to be designed, and then implemented at both ends of the connection, and then supported. Think about other protocols or interchange formats you might want to change -- can you post a $1,000 bounty and get them to add a new field to TCP or a new tag to HTML? :-)

Adding support for reliable byte streams would be a big change to the Mosh protocol, and I don't sense anybody is eager to design, implement, and support this kind of major change. I think EternalTerminal can probably already do this; you might consider using that if you need reliable byte streams.

[makeasnek]

Please do not use bountysource. Many devs have had trouble getting paid there. You can check out this lemmy community as an alternative https://lemmy.ml/c/bugbounties

For statements from devs who have been unable to cash out from bountysource see:
https://github.com/bountysource/core/issues

[ghost]

• [CRITICAL] Bountysource is Insolvent, do not use! bountysource/core#1586