mobile-shell / mosh Goto Github PK
View Code? Open in Web Editor NEWMobile Shell
Home Page: https://mosh.org
License: GNU General Public License v3.0
Mobile Shell
Home Page: https://mosh.org
License: GNU General Public License v3.0
Currently these are scored as CorrectNoCredit
It builds fine on OS X with just five packages installed:
autoconf automake boost pkg-config protobuf
Should be pretty easy to make the homebrew recipe.
Currently when idle, the blue bar appears briefly after we've lost just one datagram. (Since timeout is 5 seconds and we send heartbeat every 3 seconds.)
I'm not sure exactly what's going on, but I use ControlMaster to avoid establishing multiple connections to a server. If I have an open ssh connection to a server (and therefore an active ControlMaster socket), starting mosh fails:
evan@warwick:~$ ssh -N [email protected]
evan@warwick:~$ ls .ssh
authorized_keys id_dsa known_hosts
authorized_keys2 id_dsa.pub known_hosts.old
config id_rsa
[email protected]:22 id_rsa.pub
evan@warwick:~$ mosh [email protected]
/usr/bin/mosh: Did not find mosh server startup message.
The relevant portion of .ssh/config is:
Host *
ControlPath ~/.ssh/control-%r@%h:%p
ControlMaster auto
ControlPersist 1
In theory, we could easily support X forwarding (with roaming!) by just conveying a verbatim octet stream in both directions over the underlying network layer -- the same kind of statesync object that we use for user input.
We wouldn't get predictive local UI, but we would get the other benefits of Mosh (support for sleep/wakeup and IP roaming).
Allow degenerate use of TCP and HTTP CONNECT modes for people who can't use UDP.
When the remote application uses smcup to enter the alternate screen, the client should put the real terminal in alternate screen mode too, so that for example the mouse wheel lets you scroll in less and emacs and barnowl.
For people with UDP firewalled, allow explicit request for particular server-side UDP port.
Because 256 colors ought to be enough for anybody.
Right now adaptive prediction showing (default mode) will shut off the adaptive display even when predictions are outstanding and displayed, leading to flicker.
We should keep the predictions on until the prediction engine is not active.
mosh
uses ssh
to run mosh-server
on a remote host. From where does that mosh-server
process get its environment variables, in particular LANG
and friends?
Debian, Ubuntu, Red Hat, and some other Linux distros send these variables over SSH, with
SendEnv LANG LC_*
in /etc/ssh/ssh_config
, and a corresponding AcceptEnv
in sshd_config
. This works fine and does what we want. However it isn't the default for vanilla OpenSSH, and it needs to be configured at both ends. This means that (for example) a Gentoo machine will not cleanly accept Mosh connections. We say that using Mosh does not require root on either end, so reconfiguring sshd
is not an option in general.
Some users set LANG
in ~/.bash_profile
or similar. We could launch mosh-server
through a shell (perhaps a login shell) and trust that LANG
will appear somehow. Cons: we have to deal with everyone's wacky shells and configurations.
Alternatively, mosh-server
could ignore LANG
and instead take the name of a locale as a command-line parameter. The wrapper script would fill this in from the client's environment. This assumes that the desired locale names are the same on both ends of the connection. This is an assumption already made by the SendEnv
mechanism, but under the status quo it isn't our problem.
Mosh uses only a few locale features: UTF-8 encoding/decoding and querying basic properties of Unicode characters. We could replace this with a dedicated library such as ICU. This would also help with porting to platforms where wchar_t
can't represent all of Unicode, such as Windows or Android.
At that point we can take a more hands-off approach to locale issues. Whatever the user typically does to make their applications output UTF-8, they should keep doing it with Mosh. If they rely on SSH SendEnv
then we will keep honoring that. If their applications are all children of shells and they set LANG
in a login script, that's fine too. If they only use one app and it's hardcoded to UTF-8, we don't care.
Of course if those applications don't output UTF-8, Mosh will break, as now. In particular, terminal escape sequences can start with U+009B
'CONTROL SEQUENCE INTRODUCER'. If we get this character in an ISO 8859 encoding, it will wreck the terminal, even if all visible text is ASCII. But we can probably hack around this, if absolutely necessary, because no valid UTF-8 sequence starts with 0x9B
.
Some error messages from the initial ssh connection appear after the password prompt is reprinted. For example, when inputting an incorrect password:
aroach@champignon:~$ mosh champignon
aroach@champignon's password:
aroach@champignon's password: Permission denied, please try again.
Some sites already use SSH ProxyCommand or disable it for some reason. The mosh script should give a distinct error message in that case.
mosh needs a man page
Currently the mosh client hardcodes escape sequences for a vt220-ish outer terminal supporting BCE and xterm’s window title. It should use terminfo for portability to different outer terminals.
This could be done by making the client a full-blown ncurses application, or by reading the terminfo entries directly with tigetstr/tiparm/etc. (which still requires ncurses).
When logged in remotely with mosh to a Macintosh, OS X seems to go to sleep (and we start getting the "Last contact" countup). It doesn't even respond to pings.
SSHing to the machine seems to wake it up.
It looks like this is a feature -- "pmset -g" shows a sleep time of "10" when not logged in with SSH, and a sleep of "0" (disabled) when logged in with SSH. (I think "ttyskeepawake" is what makes SSH inhibit sleeping.)
Is it possible to have mosh-server also set the sleep time to be 0 when there is a user logged in? Unfortunately pmset requires root... Starting a screen did update utmp but didn't disable "sleep".
The mosh-server child (host) will die if the server detaches before it forks off a shell. Solution is probably to detach before forking the client, but this requires rejiggering.
If the memory page holding Mosh's session key is swapped to disk, a copy of that key could persist indefinitely. Here's an attack scenario where this matters.
mosh-client
is swapped out to disk.Using POSIX mlock
, we can prevent this data from being swapped out. But there are some reasons why we might not bother.
mlock
does nothing to protect suspended data.Having established that the benefits of mlock
are real but limited, what are the drawbacks?
mlock
is available on Linux and OS X, it is not required on every POSIX platform, as it's part of the Realtime Extension.RLIMIT_MEMLOCK
. This wil be (mis)configured to 0 on some systems, breaking Mosh.From a cursory search, neither OpenSSH nor OpenSSL prevents swapping of cryptographic materials (which is surprising, because unlike Mosh they also handle persistent keys). By contrast, GnuPG includes a custom secure allocator with knowledge of many Unixes.
Perhaps the right solution is to call mlock
if it is available, and treat failure as a non-fatal condition. But I'm still worried about increased code complexity, versus the limited enhancement to security. Maybe I should just write the code and see how complex it is.
Thoughts?
Requirement of g++ >= 4.6 is not realistic if we want to be in Ubuntu LTS or Debian.
If I press any keys while mosh is connecting, they get echoed back before the MOSH CONNECT string, confusing the wrapper script.
$ mosh linerva Hello, world!Hello, world!MOSH CONNECT 47266 TGj0sGDQij7qF6ZXFadwOA [mosh-server detached, pid=9169.] Connection to linerva.mit.edu closed. /usr/bin/mosh: Did not find mosh server startup message.
For until the package makes it to Debian stable...
Right now the trigger for underlining predictions is based on SRTT estimate only. We should add a "glitch" test (similar to the one for whether we show predictions in the first place) so long-outstanding predictions eventually get flagged to the user.
The recent change to include a "late ack" showing which client->server keystroke would definitely have been echoed has improved the rate of spurious mispredictions, but we are only sending these opportunistically when they can piggyback. That means the client also needs a timeout trigger for when there are no more replies to piggyback on, and this timeout trigger has been firing spuriously for me, leading to partial eraser of stuff I had already typed. Also the "pending ack" is not acknowledged so if the packet carrying it is dropped, we run into trouble.
We need to convert this from a header field to a protobuf object that is inserted in the stream as pending data, just like a resize or screen delta. This should make the predictions much more robust.
Cons: If we always send the "late ack," we will increase the chattiness because almost every keystroke hit will now result in TWO packets returning from the server.
Add a --version option to client.
Have server print version after MOSH CONNECT.
Right now the client dies on SIGCONT.
We should have a SIGCONT handler that (1) sets repaint_requested and (2) replays the Terminal::Emulator::close() and Terminal::Emulator::open() strings to reset the outer terminal state (in particular the application-mode cursor keys).
This will also be useful for the Android port if we want mosh to keep a connection over the client's being killed and restored.
Allow reconnection to existing sessions that were somehow severed. Give command to clean up disconnected sessions.
We want to be able to connect to a server behind a NAT, even after the client roams.
We could use techniques like http://samy.pl/pwnat/ (per Nelson Elhage), except we'd need to keep doing them to pick up any client IP address changes.
Should we add timing fuzz and bogus packets to foil passive statistical eavesdropping? (We do add chaff to the datagrams we're already sending, but is this enough?)
Can we relax the build dependency on debhelper >= 8?
Can we get rid of dh_autoreconf by putting an explicit rule in debian/rules?
mosh
could provide a way to pass options to the ssh
invocation used for connection setup. For example, the user might want to SSH to a port other than 22.
One can already customize the SSH connection using Host
directives in ~/.ssh/config
. Perhaps this is good enough, in which case we could suggest it in documentation.
We are too timid on packet loss and sometimes wait up to 3 seconds to resend.
Some users do not want to have to compile mosh to be able to install on OS X.
Sites using Kerberos and AFS need special care to preserve the user's Kerberos tickets and AFS tokens. Typically these are destroyed when SSH logs out -- which is a problem for us, since SSH logs out immediately before we even start the Mosh session proper.
One approach is to write a mosh-kerberos-server script that manually copies the Kerberos ticket file (and AFS tokens?) to a new location before detaching from the terminal and letting SSH reap the old ones.
Hardcoded CSI ! p (DECSTR) isn't working well enough.
The mosh-server should quit gracefully if there has been no connection established after 60 seconds. This will lead to fewer mosh-servers lingering around.
In terminaldisplay.cc
Mac Terminal.app often repaints the screen immediately on scroll, even if there is more input pending. This makes mosh's scrolling optimization sometimes produce intermediate flashes.
We should explore using the scroll-region feature of the outer terminal to do a more graceful scrolling optimization on a partial scroll. Will need to verify that this fixes the flashing problem on Mac.
It would be wonderful to have persistent remote-terminal sessions from an Android device. Theoretically the Mosh code should be compilable on Android and should be runnable from an existing GUI terminal emulator without needing to jailbreak.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.