Or perhaps it could all be done in the client? It's the client that needs to free up listening ports in some cases, but also the server may need to free up remote listening ports if there is a drop-out. Ssh -Y can see there is more to it than meets the eye. Mosh -Y on the other client end, the mosh client runs local: On topic of tunneling connections, auto-respawning a tunneling ssh from mosh is related to various proxy/jump features like #970 #285 (there are a lot of Prox圜ommand and jumphost github issues floating about and probably at least half of them are actually, not at all, my thought was much more primitive - to literally pipe the users command text straight through to. Something like http(s) or RDP traffic that can handle a socket getting reset would be fine, but I don't know if X11 is as fault-tolerant (my knowledge is stronger in OSI layers 2-6 rather than layer 7 protocols). When autossh respawns a connection, it's not the same connection and some software might not handle this well. This solves the problem of keeping a socket "open" across IP changes, but it still leaves up the problem of a persistent connection. SSH will automatically tear down a connection it thinks is broken (albeit after some delay), and autossh can start it right back up with the new IP. If you place a dependency on systemd, that limits it to systemd-based Unix and Linux systems- potentially locking macOS, Windows, Cygwin, Windows Subsystem for Linux, and even init-based linux systems out of this feature.Īs for whether it might work, I'd say it's at least a good start. One of the best parts of Mosh is how platform agnostic it is. Going that direction, I'd rather see autossh than systemd sockets for the implementation of this. how about passing that string straight through to the server yeah? after cleansing it for XSS vulns. correct me if wrong but I understand Mosh is currently doing it's awesome magical business regarding intermittent and dynamic IP environs by maybe setting up a UDP listening port and wait for a listener that is able to report the PID code / authentication token that matches a live running user session on the box in question. a channel for arbitrary congestion-controlled octet streams that roam and handle intermittent connectivity gracefully.Įxcuse my ignorance, but. Yep thats a string i used to use at some stage in my you mention you thought the main blocker to be needing to have: but perhaps mosh can start ssh client sessions in the background to support custom parameters? this is one of my connect strings: I understand the reason mosh does not support X11 is that mosh is a virtual TTY terminal emulator. perhaps this would need to terminate the older ip address processes to free up the local ports for the new ssh proxy process? it could check for parameters like -D 8888 (dynamic socks proxy), -L local port forwards, -R remote etc. say you were monitoring the IP address and the mosh client detects a change in gateway etc. I had an idea - how about firing up a new "proxy" ssh connection each time mosh either detects an IP address change or somehow when the client requests data.
0 Comments
Leave a Reply. |