[HN Gopher] SSH alternatives for mobile, low-latency or unreliab...
___________________________________________________________________
SSH alternatives for mobile, low-latency or unreliable connections
Author : nextaccountic
Score : 110 points
Date : 2021-11-02 13:38 UTC (9 hours ago)
(HTM) web link (console.dev)
(TXT) w3m dump (console.dev)
| aofeisheng wrote:
| The idea behind Mosh is almost perfect. Unfortunately, it's just
| a proof-of-concept project that has not been maintained for
| years. Although it has met my daily needs, I'm still looking for
| a better alternative because of some known bugs.
|
| I had hoped on draft-bider-ssh-quic [1], but unfortunately it was
| marked as "no longer active".
|
| [1]: https://datatracker.ietf.org/doc/draft-bider-ssh-quic/
| ViViDboarder wrote:
| What bugs? Mosh isn't a proof of concept. It's a stable
| project.
|
| https://github.com/mobile-shell/mosh
| kapilvt wrote:
| It's stable, but that doesn't mean feature complete, no
| release in over four years in spite of various fixes / github
| commit activity. Additionally the support for jumpbox/bastion
| pass through have been languishing even longer than that
| (https://github.com/mobile-shell/mosh/pull/696)
| NoGravitas wrote:
| Email the author? It does seem like ssh-over-quic would be a
| reasonable way forward.
| acd wrote:
| Can you replace ssh with http/3 and websockets?
| rostayob wrote:
| I've been using this script for years, and it works great:
| https://mazzo.li/posts/autoscreen.html
|
| It's very much like eternal terminal, but requires no upfront
| setup apart from having screen installed on the server.
| kevincox wrote:
| I've been looking for something like eternal terminal for a
| while. I really like using my terminal's scrollback compared to
| tmux and don't cancel/rejoin from other systems often. I really
| just want 1. Allow roaming (close laptop at one place, reopen at
| another) 2. Allow persistence (sleep laptop for the night). I get
| the Mosh advantages, but they aren't worth killing the scrollback
| buffer for me.
| nrclark wrote:
| If you connect to Linux servers from a Mac, you should try out
| iterm2's tmux integration. Iterm2 knows how to manage Tmux
| transparently, so you don't have to even think about it. You
| just get resumable SSH sessions that save your windows and
| tabs, and use normal scrolling.
|
| It's about as transparent/native feeling as you can get, and it
| works really well.
| cassianoleal wrote:
| It's shocking how exactly zero terminal emulators on Linux
| support tmux -CC .
| steve_gh wrote:
| I have a related question to the OP.
|
| What security would you recommend to run on an unreliable
| connection?
|
| To be specific, I have IoT devices which connect to the cloud
| using MQTT-SN. We use MQTT-SN because the underlying connection
| is NB-IoT (required for high penetration into difficult to reach
| areas). The latency on NB-IoT is quite high, which can lead to
| problems with TCP timeouts - so we have been recommended by the
| network operator to use UDP not TCP, which in turn leads to MQTT-
| SN, as it supports QoS 0 (unacknowledged).
|
| But we are also very aware of security issues - so how would you
| put something like TLS onto a UDP datastream?
| afics wrote:
| For TLS over UDP there's DTLS [0] which is probably still
| problematic for your use case since it still requires the
| typical TLS handshake.
|
| [0] https://datatracker.ietf.org/doc/html/rfc6347
| Skunkleton wrote:
| wireguard might be a good solution for you.
| https://www.wireguard.com/protocol/
| Karrot_Kream wrote:
| In addition to what others have said, NNCP [1] is an
| interesting way forward also. Though NNCP may not be stable
| enough for your purposes.
|
| [1]: http://www.nncpgo.org/
| walrus01 wrote:
| I am not the OP but openvpn in its default UDP mode, with long
| timeouts and frequent keepalives set on both client and server
| side, works quite well on unreliable connections. All of the
| crypto available in whatever is the latest version of openssl
| is available for use. If setting it up in a new config these
| days you would want to limit it to TLS1.3 and associated cipher
| suites only.
| mfontani wrote:
| If only mosh had ssh key forwarding, I'd use it more :/
| robotmay wrote:
| Hadn't heard of Eternal Terminal before, but I use mosh quite
| regularly - for portability I remote into my home network via
| Wireguard on an iPad Pro, using mosh inside Blink shell
| (https://blink.sh) to connect to my machines. Over 5G and 4G it
| works very smoothly, but does lag a bit if I drop down to 3G
| speeds. I very much do not regret getting the 5G version of the
| iPad as it's super useful, and I prefer this setup to carrying
| around a hefty workstation laptop. With the magic keyboard
| attached I basically have a tiny but comfortable laptop, albeit
| quite top-heavy.
|
| Having to use tmux isn't a hassle for me as I would be using it
| anyway, and it has the added benefit of being able to connect to
| my active sessions on another machine and pick up where I left
| off.
| codetrotter wrote:
| I've been using Termius https://termius.com/ios paired with
| Wireguard for a long while on my iPhone and generally I am
| happy with Termius as it has very pleasant to use touch
| interactions both for selecting text and scrolling and
| performing arrow keys up/down.
|
| However, the big drawback of Termius is that in the free
| version it will terminate the connection after quite a short
| while as soon as you put the app in the background. They offer
| a subscription to have it not behave like this but I don't want
| to pay a subscription for that feature. (The subscription
| includes additional features as well, but I don't want any of
| those features.)
|
| When I read about Blink shell now, I was kind of hoping that it
| might be a good replacement. I tried it out on my phone, but I
| am a bit bewildered about how to select text using Blink shell.
|
| I am wondering if maybe Blink shell is mainly suitable for use
| on iPad, and not as great to use on iPhone. At least, my
| initial impression is that it is probably fine for use with a
| keyboard but that it is not made for touch interactions to the
| same degree that Termius is.
|
| Edit: I figured out how to select text with Blink shell; double
| tap and drag [1]. Unfortunately it feels quite clumsy and
| awkward to me compared to Termius. Not just the motion itself,
| but also how the resulting selection is handled. I will keep
| trying to use Blink shell for a while though. After all, Blink
| shell is open source and so if I like it a lot I could maybe
| rewrite the touch interactions to be more in line with what I'd
| like them to be.
|
| [1]: https://github.com/blinksh/blink/issues/1116
| loxias wrote:
| Is there any answer other than "mosh, duh"?
|
| Keithw (who's now a prof at Stanford) wrote mosh _for_ that use
| case (high loss high latency), if memory serves correctly. (which
| it might not! being as apparently an entire _decade_ has passed
| since "what feels like last month")
|
| Also, there's some terminal cleverness, which I admit, to great
| embarrassment, I still haven't bothered to deeply understand (my
| "sensai", who offered to help me grok it if I ever got stuck,
| left this world too soon).
|
| Mosh's ability to preserve interactive responsiveness, even
| through the most high latency, low bandwidth, high packet loss
| environments is _unparalleled_! You know, for all those times
| when you 're on a cross country flight, your only network access
| is a IP-over-DNS tunnel, and you simply _MUST_ ~zephyr~ chat with
| your friends. Uh, I mean, do mission critical work... ;)
| evilos wrote:
| Probably just a typo but you likely meant "sensei" which is
| mentor/teacher/senior where "sensai" is detergent.
| loxias wrote:
| Thanks :) I'm embarrassed, I can't edit the comment anymore.
|
| Making it more amusing, I _know_ I suck at spelling so I even
| googled "sensai" first, before posting, quickly saw that it
| didn't have the "did you mean...?" prompt, and assumed it was
| the right spelling. Oops. :)
| hosh wrote:
| I agree.
|
| I'm not sure what this author is talking about with tmux + mosh
| and adding the latency back in. Maybe because I run the tmux on
| the remote server and I mosh in. I don't miss native windowing
| or mouse controls at all, and still have scrollback. I modified
| the keybindings so it is easier for me (as a vim user) to
| remember -- including window splits, layout changes, and
| adjusting pane sizes.
|
| I don't just use mosh in high latency, low bandwidth. The fact
| that mosh will reconnect even after I close the laptop (and put
| it in suspension), move from wifi network to cell and back,
| it's all fairly seamless. That makes it practical for my
| primary dev and ops environment on a remote server. I have had
| this setup for about 5 years now and use it every day.
|
| I used to use something like autossh, and it did not work as
| well.
| jwong_ wrote:
| I love Mosh and use it every day. One area it's failed on me
| however, is that I always thought it was supposed to self-recover
| in connection failures.
|
| In practice, it means that every time my laptop goes to sleep, or
| loses wifi for an extended period of time, I need to do an
| interrupt sequence and re-start it. Not the biggest deal, but
| things would be so much better if there was a way to configure it
| to re-try every so often instead.
|
| > mosh: Last contact 9:45:19 ago. [To quit: Ctrl-^ .]
|
| I'm not sure what the use of this message is -- surely you would
| think after 9 hours, trying again would be worth it.
| ikornaselur wrote:
| Hm, strange! I've had it recover from my laptop being asleep
| for hours at a time. I've seen the last contact message tick up
| until it suddenly manages to make a connection and spring back
| to life!
|
| I do just use default settings (just always set up mosh server
| on my remote servers and forget about it), but is it possible
| that there's some timeout on the other end you could be
| experiencing? If for any reason you kill the session on the
| other side, then of course it doesn't work, but for me it's
| always magically connected again.
|
| I've used Mosh for multiple years, always loved it, until
| recently when I started using tmux more. For some reason I had
| loads of problems with colours and the only solution I could
| find was to manually build it from source with some flags, or
| even potentially it was a fork or something like that. Just
| started SSH-ing again (usually have a stable and fast
| connection) and if I lose the connection, I'll just re-attach
| the tmux session anyway.
| jwong_ wrote:
| Interesting, maybe there's something up with my config. I
| also run a default setup but the backend is a macintosh, so
| that may be related. It would be really nice to have it
| magically reconnect!
|
| I actually use tmux in combo and don't see any color issues
| that I notice. I wonder if it's something about the colors in
| your tmux config?
| quesera wrote:
| I run ssh/mosh on a Linux laptop to my Mac desktop all day
| every day. I suspend the laptop every night, and when I
| open it in the morning, it immediately reconnects.
|
| I run tmux (nested both locally and on the Mac) but I don't
| think that would make a difference here.
|
| I'm not aware of any special config, but I've been using
| this setup for several years with no major adjustments.
| andreasha wrote:
| you can auto re-attach the tmux session or create new one
| with something like this in your bash_alias or bashrc.
|
| # tmux auto attach or create new session [ -z "$TMUX" ] && {
| tmux attach || exec tmux new-session && exit;}
| eminence32 wrote:
| Is it possible that your server IP address is changing? Or that
| there is some statefull firewall between the client and the
| server that is getting in the way?
| brunoqc wrote:
| > Guardian Agent: SSH forwarding means you can remotely connect
| on to other systems over SSH without needing to install Mosh on
| every one of them.
|
| What? Isn't guardian just an agent? You can use ssh forwarding
| without it.
|
| Guardian does look nice but seems abandoned.
| neilk wrote:
| Perhaps a tangent, but I found this exchange between Bradley
| Fitzgerald & Dewitt Clinton fascinating. Tailscale manages to not
| drop ssh connections even while the remote machine is being
| updated, with vanilla TCP.
|
| https://twitter.com/dewitt/status/1329104663975587840
|
| I too remember the era of ssh connections feeling strangely
| robust. I don't know enough about networking to fully understand
| how this works though.
|
| But if that's possible at a networking level and all we need is a
| stable IP, then could an appropriately configured VPN solve these
| issues?
| exabrial wrote:
| Does ssh require TCP transport? Wonder if you could do MPTCP...
| or if QUIC actually offered an un-encrypted mode, could be an
| option too.
| chasil wrote:
| SSH is problematic for several use cases.
|
| It is easy to future-proof the crypto for anything other than a
| quantum computer: Ciphers
| chacha20-poly1305@openssh.com KexAlgorithms
| curve25519-sha256@libssh.org
|
| That is also the fastest cipher for any hardware lacking AES
| acceleration, but clients configured this way will never talk to
| older servers (or vice versa).
|
| File transfer is a real problem for SSH. The scp command is being
| slowly excised because of its security problems.
|
| https://lwn.net/Articles/835962/
|
| The replacement sftp protocol simply does not perform well, and
| the performance problems are explicitly not a development
| priority.
|
| https://daniel.haxx.se/blog/2010/12/08/making-sftp-transfers...
|
| Redesigns are on the table:
|
| https://www.psc.edu/hpn-ssh-home
|
| At this point, if someone baked the chacha20 cipher into vsftpd
| (replacing TLS), I would take it for internal use.
|
| Wireguard is also an option, allowing us to simply use telnet and
| cleartext ftp (promiscuous mode on localhost would be a potential
| path to abuse).
|
| In any case, people where I work have standardized on scp and
| sftp for communication between many disparate architectures, and
| few realized the problems this would bring.
| devwastaken wrote:
| Sftp is also not that great. To transfer a folder with children
| you have to create an empty folder of the same name on the
| server. Only then you can transfer the client folder, but it
| doesn't go into the server folder of the same name. Perhaps
| stack overflow was just entirely incorrect, but that's how I've
| had to do it with limited systems in the past.
| mzs wrote:
| $ tar cf - foo bar | ssh user@host tar -C baz -xvf -
| chasil wrote:
| That can bite you if the remote tar allows absolute paths.
| technofiend wrote:
| I use this locally as well, simply because I know and
| prefer tar's behavior to that of cp. For example _tar cf -
| . | (cd /some/where/else; tar xvf -)_. It's possible to do
| this using cpio as well but it always seemed like cpio
| needed so many more switches to do the same thing.
| loxias wrote:
| _high five_
|
| It truly is the best, no? My pipelines look a bit different
| than yours (they usually have `lzop`/`zstd`, `cd`, and
| occasionally `pv`), but tar truly is the best file copy
| utility.
|
| I rarely use `cp -a` even when copying locally. `tar` is so
| much faster.
| spockz wrote:
| Then why isn't cp-a and alias for tar?
| loxias wrote:
| Because that's not how you use it. :) But you raise a
| decent point. I'll write a short script you could alias
| to cp in most cases, put it somewhere, and edit this
| comment in a day with a link.
| xioxox wrote:
| You can also use lftp to transfer a directory tree using the
| sftp protocol: $ lftp sftp://hostname
| lftp ~> cd somedir lftp ~> mirror . lftp ~> quit
| tialaramex wrote:
| > if someone baked the chacha20 cipher into vsftpd (replacing
| TLS), I would take it for internal use.
|
| Um. TLS can do chacha20 just fine if that's what you want. In
| particular in TLS 1.3 you can insist on only doing
| TLS_CHACHA20_POLY1305_SHA256 if for some reason you really
| don't like AES or maybe block ciphers in general.
| chasil wrote:
| The overriding goal was simplicity for an embedded solution.
|
| Yes, throwing up an stunnel in front of port 23 enables
| telnet-ssl, but this is a bit heavy for a small machine.
|
| I actually have an emulated VAX running VMS 7.3, and the C
| compiler on this machine does not support 64-bit "long long"
| so AES-CTR is the best that it can do (and chacha20 won't
| compile here).
|
| In this case, a version of chacha20 for K&R C would be very
| handy. As you can imagine, sftp for this machine has been a
| unique challenge.
| adrian_b wrote:
| rsync over ssh works perfectly (i.e. with the rsync option
| --rsh="ssh").
|
| Not only it works much faster than scp or sftp, but it also
| does not lose any file metadata.
|
| I have not verified if newer ssh versions have corrected this,
| but a few years ago scp and sftp failed to copy extended
| attributes and on some file systems they truncated timestamps.
| chasil wrote:
| I understand and sympathize with rsync advocacy, but there
| are two major problems here.
|
| The first is the license. Because rsync is under the GPL, it
| will never be bundled in the OpenSSH.com distribution. It is
| even missing from OpenBSD base (just confirmed, and loaded it
| with pkg_add - there are two versions, one with iconv).
|
| So let's take Microsoft's implementation, which will forever
| lack rsync (as they haven't touched it in well over a year).
|
| The file transfer agent needs to be under the same license.
| adrian_b wrote:
| rsync is a different program than ssh, installed as a
| different package, so it does not matter what license it
| has. In most cases, ssh will run a bash at the remote end,
| which also has the GPL license, so it should be obvious
| that it is irrelevant what license have the programs
| launched by ssh.
|
| When you run rsync over ssh, the local rsync starts the
| local ssh client, which connects to the ssh server, which
| runs the remote rsync, while the data is piped through the
| ssh connection.
|
| rsync is available for most operating systems, but it is
| not usually installed by default. OpenBSD might be the only
| exception without a rsync package, but it has openrsync. I
| assume that it uses the same protocol so rsync to/from
| OpenBSD should work as well as to/from Linux, Windows,
| MacOS or any *BSD.
|
| If you have the right to transfer files to a computer then
| normally it is very simple to install rsync, only for your
| own user if do not have admin rights.
|
| In most cases, you can initially just copy the rsync
| executable file to the target computer using scp, and then
| do any other file transfers with rsync over ssh.
|
| After I have abandoned both scp and sftp many years ago, I
| no longer had any problems with the performance or data
| integrity of file transfers over ssh.
| chasil wrote:
| Android will _never, ever_ install rsync into base.
|
| Nor will OpenBSD.
|
| The rationale for this decision is not technical, it is
| idealogical.
|
| A technical solution to this problem is insufficient.
|
| To be honest, I was unaware of this:
|
| https://www.openrsync.org/
|
| For maximum utility, it should be bundled with OpenSSH.
| adrian_b wrote:
| I have already written that OpenBSD has openrsync, so
| there are no problems with OpenBSD.
|
| Because openrsync has a BSD license, it can be used on
| any other system that completely avoids GPL programs.
| loxias wrote:
| I'm probably living in my own little bubble, but I didn't
| know anyone used sftp for ANYTHING, at least not in the last
| decade.
|
| Looking at my terminal history, scp for a single file, rsync
| (which you don't need to pass that --rsh flag to.. during the
| 21st century ;P) for anything that requires the ability to be
| interrupted and resume gracefully (which is most cases), and,
| in the rare case when I need _speed above all_ , the "tar
| lzop ssh bash pipe" trick (I don't know if it has a canonical
| name) is correct.
|
| Isn't this what we all do?!? If there's a better way, I don't
| see how, but would like to know.
| hosh wrote:
| sftp still used extensively in banking, payments,
| transferring financial data, or datasets like student
| information from school districts or information on lawyers
| from bar associations.
|
| Back in 1999, in one of my first professional gigs, people
| were still using ftp for sensitive data for automated data
| transfers.
|
| Rsync+ssh would be great, but enterprise IT is slow to
| change.
|
| AWS has hosted sftp backed by S3, and it's going to stick
| around for a while.
| Bluecobra wrote:
| Sadly in 2021, ftp is still used extensively in financial
| services for stuff like clearing stock trades. I wish
| more institutions use sftp/scp for this and stop relying
| on allowing specific IP addresses for security.
| magicalhippo wrote:
| > I didn't know anyone used sftp for ANYTHING, at least not
| in the last decade.
|
| We're moving customers from _FTP_ to SFTP. Most recent one
| was a well-known Fortune 500 company, which uses it to
| exchange some ASCII flat files with our software.
|
| Mostly it's for XML files or PDFs.
|
| It's simple, it works and it's easy for support to poke and
| prod.
| lathiat wrote:
| FWIW sftp vs scp is more about the protocol. Apparently new
| OpenSSH has an "scp" command that uses the sftp protocol.
|
| But yeah Rsync is a good choice.
| jcynix wrote:
| > sftp for ANYTHING
|
| Solid Explorer (Android app) connects via sftp to Linux
| machines just fine. While I use Termux and rsync to do
| backups and bulk transfers, Solid Explorer allows me to
| rapidly browse remote files.
| andylynch wrote:
| Like someone else said sftp it's huge for B2B and probably
| is part of how you get paid. *ftp is blunt but nice when
| dealing with other parties since it interoperates well,
| everyone has it, and (most of the time) it just works
| whether you are talking to a Linux box, IBM MQ, or
| something else altogether.
| przemub wrote:
| I use sftp every now and then I need to pull something and
| I don't know where exactly that is. A shortcut for finding
| the path via ssh and then pulling the file via scp, if you
| will.
| loxias wrote:
| That makes sense!
|
| In that rare situation, I typically use tab completion to
| find the remote file. However, I bet that would SUCK on a
| high latency or low bandwidth link, where sftp would be
| just fine.
| wumpus wrote:
| > rsync over ssh works perfectly
|
| I use rsync+ssh a lot, and it doesn't exactly work perfectly
| on long-distance 10-100 gigabit networks: ssh has a buffering
| problem at high bandwidths which the maintainers won't accept
| patches to fix.
| effie wrote:
| > ssh has a buffering problem at high bandwidths
|
| This is interesting, can this be the reason for why playing
| 720p video in Firefox run with ssh and X11 forwarding is
| fine bandwidth-wise (easily 1Gb/s) but it causes
| responsiveness to mouse/keyboard actions to go into abysmal
| 5-30s territory?
|
| Any references to the ssh buffering problem out there?
| adrian_b wrote:
| That is a limitation of ssh.
|
| Using scp or sftp would limit the transfer speed to a value
| several times lower than rsync in any case.
|
| On short distance 10 Gb/s Ethernet I did not see problems,
| but it does not surprise me that on long-distance links
| they appear.
|
| In such cases, if full speed is desired, it is likely that
| ssh must be replaced with either IPsec or a tunnel over
| TLS.
| wumpus wrote:
| scp has exactly the same limitations as ssh, it's the
| same code.
|
| I don't know anyone in the HPC world who uses "IPsec or a
| tunnel over TLS".
| Datagenerator wrote:
| Tried rclone yet? Does it all, parallel and fast.
| tyingq wrote:
| tar over ssh also does well with file metadata.
| xorcist wrote:
| rsync has almost the same syntax as scp, and is really what scp
| should have been. Use it instead.
| [deleted]
| walrus01 wrote:
| no mention of gnu screen or termux to maintain a persistent
| session when your ssh link drops over a very flaky connection?
|
| those are, in my opinion, essential tools to know how to use.
| opan wrote:
| The multiplexer is called "tmux", "termux" is a terminal
| emulator for android.
| pca006132 wrote:
| Speaking of SSH, I thought of vim/neovim. I frequently use neovim
| over SSH to company's computer for development, but the
| experience is horrible if the connection is unstable. If I
| remember correctly, other editors such as VSCode SSH plugin uses
| a local buffer for editing which is much better when the network
| is slightly unstable or high latency. Wondering if there is a way
| to do this for vim/neovim...
| dietr1ch wrote:
| tramp-mode does this on emacs. It's nice that it's just opening
| a file with only the `/ssh:user@host:` prefix, but a few things
| need tweaks (project tree, shell). BTW `/sudo:user@machine:`
| works too.
|
| It still feels like there's value in making this work simply
| outside of emacs so more programs can make use of the cached
| copies. Is there a more resilient alternative to `sshfs`?
| Jeff_Brown wrote:
| Tramp mode is great. My only pain point with it is it
| operates purely in serial.When i save a buffer i have to wait
| for it to complete on the remote server before I can switch
| to another. It's almost enough for me to want to open a
| separate emacs instance for each remote file I'm editing.
| (Which in tmux might even be feasible ... hmm ...)
| nousermane wrote:
| For the same snappy "local buffer" experience with ssh/vi, you
| can mount remote repo using sshfs, then open with vi from that
| local mount: sshfs
| user@computer.company.com:/home/repo ~/repo vi
| ~/repo/file.py
| des429 wrote:
| 'vim user@computer.company.com:/home/repo' also works afaik
| :-). Vim has support for this built in.
| [deleted]
| pca006132 wrote:
| Thanks, I've heard of this earlier. However, I use ssh as I
| don't want to install some development packages on my local
| computer, and I need language server to work (which requires
| the development environment to work properly). sshfs is not
| an option here as the problem is the development environment
| rather than the files.
| wumpus wrote:
| mosh + {emacs,vim} work pretty well on less-than-perfect links.
|
| One thing that I might miss with a local buffer is good syntax
| checking support (I use "flycheck" in emacs) -- it requires the
| server's software, and so composing local editing with server-
| based syntax checking sounds pretty hard to get working well.
| memco wrote:
| There's a neovim plugin in development which aims to solve
| this: https://github.com/chipsenkbeil/distant.nvim.
| bee_rider wrote:
| I think whoever wrote their title messed up -- "low latency"
| sticks out at being the one non-problem in the title (and the
| article deals with high latency).
| loxias wrote:
| This jumped out at me too!
|
| It's the author's mistake, not whoever posted it here.
|
| Which makes me question how much consideration should be given
| to one who doesn't know what latency is. :) Assuming the best,
| it's a typo, we're all human. On the other hand, it's been more
| than a _month_ (article was updated 2021-09-22) and he still
| hasn 't corrected it...
| shim__ wrote:
| Using Wireguard is also an good option to prevent the connection
| from being dropped when switching networks
| Bayart wrote:
| I remember picking up Mosh when it was shown on HN as an MIT
| student project. Apparently that was back in 2012 [1]. Time
| flies.
|
| I've used it on and off over the years, mostly when having to
| work on a fast train and a flaky 4G connection.
|
| [1]: https://news.ycombinator.com/item?id=3819382
| ViViDboarder wrote:
| > However, tmux waits for the remote server to send the new
| screen contents which somewhat defeats the purpose of Mosh. Mosh
| removes any latency by not waiting for the remote server, but
| using scrollback through tmux adds that latency back in.
|
| I don't follow. Is this user running mosh inside a tmux session
| rather than running tmux inside the remote shell?
|
| I don't see how tmux adds latency back in.
| [deleted]
| gorgoiler wrote:
| Is there a way to reconcile the duality of tmux and i3wm fighting
| over terminal/window management?
|
| I am very frequently logged into remote systems, running tmux,
| and multiple terminals. At the same time I have multiple window
| manager windows running multiple of these tmux sessions.
| Different types of window arrangement. Different types of
| clipboard. Different keybindings. Different support for focus
| follows mouse. It's janky af.
|
| This article alludes to an iterm2 specific solution to the
| problem. I would dearly love to figure out a general one for my
| window manager of choice.
|
| Help.
| tomxor wrote:
| > The client will also disconnect if your IP address changes, or
| there is a temporary loss of connectivity.
|
| Not to mention CGNAT doesn't have large enough memory to respect
| TCP keepalive, it will drop your connection in a heartbeat if you
| even look at the session funny. I only have mobile internet at
| home and it was a pain until I wrapped it up in wiregaurd
| permanently.
|
| Using SSH is now bliss... TCP keepalive is respected, an idle
| prompt will actually stay alive for the full 2 hours, which is
| basically impossible on any consumer internet connection today. I
| can switch physical connections without worrying about it
| dropping too... even when packet loss is crazy high wiregaurd
| ensures SSH doesn't know enough to drop the connection. I no
| longer worry about losing connections enough to usually not
| bother with tmux until I actually need multiplexing.
|
| My internet experience in general has improved ever since using
| wiregaurd.
| dqh wrote:
| Or solve at a lower layer - it's possible to configure an IPsec
| VPN so that it can reconnect without dropping TCP connections.
| Even if you change IP address. I had great success doing this
| using FreeSwan to manage IPsec on a Linux server, and with the
| native macOS IPsec client.
| nextaccountic wrote:
| The two alternatives in the article were previously discussed in
| HN as well: mosh (https://news.ycombinator.com/item?id=28150287)
| and eternal terminal
| (https://news.ycombinator.com/item?id=21640200)
| eminence32 wrote:
| > The main downside with Mosh is that it emulates the terminal
| remotely and only sends the visible state of the terminal back to
| the client. This means if you have a lot of output from a
| command, you will only be able to see the result that would have
| been visible in the terminal. This is known as the scrollback
| buffer. It's a known limitation in Mosh because it focuses on
| efficiency and solving issues with poor connectivity, so it makes
| sense to only send the visible portion of the terminal.
|
| This is indeed one of the biggest downsides to mosh, and is a
| very often requested feature. But I am pleased that this article
| framed the lack of scrollback as an explicit design decision, and
| didn't simply call it a "missing feature".
| loxias wrote:
| One person's "bug" is another person's feature.
|
| In my usage, and opinion of mosh, the remote terminal emulation
| is at least half the point. It lets you be functional with
| minuscule amounts of bandwidth, and makes your sessions more
| responsive when you have plenty of it. It's efficient
| (enlightened even...) to solve an engineering problem using the
| appropriate distribution of resources (bandwidth, cpu, memory).
|
| A remote terminal that wasted resources sending things that
| would be invisible anyway strikes me as not just less useful,
| but really mediocre/lazy design.
|
| (IMHO, of course!)
| gsich wrote:
| This can also be solved with programs like screen and tmux.
| Requires some work though if you want the seemless scroll
| function.
| Johnny555 wrote:
| It's also a feature since if you accidentally send a lot of
| output to your screen, you don't need to wait for the buffer of
| incoming data to clear before your Ctrl-C will stop the data.
| You can Ctrl-C and stop it immediately.
| est wrote:
| The only thing missing in Mosh is SSH tunnel support.
| NoGravitas wrote:
| For me, it's agent forwarding.
| m-p-3 wrote:
| Basically why I stay with SSH, it's my poor man's VPN.
| aftbit wrote:
| I'd love to see something that used TCP so I could route it over
| Tor but offered local prediction like Mosh.
___________________________________________________________________
(page generated 2021-11-02 23:01 UTC)