-
Notifications
You must be signed in to change notification settings - Fork 747
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
Implement ProxyJump #970
Comments
Is this the same issue as issue #285 ? |
@Gunni, I think you're proposing that mosh-server (mosh-proxy?) would 1) tunnel another SSH session to target.example.com (I don't see how you'd avoid exposing the ssh agent to the proxy otherwise) and 2) would forward the UDP session to target.example.com. Have I got that right? It is in fact pretty much impossible for a proxy to know when the session ends (unless it had the Mosh session key, which it wouldn't in the description I gave). The client can disappear at any time and reappear on a different address and/or port, and the server will stop sending messages a short while after messages from the client stop. Pretty much the only two ways a proxy can know about a session's lifetime in the existing Mosh architecture are 1) having the session key and decrypting/observing the session, or 2) maintaining some sort of out-of-band observation of the server's lifetime such as a TCP connection or pipe or something. |
Hey, How about this: Local client authenticates to the first hop, asking mosh-server to start in proxy mode, mosh-server starts and listens for the connection. The local client then exits that ssh connection and starts a new one like this: and on that connection performs the normal mosh-server setup, when ready, exits this ssh connection but leaving mosh-server listening. The local client then sends some packets to the proxy mosh-server, with a "ping" packet, and an encrypted blob to forward to the target ip address. The proxy can never decrypt this blob because it does not have the session keys for that blob. On the target host, it receives the udp frames as per normal procedure, not even caring that the proxy is there. The dead session handler that mosh-server already uses could be used here, currently when i connects it displays a list of idle mosh-servers that i can kill, and i can use the idle kill feature which is already documented. This way:
|
This feature would be super useful. I've just started to use mosh, but it is very limiting to not be able to use the ProxyJump feature. More than half the hosts in my ssh config file use ProxyJump due to firewall policies. |
I have implemented a bodge to allow me to use ProxyJump: #285 (comment) |
This was already discussed on #120, where @keithw suggest using guardian-agent. From IRC:
( @keithw said:
Also said there:
Maybe @keithw could create a new repository called mosh-proxy so people could start sending PRs to have this feature separately of the secure mosh core. |
I built a prototype already: https://github.com/quentinmit/mosh-jump But this really needs to be embedded in mosh/mosh-server, not a separate repo. You should see what I have as a proof-of-concept. |
+1 |
I think it'd be great if there were an official way to accomplish this. I've been getting around this with a wrapper by doing some UDP proxying, bookkeeping, and calling |
This doesn't work for me. Fails with:
This is very important to me since most ISP's here block outgoing on port 22. |
See also #285 |
It could be just a wrapper around SSH as well. Just for enabling replacing SSH by Mosh in VSCode SSH environments for example (It needs SSH forwarding for working as expected) |
Any updates or news here? I'm looking for a way to use mosh to connect to my proxy then proxy jump to another server by ssh. |
Probably not the most efficient way but this is what I am doing to use mosh with a proxy server in between.
|
What is the current status of enabling proxyjump for mosh, possibly based on the two proof-of-concept implementations? I often want to use mosh to work while traveling: mosh used to be the best way to not be drowned by latency. However, these days everything is behind bastion jump hosts, it is very rare to have servers directly exposed. This makes mosh impossible to use without proxyjump functionality: even though the experience is much, much nicer with mosh, it's not much use if we can't use it to connect anywhere. I haven't been able to use mosh for years for this reason, but was really hoping the issue had been solved in the mean while. This github issue is 4.5 years old and still open: is it a "wont solve" or what is the situation? Still fingers crossed that this will be implemented. |
Works in Linux but not in MacOS / FreeBSD / OpenBSD / pfSense which are unable to use the tproxy method thus no UDP. This is stated in the Requirements for sshuttle |
+1, We use an intermediate server to ssh into our compute nodes. With ssh this works through the ProxyJump config. Would love this to work with mosh too. |
ping |
Took the script from @aduong (in the comment above) and added the ability to specify an outgoing port along with tweaking it here and there to cater for my use cases. Comments or ideas welcome You can find it here --> Mosh-With-Jump Here is how I use it with an alias
|
mosh -o ProxyJump proxy.example.com target.example.com (or similar, use ssh config?)
local mosh authenticates with proxy.example.com and starts the mosh server on proxy that forwards the packets to target.example.com.
local mosh then connects to the mosh server on proxy as usual and asks to forward a stream which then gets forwarded to target where it authenticates and finally connects to the mosh server on target.
This way, no agent forwarding is ever required since i can always connect from localhost and all agents and keys stay there.
Also lets me authenticate using my yubikey / pgp key directly with the end host, again, without ever exposing my agent og key.
todo:
The text was updated successfully, but these errors were encountered: