I have spent the last 5 years or so looking for a thing that I begin to conclude nobody has made, and I have no idea why.
I want an `ssh` that is transparent to client IP address migrations (i.e. things like mobile hotspots, wifi-to-ethernet cable swaps, etc...)
Please do not say "mosh". Mosh is for *interactive* shell use. I am using ssh as a data transport for an application. (1/3)
Specifically; on a client of mine I run
ssh USER@HOST -t perl -E SOME-CODE-HERE
and this connects to the given host as the given user, and runs the code. The code contains a little injected program that just basically pipes to a local UNIX socket, which is where my server program really runs. But that part is not too essential.
What I'm using ssh for here is
* Secrecy
* Authentication
* User-addressing
* Application-addressing
(2/3)
After 5 years of not being able to find any suitable replacement for this, I am coming to the conclusion that I will have to make it. Which upsets and annoys me because I would have thought someone else had by now. But anyway.
I'm therefore starting to think about things like names for whatever I make, and bits and pieces of technology to use to create it.
Suggestions welcome. (3/3)
@leonerd: I think the point is that for being able to roam, you'll need something else than TCP (e.g. UDP), but #SSH requires TCP…
That's also why #Mosh uses UDP after authenticating and bootstrapping via SSH.
So I see two possibilities for that:
Use SSH over a non-TCP based tunnel like #WireGuard (https://www.wireguard.com/).
Or reconnect everytime the client IP changes again, e.g. with #Autossh (https://www.harding.motd.ca/autossh/) and maybe GNU Screen or Tmux. But that's usually interactive again yet.
@xtaran screen or tmux are interactive, for terminal use. They don't behave like a "dumb serial port".
The key thing about using ssh in this manner is that everything is transparent to the application. It's a long-lived bidirectional fully-duplex stream of arbitrary random bytes. Either side can just send at any time and know the other side will receive it. This is the part I want to preserve.
@xtaran Huh? A custom program could easily do this. I've spent 5 years hoping someone else had already written that custom program so I don't have to, but it appears not. It seems I will have to write it then.
I am not looking forward to having to reïmplement the authentication and secrecy parts of ssh. I am still hoping I can find some other implementation of those parts, so I can just add the user/application addressing and stream coherence on top.
@leonerd: But frankly, if I just want a never disconnecting pipe over SSH, I'd use Wireguard tunnel and then running SSH over it (if Wireguard is possible). I do that at some places.
And for sessions which are fine to respawn the tool on the other side (i.e. if it's idempotent), I'd just use Autossh. I use the latter for longer than Mosh is in Debian, usually (but not always) calling "screen -Rd" on the other side. Never used it with a pipe directly, but it IIRC works with port forwarding.
@xtaran Wireguard is a VPN, yes? It's not an application thing. It's a thing a user sets up as root in certain specific circumstances.
I'm wanting an application transport. I don't see the likes of telegram or whatsapp using wireguard to connect their mobile apps to their servers.
@xtaran Actually another way to do it is to flip the thing entirely upside-down.
Use ssh as the transport with some kind of multi-path mux setup around it. The client can start one or more of those tunnels, choose the best one, it knows when to switch; but then you need some demuxing container on the server end to ensure your actual application connection can outlive those individual sessions.
Plus it still has the TCP head-of-line-blocking problem to deal with.
@xtaran Huh there might be some mileage in those as a starting point then. If folks can tunnel ssh on top of QUIC it does suggest it has enough full-duplex ability to do this.
I'll take a look at that :) Much thanks for finding those.
@xtaran If QUIC can do arbitrary bidirectional full-duplex push then sure. Plain HTTP is purely request/response so it's no good here but maybe QUIC has solved that thing? But I don't believe QUIC already solves the user authentication part of the problem, which again ssh gives me for free.
Don't forget that once connected, ssh really does feel totally transparent like a pipe, plain TCP socket, serial port, etc... and that is a really strong attraction. You don't get that at all out of HTTP.
Paul Evans
Axel 🚴😷🐧🐪⌨ | #WeAreNatenom
James Gilbert
Reto