15 ms·
Eternal Terminal: Remote terminal for the busy and impatient
- notheguyouthink 9y agoAfter skimming the "How it Works" page, 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. With Mosh, there's no giant delay because they don't care about history, they're just sending snapshots of the latest data. Hence why they use UDP as well. ET however uses TCP, and some type of BackedReader and BackedWriter for TCP data - which _implies_ to me that everything is being sent/received in a massive queue. Also, it supports scrolling, which would be difficult _(but not impossible)_ if they only cared about recent frames like Mosh. Finally, I'm curious how well it handles mobile connections. That's another selling point of Mosh. Admittedly I never use mobile internet, so that's not a concern of mine, personally. I love Mosh and I'm always happy to see competing apps, hope they complement each other well :)
- RJIb8RBYxzAMX9u 9y ago> ...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.
- geofft 9y agoTCP 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 clear), but to transmit the interruption of the reply urgently back to the client. And I think there's nothing that will save the server from having to actually send all the bytes that you managed to attempt to send before you received the Ctrl-C. Also, it's completely broken: https://tools.ietf.org/html/rfc6093 https://tools.ietf.org/html/rfc6093 mosh works around this by rendering the terminal window server-side and sending diffs of the terminal window (think VNC or streaming video) to the client. So the in-flight data from server to client is at most a screenful. If the data isn't sent in the first place, you don't have to worry about unsending it. (Of course the tradeoff is loss of scrollback.)
- btym 9y ago>Of course the tradeoff is loss of scrollback. That could always be buffered on the server side.
- joombaga 9y agoIf you use a terminal multiplexer (screen or tmux) it effectively is.
- geofft 9y agoYou won't get native scrollback with server-side buffering. Precisely because it's scrollback that's off the screen, there's no way to send ANSI escape sequences to edit it after the fact; it has to actually be written to the screen and then scrolled off. So you can't really do anything where you transmit the current screen at higher priority and scrollback at lower priority. (Unless you want to do something where mosh will write out scrollback when it receives it and then write the actual current screen below it, but I bet that will cause a ton of flicker.) You can probably do some things to heuristically improve scrollback, e.g., telling the terminal sync thing to sync 1000 lines of scrollback if the connection seems good and only the current screen if it seems poor. You won't get reliable scrollback but maybe it's good enough.
- tptacek 9y agoVirtually nothing uses TCP URG anymore; it is for all intents and purposes obsolete.
- knz42 9y agoCan you outline briefly what the benefit of this is compared to mosh?
- wwarren 9y agoNot OP, but the page says > Mosh is a popular alternative to ET. While mosh provides the same core funtionality as ET, it does not support native scrolling nor tmux control mode (tmux -CC).
- Matt3o12_ 9y agoAccording to their website (the third bullet point): > mosh: Mosh is a popular alternative to ET. While mosh provides the same core funtionality as ET, it does not support native scrolling nor tmux control mode (tmux -CC).
- deleted 9y ago[deleted]
- ovi256 9y ago>While mosh provides the same core functionality as ET, it does not support native scrolling nor tmux control mode (tmux -CC).
- nopcode 9y agoIts also Apache 2.0 licensed, compared to the GPL3 that strangles Mosh. Pity its not a freer license though.
- lathiat 9y agoHow does GPLv3 strangle mosh?
- falcolas 9y agoHow does a GPL license "strangle" a network connection tool? Are you really bothered that you can't incorporate it into your own BSD/closed source project, or is it a purely ideological "it's not BSD, so it doesn't respect me as a developer" stance?
- deleted 9y ago[deleted]
- nitrix 9y agoHow robust is this to man-in-the-middle attacks?
- falsedan 9y agoSince it uses SSH to transport the initial session password, as robustly as SSH is.
- nitrix 9y agoThe 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.
- deleted 9y ago[deleted]
- notacoward 9y agoThat was my concern too. So ssh is used for the initial handshake? BFHD. A lot of the interesting stuff happens afterward. The "how it works" page explicitly says this: > ET does not implement any of the SSH protocol That implies they rolled their own wire protocol. Maybe they did a good job (like mosh appears to have done). More likely not. I'd be OK using this on an internal network or over a VPN, but relying on it alone for security would be premature.
- aroch 9y agoI think that sentence implies they're using OpenSSH not that they're rolling their own? --Edit-- A quick glance at the repo suggests they're using NaCl to handle the encryption + the SSH server for auth
- notacoward 9y agoWell, NaCl is certainly an improvement over a completely NIH approach, but doesn't necessarily provide features like forward secrecy. It would certainly be nice if the ET authors would explain in their "how it works" page how they've solved problems like these. Forward secrecy over resumable channels is not a trivial problem for which the quality of solutions should be assumed.
- fiatjaf 9y agoSo it is mosh, but much better? I'll try it.
- fiatjaf 9y agoThe PPA doesn't work. The compilation instructions fail.
- JosephRedfern 9y agoCompilation works for me: https://asciinema.org/a/LkPYDdWkGgFybny8ChqOLQA8e https://asciinema.org/a/LkPYDdWkGgFybny8ChqOLQA8e What problems are you encountering? It might be worth opening a GitHub issue.
- fiatjaf 9y agoIt is not clear from the error that you were missing libsodium. I don't remember what was my error anyway, I'll try again later. But I can't even find libsodium on my apt.
- JosephRedfern 9y agoAgreed, it wasn't terribly clear. I essentially just guessed based on the mention of "sodium_LIBRARY_RELEASE". What OS are you running?
- Digitalghost 9y agoHey, please file an issue on github: https://github.com/MisterTea/EternalTCP/issues 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.
- jitl 9y agoTo 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 Mosh and ET is that neither expose a data communication channel along side the PTY. I use SSH for port forwarding, Tmux paste buffer sync, file transfer, and SSH agent forwarding. Without those features, I'll always need to use SSH/Autossh along side these tools for my other SSH use cases.
- falcolas 9y agoFWIW, 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 the value of tools such as these. I do have one question, given the tmux and scrolling support, how much mosh-like lag compensation can ET provide?
- xianwen 9y agoI'm curious. What's the ssh options for managing the resumption of sessions?
- falcolas 9y agoIt 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'.
- dalore 9y agoAll 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.
- falcolas 9y agoNo, 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.
- skrowl 9y agoWhy does it need it's own port if it rides over SSH? Couldn't SSH just forward a port?
- zie 9y agoIt could, but then it would have to deal with the SSH line protocol which is complicated, because it allows for a LOT of stuff. ET is basically pretty dumb, it basically just dumps a PTY onto the network, and is way simpler.
- geofft 9y agoI feel like 99% of what I get from mosh is good performance over mobile networks, not IP roaming per se. In particular, TCP's congestion control algorithm is intended for networks that get congested, i.e., low-bandwidth shared-media physical networks where a dropped packet is a sign that you should lower your transmission rate. That's approximately zero of the networks I use; when my packets get dropped, it's usually because I'm in a train and tethered to my phone which went briefly out of range of cell service, or because someone turned on the microwave, or because I'm being handed off between wifi or cell towers, or whatever. So constantly reconnecting over TCP (especially if there's a significant application-layer handshake for the reconnection) doesn't seem like it solves the problems I have. mosh uses a custom, non-TCP reliable transport layer that is actually built for mobile networks. Both scrollback and tmux -CC support are feasible in theory with mosh, though difficult to get right: https://news.ycombinator.com/item?id=14228591#14229268 https://news.ycombinator.com/item?id=14228591#14229268 https://www.mail-archive.com/mosh-devel@mit.edu/msg00304.html https://www.mail-archive.com/mosh-devel@mit.edu/msg00304.htm... There's a fork of mosh linked in the first comment that switches the terminal-to-user end from a synchronized terminal screen to a bytestream (same as the user-to-terminal direction, i.e., keyboard input). It's not going to be robust to, say, catting a huge file and needing to Ctrl-C, but it should maintain mosh's robustness to radio (wifi/cell) network blips. It was designed for scrollback, but I'd sort of expect it to make tmux -CC work too. Anyway, it is super cool to see more efforts in this space, and I bet for people who work primarily at desks with reliable internet connections, this is a huge improvement over, say, autossh. But for my own use case for mosh, this doesn't seem like it's got feature-parity yet. Maybe there are clever things you can do with aggressively restarting TCP connections that get you the same experience as mosh's UDP approach.
- Gaelan 9y agoIIRC, Terminal.app sends a key code when the user scrolls in mosh (or any program that takes over the screen). Maybe it would be possible to handle that and display the scroll back buffer?
- geofft 9y agoOh, yes, if there's a way to signal a scroll attempt to the application then it's totally doable. Is this the "Scroll alternate screen" checkbox? I believe that just controls the scroll wheel, and makes it not do native scrolling and instead just send a page-up or something. If so, then non-native scrolling is definitely possible ... but it's already possible if you run screen or tmux instead of mosh. (Which is what I do, and it works fine for me, in part because I learned how to use screen's scrollback even before mosh existed.) I can see the argument for exposing this with better keyboard shortcuts than screen's inscrutable ones, but my impression is that people mostly want native scrolling so they can, e.g., drag in the terminal UI to copy and paste a large amount of text. You can't do that with non-native scrollback, since the text isn't all contiguous in the terminal window.
- technofiend 9y agoIt's in a different category but there's also Apache Guacamole... typically you'd host your web proxy+container where ever your servers are, so the buffering and scrolling happens on the remote side and is rendered to your browser. No idea what happens if you try to ^C out of a 100MB cat halfway through.
- h1rschnas3 9y agoDoes it support ssh agent forwarding? The most important missing feature in mosh imho.
- majkinetor 9y agokitty (fork of putty) does the reconnect thing on Windows, among many other things: cinst kitty
- Lazy_Killer 9y agoWhat about tmux/screen?
- Digitalghost 9y agoYou can run tmux/screen inside a ET session
- mbonzo 9y agoHi, I made a quick video showing ET in action and what it is: https://www.youtube.com/watch?v=_tzQhL-usbc https://www.youtube.com/watch?v=_tzQhL-usbc
- amingilani 9y agoLooked for a video on the site, couldn't find it. Found this in the comments. Thank you!
- mbonzo 9y agoDid the link work for you? I just updated the link because it was somewhat broken! It works now though :) NP!
- bedros 9y agoAnyone used this behind corporate firewall
- Digitalghost 9y agoYep, it's just like ssh so as long as you can make a TCP connection to the server you can use it from behind a firewall.
- pmarreck 9y agoCan anyone who's tried both this and mosh, comment on them both?