Hey, never, but never, go out of an elevator that isn't leveled in the floor. By the description, I understand that he jumped from the elevator. If the elevator started to move, he could have been cut in half. This happened other day in my city.
If you are stuck in a elevator, wait for professional help to take you out.
And watch this[0] entire (super entertaining) talk from Hope X about elevator security. You get a pretty good feal for how the safety measures work after watching it.
I once dreamt I was cut in half by a lift. It was not at all fun, so I'd definitely follow this advice :-D
The other piece of lift related advice (that I really enjoy saying in more crowded, rickety lifts): I once read if in a lift that is falling you should attempt to lie flat on the bottom of the lift to limit the impact - preferably on top of another human. Some hacker news physicist will prove me apocryphal here I'm sure...
If an elevator is falling for long enough to give you time to recognize the situation, recall this strategy, and actually lie prone upon the floor (in ~0G, somehow)… it's not going to matter.
Seconding this: I like to put hacker con talks on in the background while I do other things, and this was the most entertaining panel from HOPE X in my opinion
There's a video of security footage from some elevator in South America (Argentina I think) in a brand new building. The elevator brakes failed and it launched upward (from the counter weight). Dude survived with major injuries. Others have said he should have laid down flat, but at that velocity who knows if it would have done any good.
There's a horrible video I don't feel like looking up at work of a dude in an elevator that's acting all erratically. A guy with a baby stroller is about to get in. The guy tells the guy not to; the elevator hasn't been behaving correctly (there's no audio/security video. Guy tells the police this later). Guy in the elevator looks terrified.
The man with the stroller steps in and the elevator cuts him in half. There's a trail of blood on the wall where the man use to be. It turns out the maintenance guy forgot to put out barriers saying the elevator was under repair. He was moving it from above and didn't realize people were getting in.
There's not enough detail in the link. You can force the doors of an elevator to open it. Sometimes there's just a small hole to go through. The elevator had problems and was moving arbitrary. Sure, if it is just 5cm off, go for it, but don't think you are inside a movie and it is save to go out. In doubt, stay quiet.
I dont get the plot. He got text messages to his flatmate, but the one asking his flatmate to call the council never made it. So his flatmate is dumb enough to need explicit instructions to call for help when a friend says they are trapped? Or were the first few texts he sent "hey whats up?" and "doing anything later?"? Why have your flatmate call "the council" when the obvious ask, and the one requested via email, was to call the fire brigade?
I cannot remember for this building specifically, but I've noticed in others that the emergency instructions are indeed to call the council.
I was the flatmate. We never got a message through. I was busy on my own side courting a fine lady, and did not expect any sort of communication.
I learned of the story only the next day, when I went back to work.
The building in question is operated by the city council, which did great for low rent. I think many people, me included, would have thought of calling the council first, before the fire brigade, as the city keeps technicians round the clock (supposedly) to deal with such problems.
I'm rather pleased by the elegant use of this software for such a situation.
Termux[0], the best Android terminal emulator (in my humble opinion), recently had mosh added to its' package repository.
I currently use it and it's very nice. It makes me long for a better handheld though (my 4" Moto G screen is difficult to type on, even with Hacker's Keyboard).
I can have tmux sessions running on servers with say, an irc client running, mosh in, chat away for a bit, turn it off, the irc client continues running. Perfect. Same for e-mail using mutt, notes that are backed up on the server automatically using vim, etc etc. Really nice workflow.
Give me a handheld device with ssh/mosh support and I'm happy. :)
I'm running Termux on a Pixel C and I love it. With the keyboard and all it's the Linux experience i wan't on the go. Local compiling works real nice for Go applications and smaller C++ and C stuff. Or Node.JS, Python and whatnot.
It's also available from F-Droid, though i recently became aware, that somehow I only had the ARM version and not AArch64, so keep that in mind. And it also works flawlessly on N.
With Termux, you can ssh into your Android device over Wifi. If there is no Wifi available, you could use your Android device as a Wifi hotspot, connect to it and SSH (you could even use mosh, as others comment that it can be installed in Termux) into your device.
I do not know if you can SSH into your device if connected through bluetooth.
Termux is a bit of a different concept to JuiceSSH. Termux is just 100% terminal, you can install packages through apt in the command line, use standard Linux utils from your phone and on the local file system. It has no GUI.
Personally I like JuiceSSH because it has a nice simple UI for setting up and saving SSH connections. I like the extra buttons for things like ctrl/home/etc.
I'd definitely want something like Termux if I was using Android on a device with a keyboard, but for the sort of things I use a terminal/SSH for on my phone, I prefer something like JuiceSSH. Shame it's not open source though.
On topic, JuiceSSH also supports Mosh out of the box.
Another commentor expressed it, but JuiceSSH is proprietary. In most cases open source is more of a preference for me than a necessity, but I may need to sudo or access root over SSH, and there's no way to review closed source code. JuiceSSH (IMHO) has too much control over my computer for me to use it based on the assumption that I fully can trust the developer.
Agree. Really wish mosh support would be merged into standard ConnectBot. The linked build on the mosh site is hacked into an old version of an old ConnectBot fork.
I haven't tried JuiceSSH, I use CM and only have F-Droid installed (not play store). Most of the reason I use termux is to get away from proprietary apps (I can run all free software on a server and SSH into that).
Juicessh has implemented mosh but stops just a bit too soon.
it would be great if they could support suspending a mosh connection so that you can have a resumable connection without having to have the radio on all the time.
Know of anything similar which supports android gingerbread? I'm using JuiceSSH now but I would love something with package management features like this.
I've used mosh on and off for the past year. For me, the best feature of mosh is the support for roaming. For the "persistence" aspect, SSH + remote screen is sufficient.
There was a point where I used mosh whether I was roaming or sitting at my desk, but eventually the friction of mosh made it only worthwhile to use in roaming situations. By "friction" I mean the small annoyances of (1) installing mosh on every new server, and (2) requiring the use of screen to get scrollback buffers. I frequently use screen in my workflows outside of mosh, so I would often end up in weird states where I moshed into a server and auto-attached to my dedicated "moshscreen," but then had to detach from it within the session to move to another screen that I wanted to use.
Because of those annoyances, I now just use simple SSH when sitting at my desk, and put any long-running commands into a remote screen. But mosh is still extremely useful in two narrow cases: train rides (moving between cell towers) and traveling in developing countries (high packet loss).
I've had great success with using JuiceSSH[0] for mosh on Android. Great for those times something important comes up and I'm away from my desk. Trying to connect without mosh on mobile networks is pretty terrible.
You do have to install a patched version for mosh support, but for some reason I could never get JuiceSSH to connect to our mosh server so I've been using "mosh for irssi ConnectBot" from http://dan.drown.org/android/mosh/ for years.
Love mosh, but having no scrollback is a pain. I can hack a solution by using screen on top of mosh. They say that version 1.3 will add support for scrollback.
Also, you don't need root privileges to install it on the server side. You can just install it into your home directory, and run the client with --server=/home/you/bin/mosh-server. (It uses SSH for connection setup, and then communicates over UDP on a high-numbered port, so it doesn't need any privileged code.)
This beautiful little tool was what let me do contract work over a (frequently >10s roundtrip with >50% packet loss) 1-2kbps mobile uplink in rural West Africa. It's indispensable in such situations.
I have been an extremely happy Mosh user for a while now. The feature I am missing the most is port forwarding. I looked into adding it myself at some point, but it wasn't entirely trivial because of how Mosh bundles together network-related concepts and higher-level stuff like optimistic typing. There is even a small bounty on it, I think :) https://github.com/mobile-shell/mosh/issues/337
Mosh is great, but I kind of stopped using it once I discovered Tmux so I could resume a session if the connection dropped.
It's not that Mosh does anything wrong, but SSH has more features, and is supported by basically everything ever. Consequently, I stick with old-school SSH.
tmux complements mosh, it doesn't quite replace it. For me, the whole point is that you don't have to "resume a session", it just happens.
On my laptop I have a mosh session open to my remote shell basically all the time. In situations with spotty net access, it's actually a pretty reliable "canary" that indicates whether I have any access at all.
I occasionally use it when I have spotty internet connection, since it allows me to type commands or edit files with no latency. I still rely on tmux/screen for cases when I need to re-connect to a dropped connection.
well, i've been using mosh for two(?) years and it's not perfect.
>lost sessions cannot always be resumed, not even root can force that.
>you can't scroll the terminal unless you use screen inside mosh
>can't use mosh from the university network because UDP ports are filtered
>can't autocomplete hosts in the config (ssh can do that)
but i still use it and would miss it very much, the whole experience is much smoother using mosh and bad connections are more bearable with it
can't autocomplete hosts in the config (ssh can do that)
If you mean writing "ssh <tab>" and having it auto-complete, that's a feature of the shell (usually with some "plugin" to add support for that particular command). They added support for Bash in 2012 [1], what OS and shell are you using?
I wish I had your problems, I've been waiting more than 5 years since my ISP first promised they are working on implementing IPv6 and so far I am still stuck with ~10mbit/s ADSL using IPv4 only.
I use mosh to connect to my workstation, which only has an IPv6 address as far as public connectivity goes.
Several friends of mine are in a similar situation, so at least in my bubble, getting easy access to computers running at home is a major use-case for IPv6 :).
I'll chime in and say: Support for IPv6. It's ... self evident? I think we've reached a point that it's okay to call out a network client that doesn't support it.
I am not sure I understand. How is it self-evident? Is there a benefit over using mosh over IPv4? Performance, stability,anything else? Does it add anything to what mosh can do over IPv4. Is the benefit from the client end or the server end or in-between.
I never realised people used mosh for persistence. I always use tmux (with my zshrc set up to automatically drop me into a default session) and use mosh so that I can write full commands while operating over a lossy connection. I would use mosh over Tor, but Tor doesn't route UDP. :(
I use mosh daily and love it. It's great for moving around the office and maintaining a connection - no accidental hups, no real need to use screen or nohup.
My one beef with it is that it effectively defeats my terminal emulator's scroll bar. Need to scroll back the output? Nope. You have to use less or more profusely.
Is mosh on top of screen or is screen on top of mosh? Serious question, since I share parent's love of mosh and frustration with the lack of scrollback.
Mosh to the server, then run screen/tmux there. You'll have to use the scroll features of screen/tmux. Running your stuff inside of screen/tmux is useful in any case.
We are currently in a very advanced state, shooting for Beta soon. Follow us on @blinkshell https://twitter.com/BlinkShell if you would like to have early access!
SSHing my servers with my iPhone over LTE with Prompt w/o Mosh.
Same low latency as on desktop over WiFi, perfectly fine, light code editing in Vim is butter smooth. And if connection breaks I just get back to my tmux session. So, can anybody tell what I miss?
Speed and responsiveness. Mosh renders on the server sending only changes, so a Ctrl+C or a dump like dmesg is crazy fast. Prediction makes a server in a different country behave as if you were there. Also, although you mentioned the connection breaking, this happens in iOS a lot and ends up being a pain, having to tap the server again and again.
With Blink, which is Mosh for iOS (I'm the developer @BlinkShell https://twitter.com/BlinkShell), you also get full keyboard support, with Caps as Ctrl, Alt as Meta, or any other combo you want to have. And a great terminal with full configuration of color themes, fonts, etc. beyond the standard included with the app. Everything a real terminal should have.
This is funny, mosh saved my day a few days ago to reliably access a workstation connected through Comcast Business from an ATT Uverse home connection... For some reason the SSH sessions break (timeout) every 2-3min. I tried everything, but after a random time between 2 and 4min packets for those sessions just disappear, despite ssh sessions between other networks being perfectly fine.
Anyway mosh works like a charm now. I think it is where it shines: seamless access over high latency and/or unreliable networks.
I have mostly gone back to plain ssh. mosh was fantastic for keeping a connection running across network changes and when accessing a plain command line it does feel a bit snappier on slow connections.
But screen or tmux give me persistence and re-establishing an ssh connection isn't very time consuming. A terminal multiplexer has a lot of advantages that mosh does not provide.
mosh adds another layer of terminal emulation and while the extra latency might not be a killer the terminal emulation can be as it is opaque to some features.
It is practically necessary with mosh to run tmux/screen anyway because mosh removes scrollback. I find mosh adds little benefit for me most days and it makes a few things worse.
mosh is a great idea and sometimes useful when you are changing connections or opening and closing a laptop all day but most days I think I am better off without it.
Also I rarely have a remote connection open without forwarding some ports about so mosh often doesn't do what I need anyway.
Unfortunately every layer of terminal emulation tends to filter out some terminal capabilities. It is a small thing but I like to be able to yank a selection out of a remote vim and paste it locally and last I saw mosh's terminal emulation eats the necessary control codes.
That's what I do. My laptop moshes into a tmux. It's like I'm just always connected to my servers; the network is abstracted away. Mosh even has a very useful "7 seconds since connection dropped" message for when the café WiFi lags etc.
I tried to use mosh, but it turned on really bad mobile network even it was not helpful. What surprisingly worked OK was Emacs shell plus lsyncd. With that I type commands locally and send the whole line on Enter while lsync transparently syncs my edits of local files to the server. Then I can live with latencies of over a second.
For anyone else that was curious, zerotier appears to be a virtual network tool, kind of like Hamachi but not run by a terrible company and with a much saner pricing scale.
It's actually free for unlimited use if you run your own network controller, see docs in /controller and /service on GitHub. There's now a 100 device free limit on my.zerotier.com which is just our hosted SaaS network controller.
actually the site/documentation hasn't been updated but it's now free for 100 devices (with a price increase beyond).
from an email earlier this week:
"For new subscribers we've increased the price to $29.00/month (USD), but we've also increased the maximum number of devices for free accounts to 100.
We think this better reflects the difference between personal and business users, providing plenty of devices in our free version and charging enough for our business customers to justify adding new features and services and to support the continued development of the entire ZeroTier ecosystem."
Few HN posts propel me to even slightly alter my day to day workflow. Using Mosh instead of raw SSH is a huge win for me because much of my day is spent remoting into a server in Singapore from the US over Verizon 4G cellular data.
Sadly, there's no indication of a proper protocol specification for the State Synchronization Protocol having been published in the four years since the authors suggested that SSP might be usable outwith just mosh.
The low latency features really set this one apart. The smart local echo (it underlines unconfirmed predictions) make it much nicer to use over laggy mobile networks.
That sounds like a scenario for long-form work over a mobile network (eg. on a laptop through a mobile hotspot).
Mosh from a laptop is a no-go for me because there's no Windows-based, full-featured terminal emulator (saved sessions, auth agents, etc) that supports mosh.
I can second the suggestion of MobaXterm. I am using it quite a bit, and their support has been fairly responsive to questions. Not open source, but still seems like a good product.
The connection is set up over SSH, and mosh-client generates a random AES-OCB key and sends it to mosh-server. Packets are sent over UDP, protected using authenticated encryption, and discarded if they fail integrity protection (which is fine, since packets could just be dropped and perhaps corrupted anyway because of bad network connections). Replayed packets are invalid. At that point the client's IP address no longer matters, since it's the only entity with the key. The server accepts valid packets from anywhere, and also sends packets to the IP address that most recently sent it a valid packet.
This should as much protection as an SSH connection over TCP. One thing I'd worry about is whether the server or client can be DoS'd with invalid packets. Is there anything else that seems concerning?
I guess I was thinking about something involving a principle similar to session fixation, but it was just a passing thought. Your methodologies seem sound.
Yeah, I think in order for session fixation to work, you have to have multiple connections trying to use the same session, and trick one of them into reattaching to the wrong session. For HTTP + cookies, that's doable. But the only concept of a "connection" in mosh is this key shared between client and server and only stored in RAM, and there's exactly one session per server process, and one client per server. A new connection is a new session (you have to use screen or something if you want to connect to an old terminal).
There are occasional requests for the ability to write out the client key and cryptographic state to disk, so you can reboot your machine, kill and restart a process on Android, etc. without losing your connection. But they've been pushing back because it breaks this straightforwardness.
If my client session dies (laptop kernel panics or runs out of battery) then mosh will notify me on the next login that "there are sessions running with these PIDs"
I've tried to reattach sessions to no avail, mosh was designed this way. I have to just kill the sessions.
There's no way to know if a machine you can't contact is on the other side of a network partition or if it has died/disconnected/given up. You could have the client try to persist its state across local reboots, at least to the extent necessary to kill the session (in case the latest crypto state needed to resume couldn't be saved before the system died), in which case you would have to kill fewer sessions.
I think caution is good, but I am not sure "Don't use it" is a fair assessment for all use cases given Mosh's technology and track record over the years. Of course SSH is more battle tested but, Mosh has a FAQ entry just for this concern:
"In one concrete respect, the Mosh protocol is more secure than SSH's: SSH relies on unauthenticated TCP to carry the contents of the secure stream. That means that an attacker can end an SSH connection with a single phony "RST" segment. By contrast, Mosh applies its security at a different layer (authenticating every datagram), so an attacker cannot end a Mosh session unless the attacker can continuously prevent packets from reaching the other side. A transient attacker can cause only a transient user-visible outage; once the attacker goes away, Mosh will resume the session."
"However, in typical usage, Mosh relies on SSH to exchange keys at the beginning of a session, so Mosh will inherit the weaknesses of SSH—at least insofar as they affect the brief SSH session that is used to set up a long-running Mosh session."
Mosh requires OpenSSH to run so no matter what, using Mosh is ALWAYS less safe than OpenSSH alone since all it does is add functionality on top.
Now, I wrote a 3DES-telnet tool back in 1996 and it has zero security vulnerability. That's 20 years. Safe as hell! Yeah exactly. Everyone uses OpenSSH. Very few use Mosh. Invalid comparison.
> Mosh requires OpenSSH to run so no matter what, using Mosh is ALWAYS less safe than OpenSSH alone since all it does is add functionality on top.
Not sure I'd agree with this, since after initial session establishment, it completely replaces the functionality of OpenSSH in a way that guards against privilege escalation and authenticates every packet.
I do agree that there are some concerns with how 'battle tested' it is, but not sure I believe this about "audits" since, I mean, the entire world was using OpenSSL to build the entire internet for ages and we just found out it was one guy scraping through the bug tracker for far too long.
The model of mosh is more secure than SSH, though its' session resumption could potentially expose a hole if someone has your token and session keys, they can resume your session.
I think "Not wanting to use SSH agent forwarding" is the answer. I don't want every single machine I use to be able to authenticate as me to anyone else. If I actually want to be able to connect to a third machine, I'll have an SSH key on the second machine. For instance, my phone has an SSH key to SSH/mosh to my VPS, and my VPS has a different SSH key that can authenticate to GitHub. If I suspect my VPS got compromised, I can kill its key on GitHub without having to worry about whether my single, master, local key got compromised. Given that ssh-keygen is so easy and basically every server I want to talk to supports multiple authorized_keys, I haven't seen much use for agent forwarding.
Also, mosh was developed at MIT, where there's a good Kerberos setup for most SSH-able machines. So if you really want forwarding, you can forward your Kerberos ticket with the initial SSH connection. The mosh-server command on Athena is actually a wrapper script that copies your Kerberos ticket (so it's not destroyed when the SSH session exits) and sets up a Kerberos + AFS session for the actual mosh-server to run inside:
There's little use for key-based authentication on Athena, let alone agent forwarding, because if you don't forward Kerberos tickets, you don't have access to your network home directory.
> I don't want every single machine I use to be able to authenticate as me to anyone else.
There is the `-c` option to `ssh-add` for that reason:
-c Indicates that added identities should be subject to confirmation
before being used for authentication. Confirmation is performed
by ssh-askpass(1). Successful confirmation is signaled by a zero
exit status from ssh-askpass(1), rather than text entered into
the requester.
Security by policy is worse than security by design. Mosh doesn't have code that implements agent forwarding, so there's no bugs in the policy code I have to be worried about.
>SSH waits for the server's reply before showing you your own typing. That can make for a lousy user interface. Mosh is different: it gives an instant response to typing, deleting, and line editing.
This seems asinine. If latency is an issue I want to know it, not be fooled into thinking my input is being interpreted correctly by 'predictions'. Does this mean when I hit 'jjjjjll' in vim, I'm going to see this underlined on-screen in mosh in high-latency situations?
If that's what you want, then don't use predictive echoing (or w/e it's called exactly).
I've been using Mosh for years on spotty connections and this feature alone is an absolute game changer. Sure, when you're trying to `jjjj` and your network hiccups, it may look weird for a moment, but no more weird than not seeing any input imo. And when you're not `jjj`ing, but instead typing in edit mode, you don't notice anything, it's flawless.
Also, Mosh shows a blue banner on top if there is prolonged connectivity issues, so it's not like it is tricking you or anything. The feature merely smooths out the UX, and it does so amazingly well.
Only if your recent keystrokes have been getting echoed, and if you haven't done something that might disrupt echo.
> Predictions are done in epochs: when the user does something that might alter the echo behavior — like hit ESC or carriage return or an up- or down-arrow — Mosh goes back into making background predictions until a prediction from the new batch can be confirmed as correct.
Yeah, this offends me - I want my terminal to have simple, predictable behavior, not be trying to reason about what the shell process is up to. If it has some predictive model, I have to worry about my predictive model (expectation of what happens when I hit a key) being in conflict.
You really don't have to worry about that, imo. The predictive feature doesn't overlap connectivity issues long enough for you to ever wonder "Am i connected or not"?
Not to mention, it shows you in two ways that you have connectivity issues.
1. All echoing prints underlines, so you always know if it's predictive output or not.
2. Any prolonged connectivity issue displays a blue bar at the top of the session, showing how long you've been disconnected for.
edit: And of course, you can simply turn off predictive echo if it's a feature you hate. but man oh man, is it something to love, imo.
As opposed to having your non-predictive model be in conflict, because your connection decided to space out for a minute so you don't see any results from any of your typing?
I thought that too when I first heard of mosh. But mosh is actually clever about it and it doesn't try to guess what would happen in vim. It usually only does predictions for prompts. In addition, the predictions are very obviously predictions (they're underlined). It's a very useful feature if you're trying to modify a complicated pipeline over a lossy network.
Um, wow! https://mosh.mit.edu/elevator.txt