Does it support ssh agent forwarding? The most important missing feature in mosh imho.
Eternal Terminal: Remote terminal for the busy and impatient
41–50 of 73 posts
Re: Eternal Terminal: Remote terminal for the busy and impatient
#42FWIW, I've had a lot of personal success with just plain SSH managing the resumption of sessions. The trick is to not send keepalives from the client, and to not time out idle sessions on the server. When you can control both of these, you don't need extra tooling to resume sessions. That said, it's not as friendly to IP changes, nor does it provide predictive typing, so there's definitely something to be said for th…
I'm curious. What's the ssh options for managing the resumption of sessions?
Resumption? None that I can find in sshd_config but there are several related to increasing tolerances to prevent it from terminating in the first place.
ClientAliveCountMax default is 3 ClientAliveInterval default is 0
Ergo by default ClientAlive messaging isn't used. If Interval were set to 60, the connection would be terminated after 3 minutes.
From man sshd_config: TCPKeepAlive "Specifies whether the system should send TCP keepalive messages to the other side. If they are sent, death of the connection or crash of one of the machines will be properly noticed. However, this means that connections will die if the route is down temporarily, and some people find it annoying. On the other hand, if TCP keepalives are not sent, sessions may hang indefinitely on the server, leaving "ghost" users and consuming server resources.
The default is yes (to send TCP keepalive messages), and the server will notice if the network goes down or the client host crashes. This avoids infinitely hanging sessions."
That's probably not that interesting because it's considered spoofable. Maybe more interesting are the client side ssh_config options which allow for opportunistic multiplexing:
ControlMaster ControlPath ControlPersist
Re: Eternal Terminal: Remote terminal for the busy and impatient
#43Earlier quoted context omitted.
I'm curious. What's the ssh options for managing the resumption of sessions?
It occurs automatically, so long as the client and server haven't timed the other out. The client will time out the server by sending a packet with no response (such as via the 'ServerAliveInterval'), the server via unsetting 'ClientAliveInterval', 'ClientAliveCountMax', and 'TCPKeepAlive'.
All your saying is that the tcp connection doesn't break if you don't send anything whilst either host is not unreachable.
You can break the connection in between and resume as long as your ip hasn't changed.
So it's not really resuming ssh or anything, just a function of tcp sockets. Generally disabled on public since something could open up a bunch of listening sockets and then leave them and never close.
With your servers that you've disabled the keep alive and intervals, if you drop a connection and never reconnect, it's going to keep it open. A malicious could keep opening connections and exhausting your server.
Re: Eternal Terminal: Remote terminal for the busy and impatient
#44Earlier quoted context omitted.
Since it uses SSH to transport the initial session password, as robustly as SSH is.
The initial password is only used for authentication, isn't it? Someone could (unless more details are provided) snoop on the connection or even inject packets.
Hey, Eternal Terminal developer here :-)
A one-time shared passkey is sent over ssh and then this passkey is used to encrypt/decrypt the data in both directions. The server and the client have different initial nonces.
Re: Eternal Terminal: Remote terminal for the busy and impatient
#45Earlier quoted context omitted.
> ...I'd be curious to know how they get around laggy interrupts, e.g. cat'ing a massive file and trying to Ctrl-C out of it. Presumably with the TCP URG flag. That said, I only read years ago that's how it's done, without ever checking myself. I've found references to in in telnet, but not ssh, so perhaps the latter uses some other mechanism.
TCP urgent data only indicates that the application should try really hard to read up to a certain point. It doesn't provide a way to abandon transmission of data that's already been sent with write(). It also generally does not convince routers on the way to prioritize the urgent packet before packets already in their buffers. The way you'd want to use it is not to transmit the Ctrl-C urgently (that direction is cle…
>Of course the tradeoff is loss of scrollback.
That could always be buffered on the server side.
Re: Eternal Terminal: Remote terminal for the busy and impatient
#46So it is mosh, but much better? I'll try it.
The PPA doesn't work. The compilation instructions fail.
Hey, please file an issue on github: https://github.com/MisterTea/EternalTCP/issues
You may be running a distro that doesn't have libsodium (such as ubuntu 14). In this case you have to grab libsodium manually and build et from source.
Re: Eternal Terminal: Remote terminal for the busy and impatient
#47Earlier quoted context omitted.
It occurs automatically, so long as the client and server haven't timed the other out. The client will time out the server by sending a packet with no response (such as via the 'ServerAliveInterval'), the server via unsetting 'ClientAliveInterval', 'ClientAliveCountMax', and 'TCPKeepAlive'.
All your saying is that the tcp connection doesn't break if you don't send anything whilst either host is not unreachable. You can break the connection in between and resume as long as your ip hasn't changed. So it's not really resuming ssh or anything, just a function of tcp sockets. Generally disabled on public since something could open up a bunch of listening sockets and then leave them and never close. With your…
No, not quite.
The Linux kernel will close the TCP connection if it's idle after about 5 minutes (configurable), regardless of the application settings (with one exception noted in a bit). That's why you can even get "connection closed by peer" errors in the first place. TCP keepalive messages are used to circumvent the kernel (and every router between the two endpoints) from closing that TCP connection due to it being idle.
Plus, I can put my computer into hibernation for upwards of 12 hours, and still come in and have a responsive SSH session over a new TCP connection. So long as the key being used to encrypt the session is still in use, and the associated TTY has not been closed out, your client can create a new TCP connection and resume the previous SSH session.
> A malicious could keep opening connections and exhausting your server.
This could (and does) occur regardless of your application TCP settings.
Re: Eternal Terminal: Remote terminal for the busy and impatient
#48So it is mosh, but much better? I'll try it.
To me this seems like Mosh, but worse. I think that each project's approach has different strengths. For me, the best part of Mosh is the intelligent, asynchronous handling of type-ahead. Mosh feels really snappy, even over poor connections. I'm not bothered by needing to run Tmux on the remote for scrollback; I do that anyways, and I have no need for this fancy "control center" mode. My big frustration with both Mos…
I've been using tmux for years and I have no idea what "control center mode" even means :D
Re: Eternal Terminal: Remote terminal for the busy and impatient
#49FWIW, I've had a lot of personal success with just plain SSH managing the resumption of sessions. The trick is to not send keepalives from the client, and to not time out idle sessions on the server. When you can control both of these, you don't need extra tooling to resume sessions. That said, it's not as friendly to IP changes, nor does it provide predictive typing, so there's definitely something to be said for th…
ET dev here.
ET is primarily made for IP changes and also because the kernel/router will sometimes kill stale connections, and it's not possible to send keep-alives if your laptop is asleep.
There is no lag compensation because ET is not a terminal emulator, it's only a remote shell. I cannot create predictive letters and undo them reliably (passing backspace commands to the terminal sometimes does not undo the last letter). Lag compensation would need to be implemented by a terminal emulator such as hyper.js.
Re: Eternal Terminal: Remote terminal for the busy and impatient
#50Can you outline briefly what the benefit of this is compared to mosh?
> benefit of this is compared to mosh? I use byobu (screen) for all the things this is supposed to address. I think. Byobu doesn't keep your ssh connection from dropping but the session is still there once you reconnect with no loss of history. Plus you can connect from multiple clients (using the same user account).
You can continue to use screen with ET and not have to worry about disconnecting/reconnecting.