As for predictive character insertion, when i'm working in a shell, especially with high latency, i prefer my commands to be as i type them, not something some algorithm "guessed" i was going to type.
That's not what mosh is, it doesn't predict what you're going to type. It however proactively renders the characters you type before it receives confirmation from the tty on the other end.
In other words, imagine typing ssh somebox.typo.com and waiting 1 second before the text renders and discovering the typo, then pressing backspace, waiting a while for the backspaces to render, then going through all of this again. With mosh you'll be able to instantly see what you typed and fix it. On high latency connections it makes a huge difference in quality of life.
Mosh support roaming and intermittent connectivity which is really super useful if you have to debug a server on a very dodgy 3g connection in a moving train.
tmux solves the session resumption at a lower level. You can have a connection from home, jump on a train, open your laptop and keep typing and do the same when you get into the office. You don't need to re-auth each time (or deal with delayed disconnects).
It works well WITH tmux, not instead of tmux.
Which means your solution would be something like:
It doesn't guess. It sinoly has local echo, and the characters that are not-yet-ack'd are underlined. Changes your life when working with 175ms+ latency
I don't think you missed anything.. I'm pretty sure I've seen a few similar apps like this on HN, but I don't really understand the draw of them over just using ssh's built in options.. You can even configure tunnels in ~/.ssh/config for "aliases".
there's multiple ways to make tunnels in ssh. -L is one of them (local forwarding). basically, local, remote and dynamic forwarding are possible. there's some interesting uses for the latter 2 as well so if you only know -L it might be nice to check out the other methods and how you can use those. You can for example, forward a remote localhost port of a server to your own localhost, and then have a fully encrypted channel to some internal or locally bound service. for example if some server hosts a site on it's loopback or some service is listening there which you want to interact with, then you can do it directly from your own machine instead of through an active ssh session. (for example with websites this is useful, because then you can have a graphical browser instead of links via ssh x11 forwarding or w/e)
I think it's worth drawing attention to it. It's a very useful feature; just don't tell the network administrators.
NB including
*:
does mean anyone on your local network (assuming a firewall at the gateway) can use your computer to proxy to work. That's great if you're on a private LAN and want to look at a work site on your phone, but not great at a coffee shop.
And when that proxy is worth it's salt, it shall detect attempts to tunnel plain ssh over said ports.
This is 2018, anyone who can bypass their corporate proxy with that example, should find employment elsewhere or atleast prepare to do so since your company's internals will surface on twitter any time now.
This command actually fails if /usr/local/bin doesn't exist. He could simplify it by releasing the binary alone and running `curl -L --create-dirs -o /usr/local/bin/mole https://...`, but my guess is uncompressed it's huge. (edit: possible that the GitHub server would support `curl --compressed ...`, allowing the HTTP connection to compress it in transit)
I have a number of connections I need to maintain - e.g. have reopened automatically - and I've been using Secure Pipes on Mac for a couple months now, very happy with it.
If it's easy for you to remember ssh syntax, then for you ssh is the better tool.
As far as I'm concerned, I never remember the different syntax between -L, -R, -D, etc. Always have to read a doc somewhere.
operations are easy :(c)reate, e(x)tract, (t)est
options the same: (f)ile, (v)erbose, g(z)ip compression.
the only illogical ones is bzip2 compression and xz compression with -j and -J
I think i can remember cpio syntax as well, though i haven't used that i a decade, but did use it quite often in my old sysadm job.
This seems to imply that he is not 'storing other things in life' because he's able to remember that L=local forwarding R=remote forwarding and D=socks proxy
You can do the same thing with the ~/.ssh/config file. Add a configuration block for the host you want to connect to with the ports you want to map. I agree that an official user interface to editing the config with the most common examples would be really handy.
This is a fantastic tool! I've always had to reference a markdown file with SSH tunnel syntax whenever I wanted to create one. I can see myself using this quite a bit in the future.
This whole thread makes me think of Alan Cooper, and how he bashes developers in The Inmates Are Running the Asylum basically as people out of touch with the rest of humanity in that we got used to rudimentary tools and our love for them and maybe the time and pain spent learning them makes us victim blame users, not that your comment is doing that, but maybe we do that unconsciously.
I was going to comment on the whole persona thing he started but it’s to early in the morning for such things