1. 16
  1. 7

    Just use mosh.

    1. 3

      mosh doesn’t work with port forwarding, or remote display last I checked.

      1. 1

        Good to know. I just use it for terminal access directly to a mosh/ssh host.

    2. 2

      Very interesting read. For someone who knows a bit about networking but nothing too deep, this was insightful.

      1. 2

        Ah, good old CGNAT… I’m glad all of my systems are available via IPv6 and I got it at home, office and on my mobile as well.

        1. 1

          Consider mosh, screen, or tmux. Double for tmux if the remote side runs OpenBSD since I believe it’s in the default install. Also double for tmux when the local side runs Mac OS and you use iTerm as your terminal emulator. On Mac OS use tmux’s -CC option which hides the tmux ‘in-band trigger’ issue transparently for you.

          1. 4

            My understanding of the article and the sleuthing the author did is that neither mosh, nor screen, nor tmux would help. He’s copying large files, and the problem was that misconfigured carrier grade NAT was killing the SSH connection before the official TCP timeout.

            1. 2

              I am by no means an expert on this, but I think that though screen and tmux would both be ineffective mosh might solve the issue. The former are terminal multiplexers, meant to manage and resume sessions – so not fixing the problem.

              Mosh, however, is a different protocol that ditches TCP altogether in favor of UDP and thus AFAIK will not be affected by the timeout.

              1. 2

                I’m not sure you could do file copies over mosh, even like the author did using netcat.