Combining regular ssh with screen has worked fine for me for years. Why would I want to switch to something with a much shorter track record for security?
(By the way: if you want a line-buffered ssh for use over bad connections, run ssh inside Emacs with M-x shell.)
Unfortunately we have very little chance of having an impact on how ip is implemented in mobile network, but we do have the possibility to change our softwares to accommodate deficiencies. Much like HTTP over SPDY is highly similar to HTTP over SCTP, but we have much more chance in making SPDY a reality rather than SCTP.
> Combining regular ssh with screen has worked fine for me for years.
I guess the real novelty (and it's too bad it isn't presented in greater depths) is SSP, the synchronization protocol. It can be an inspiration for other network programs.
Does anyone know how to fix this?
(don't usually ask SO questions on HN but this has been bugging me for years)
It seemed to me as if the mobile browser kept redoing a whole lot of work, ie. essentially re-requesting web sites from scratch. I'd like to make a single request to a web site, have my proxy host complete the request and deliver the bytes piecemeal to the browser as I go in and out of range.
I think it's possible to do this transparently to the browser, but I think you might need a proxy host with a reliable connection as well as a proxy software running on the mobile device that can deal with the situation by telling the reliable host: I'm back, here's a list of running requests and the last byte I received, please continue.
> I generally do not connect to web sites from my own machine, aside from a few sites I have some special relationship with. I fetch web pages from other sites by sending mail to a program (see git://git.gnu.org/womb/hacks.git) that fetches them, much like wget, and then mails them back to me. Then I look at them using a web browser, unless it is easy to see the text in the HTML page directly.
A lot of the problems with mobile networking are the results of connections literally being cut off. On trains I often end up without coverage (tunnels, in the middle of nowhere) exactly for that reason; the connection broke. I don't think that hacking a system based on connections to pretend that this never happens is a particularly good idea.
The major problem with it is that existing protocols need to be reinvented once again to fit new way of communicating. Of course you could encapsulate TCP/IP over it, but then you're losing all nice properties of the protocol.
This doesn't work for me because I use emacs over X11 over a tunnel.
mosh doesn't work because I feel required to use ssh-agent. That is, I feel required to use a password on my ssh private key and not using ssh-agent is too high a burden.
What do you think about Multi-path? I think Apple is already using it for Siri.
I look forward to using regular SSH to connect to my servers hosted in the floating city of New Chicago!
I, for one, look forward to communicating with a deceased person's gallbladder.
Perhaps replying with a non-sequitor is why you were downvoted?
ISPs like Verizon Mobile are NATing everything -- even IPv6 IPs, and running through proxy servers to enable rate-limiting and other things.
As far as mosh is concerned, it feels like it's an extremely overengineered solution to the "I wish I had started this process in a screen session" problem, except you need to be thinking even further ahead than you would normally (installing and connecting via a mosh service, as opposed to remembering to connect to a screen session that can be run with very little prior setup and no client modification).
Where mosh really shines is when your IP is changing too frequently (a mobile problem when you are on the move) and when you are dealing with high latency connections.
When you have to ssh in somewhere over a shitty, barely working mobile data connection - mosh is a lifesaver. It makes an otherwise unusable situation comfortable and productive.
Sure, it's handy for jumping between connections, on/off wifi and so on - but that's easy to achieve many other ways with tools that have been around for a decade or two at this point.
Not necessarily. When I'm thethering my phone's data connection to my laptop I use mosh to ssh into my server because it resists way better to bad connectivity. No matter if I used screen or not, I would still have to kill the ssh process and connect again and reopen screen if I didn't use mosh.
But if I lost connectivity - my SSH session won't be auto-resumed from local machine in first place, I think thats one of the things `mosh` solves.
It promises lower latency etc, but I am just perhaps too slow to notice such things (or both SSH/Mosh feel equally laggy if remote connection is slow enough).
While true, it just seems (to me) that if that's the only problem you're solving (which is to say, not needing to type the command "ssh host" and let your key log you in) and it's at the expense of not being able to properly ForwardAgent (which I require very heavily in my line of work), then it's a lot of work for negative return.
But, again, to each their own. As mentioned below, if your latency over a phone connection is so bad that this helps you, then by all means, use it. :) I'm just noting that for pretty much everyone I work with, this would be a step backwards.
> you could just add a "/bin/screen -DR; exit" to your
> remote .bashrc and the screen integration would be
> completely invisible after the initial instantiation.
- SSH to remote
- on remote, run "screen"
- get disconnected from remote
- SSH to remote, .bashrc runs "screen -DR" and you resume from where you left off
You only have to create the initial screen session once, and it persists until you explicitly shut it down or restart the remote machine.
And what happens if I want to have two terminal tabs on my end logged into the same remote machine? (Which is basically 100% of the time for me.) It seems like that would be a case where mosh would be much smoother...
(Disclaimer: Once upon a time I used screen, but I stopped ages ago. mosh is intriguing, but as long as I'm working from home just plain vanilla ssh is all I really need...)
Multiple terminals in one session was more critical back when we were using dumb terminals and whatnot - where you couldn't multiplex locally.
Don't do that. Open a new window in your screen instead.
Then start giving windows descriptive names. Then start giving them automatic names. Marvel at most fast you've gotten using the window selector (with type-ahead-find).
You can use 'screen -x' to attach multiple times to the same session.
Why is everyone here assuming all programs can be run in a screen session? I run emacs over X11 through a tunnel. This is far superior to emacs in a screen session.
Because that's what mosh is designed for. Graphical programs are off-topic.
By the way, we have used xpra ("screen for X") with success in the past: https://www.xpra.org/
I've solved this by buying FastX from StarNet. I run a server on Linux and display my X programs on my desktop at work. When I get home, where I run the client on my home desktop, I can connect to the same server and disconnect my work clients and reconnect them to my home machine. It's the perfect solution for me.
Alternatively, consider Kerberos and kinit.
I love the idea of mosh, but I find the implementation to be lacking... or I am doing it wrong. :)
I haven't used the agent forwarding patch myself, though. The patch is rather large, which may be the reason it was never merged.
The author (rinne) is the former CTO of ssh.com, by the way.
But -- mosh still can't do proper SSH agent forwarding[0], which is a real drag. Many of my common workflows become impossible. I hope it gets fixed!
[0] https://github.com/keithw/mosh/issues/120