rpwoodbu / mosh-chrome Goto Github PK

Entering or pasting Unicode does not function.

Right now, you only get once chance to enter your password/passphrase. Make it repeat the question once or twice.

Since last update on dev channel cursor position is wrong. Problem first reported on Secure Shell, but mosh-chrome also is affected as it is also using hterm

Copy/paste first message from https://code.google.com/p/chromium/issues/detail?id=386414

What steps will reproduce the problem?

1. login
2. vi
3. :q

What is the expected output? What do you see instead?

• The cursor indicator rectangle is gone after back from vi.
• doing some command, the cursor may appear at a wrong place, or hidden

Problem is fixed in a new release of hterm/secure shell. See https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/chromium-hterm/NY9TSfEjfGA

Just like with ssh::KeyboardInteractive::Answer(), use a const char * to accept sensitive data (i.e. the password), so that the lifecycle can be more easily managed.

I've been trying to track down what the issue is and i think i have it.

When connected to a screened irssi session.
There are times when i try to change windows to see a different channel. the input is taken but the mosh terminal does not do any visual update so i cannot see the channel.

I think the cause is when a large string has been posted in the channel and it is causing issue with the word wrap. I have tested on secureshell and the problem isn't there

It looks to be possible to add context menu items to the launcher icon for the app:

http://developer.chrome.com/extensions/contextMenus.html#method-create

Currently, due to behaviors on Chrome OS, the "New Session" window (mosh_client.html) is left open, and if the user closes it, he may never get it back. Other platforms will bring the window back when the user attempts to launch the app again (onLaunched() fires). But just because of Chrome OS, I'm leaving this "New Session" window open but minimized, which pollutes the workspace, and isn't a great UX.

By adding a context menu to the launcher icon, I could just close that window once the session is started, and let the user right-click the app icon to start a new session. This is similar to how the Secure Shell app works.

This may only show on Chrome OS, but that's OK, as that is the only platform AFAIK that needs this.

If I get a "Resolution fails" error, I don't get the option to hit "x" to exit. That's likely because the module is not exiting.

I didn't find anything in either this FAQ or the hterm one to disable it. I like having Option (alt) as meta, but how do I get it to leave my Command key alone?

This will likely require a major UI change (which needs to happen anyway, as it is currently hideous), but also some changes to the code to allow multiple "instances". Some work toward this has already been done with the GetPOSIX() call; it should be able to distinguish which instance to use by looking at the current thread ID.

The ssh connection timeout is currently 10 seconds. This is causing problems connecting to machines that are under heavy load or when the network is being laggy. Increase this timeout.

Probably need to fix issue #7 first, so that the long timeout doesn't cause grief when the connection fails for other reasons.

The scrollbar is noise. Mosh doesn't have a scrollback buffer. Maybe if this could communicate through to screen or tmux, that'd be neat. But for now, turn it off.

This may be controversial. Maintaining a web-like environment means not keeping any run-time state that would be lost if the browser is closed. This is especially important on Chrome OS, as signing out has no "are you sure", and any user can sign anyone out from the lock screen. Also, it stinks to lose your session because of a browser update, which is pretty frequent if you are on the Beta track.

Storing session state on durable storage is obviously a potential security risk, and should be opt-in with a big disclaimer. However, on Chrome OS, each user's local storage is separately encrypted, reducing the real risk to the point where many users may reasonably choose the convenience. On other platforms, security-conscious users may also have encrypted local storage, but it is up to those users to make that happen.

This requires support from the upstream Mosh code itself, so this is blocked on that.

From a bug report on the Chrome Web Store:

I'm trying to set the background-image property like this: mosh_client_.io.terminal_.prefs_.set('background-image', "url('http://.../image.jpg')") but end up getting: Refused to load the image 'http://.../image.jpg' because it violates the following Content Security Policy directive: "img-src 'self' data: chrome-extension-resource:". The same thing works just fine with the Secure Shell.

I'm guessing this is due to Packaged Apps being more restrictive. I should look into what permission I could add to manifest.json to make this work, if possible. After all, the app can already "exchange data with any computer", so it really wouldn't make the situation any less secure.

I'm trying to login to my server but it gives me a 'ssh authorization failed' on my password.
My server is using the yubi-PAM module for two-factor authentication, it might cause problems, although it only needs a password. Other ssh clients work fine, even the Chrome 'Secure Shell' which is using NaCL.

Since the only output is that it failed, it's pretty hard to pinpoint the problem.

Also, what should 'user' be? only 'user' ? or 'user'@'hostname' ?

Manual login works fine.

The white text abuts directly against the left/right edges of the window, resulting in an unpleasant juxtaposition of my text with the surrounding environment. Please add a pixel or two of padding. :)

Sometimes, ssh-ing into systems gives this error:

Bad response when running mosh-server: 'mosh-server needs a UTF-8 native locale to run.


Unfortunately, the local environment ([no charset variables]) specifies
the character set "US-ASCII",


The client-supplied environment ([no charset variables]) specifies
the character set "US-ASCII".


LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
'

This is repeatable on such servers by issuing this from the client:

$ ssh -t <server> mosh-server

But the "mosh" Perl script has no trouble.

Currently, an ssh connection failure is not communicated properly to libssh, which means that failed connections simply have to timeout within libssh (only 10 seconds, but still).

This is due to the fact that the socket is non-blocking, which requires getsockopt() to communicate the disposition of the connection, which has not been implemented.

See man connect and search for EINPROGRESS for details.

Typing/pasting characters like á, ä, å etc results in á, ä, and Ã¥ respectively. If I use Secure Shell, then mosh within Secure Shell, it works fine.

[alexis@fluffy ~]$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Repro: (for me, on Chromebook) go to the zoom settings and set the default web zoom to something other than 100%. I used 125% b/c the machine I'm on has tiny little pixels.

Open Mosh, see complaint. According to rginda, when the web zoom != 100%, hterm stops trapping ctrl +/- so that you can use those to fix it, however it seems that chrome doesn't look for those keystrokes on v2 apps.

I think this is in the Chromium bug tracker here: https://code.google.com/p/chromium/issues/detail?id=153568 but I'm filing this with the hope that someone has an idea for a workaround that could be integrated into mosh-chrome.

One easy way would be to add a button in the UI to add/replace the key, which would pop up a box to paste it into.

Also, consider supporting multiple keys, which is mostly a UI thing.

On my OS X Mavericks machine, connecting to a remote machine via Mosh extension (0.2.0.20, precompiled version from the Chrome App Store) produces corrupted output.

Attaching to tmux produces a blank screen, and curses-based apps fail to draw correctly on the screen. I initially thought it was my relatively fancy bash PS1 prompt, but setting PS1 to \u@\h \w \$ still produced issues.

Attached is a screenshot of running man set on the remote machine via Mosh.

Connecting to the same machine using the same version of the extension from the app store on a Linux machine works flawlessly, so I believe this may be limited to OS X.

libssh tells us if, during interactive auth, a particular question's response should be echoed to the local terminal (e.g., second factor). Right now, no echoing is done, ever. Plumb this through and honor it.

Right now, the ssh server fingerprint is just printed to the terminal. Just like with OpenSSH and known_hosts, these fingerprints should be saved and verified.

Right now, if you hit the "close" button, the session is just gone without warning. Happily, CTRL-W does not close the window, but is passed to the terminal. Nonetheless, this is problematic.

There are two obvious solutions to this:

1. Keep the session going in the background. This would require some UI changes most likely. The session can always be totally destroyed with Ctrl-^ .. This would be especially nice in conjunction with multiple simultaneous sessions (issue #4).
2. Pop up an "are you sure" dialog. Relatively easy to do, and probably worth doing, even if we take it out later in favor of another solution.

If we're connecting to an old (pre v1.2) mosh-server, it doesn't understand the '-l' option. Consider trying first without it.
Edit: Instead, tolerate the non-fatal error you get from old mosh-servers.

Since the move to PNaCl, the NaCl module take a long time to load the first time after an update. This is likely due to the module being converted to the local architecture. This delay is a bit off-putting, and could be a major annoyance during periods of rapid iteration. See if there's a way to cut down the load time or hide it. Some ideas:

• Load the module immediately upon starting the app, rather than waiting for the user to hit connect. This could hide some of the slowness. This implies using a different mechanism to initiate the connection; this new flow may fit in nicely with issue #4.
• See if we can preload the module as soon as the app is installed or updated. I have some recollection of there being a callback for app updates.
• See if there's a step after linking, like stripping, that could make the module load faster.

I had an issue with mosh triggering strange behaviour due to a vim plugin that I closed as it was really an issue with my vim setup.

It made me realise how slow mosh-chrome is compared to regular mosh or ssh. I created a test file to open up vim, go into insert, enter a text document, then quit and timed it on a Toshiba Chromebook and a 2009 Macbook Pro. Both running Chrome Beta channel Version 22.0.1750 and current version of mosh chrome. In each case they connected to the same VPS and ran the same test. I averaged out the results roughly in my head but they are close enough.

Obviously there are variations in fonts and window sizes etc so each test was doing a slightly different amount of work. If I make the mosh chrome screen really small it manages it is less than 4s so it isn't like it is slow sending the characters. I would guess it is less efficient updating the screen somehow.

• I got a lot of screen corruption with mosh chrome on the mac and I couldn't read the time so it is a rough stopwatch job.

Is there a way to set colors that could be saved, for example setting up solarized theme for mosh. Theme option of Solar (dark/light), light (black on white), and dark (white on black) It could be small or big enhancement project to take on.

Calling exit() is seen as a crash to NaCl. Excessive crashes lead to throttling of module startup, potentially leading to user confusion. Throttling manifests in Chrome's stderr as:

NaCl process launch failed: Process creation was throttled due to excessive crashes

Exits leading to throttling manifest in Chrome's stderr as:

NaCl untrusted code called _exit(0x1)

Find another way to communicate that the session is over, and shutdown the module properly.

I've observed that if I leave CIRC running when exiting Chrome, Chrome still runs in the background until I close the CIRC window. Doublecheck that this is not the current behavior of Mosh. If it isn't, see if it can be made so.

I'm trying out mosh on my Chromebook. If I have the shelf set to auto hide, and make the mosh window fullscreen, then I can never get the shelf back - even if I switch to another app - until I stop mosh being fullscreen again.

Currently, hterm grabs all the keys it can to pass through to the session. For example, this includes Alt-"number" keys, which are often used to switch windows or workspaces, and Alt-minus, which is used on Chrome OS to minimize the window. While some users want those to be passed through (e.g., users of byobu), others may prefer them to be interpreted by the system.

Look into making this a configuration option.

In SHA 56e7051 (issue #8), a fallback locale of en_US.UTF-8 was set. This is hacky. It should follow the local of the browser user.

SSHLogin() is a giant function. It should be broken out into a separate file, various functions, and probably a class. A lot of the flow could be clarified this way.

A report from a user on the Chrome Web Store says that when he uses an SSH key with no passphrase, he is still prompted for one, and when he just hits enter it goes to the next authentication mode.

It would be useful to be able to maintain a list of connection profiles to the various servers the user uses. This list should be synchronized among browsers. This would facilitate managing more advanced options that may come in the future, such as port forwarding, special remote commands, etc. It could also serve as the UI mechanism for dealing with "suspended" sessions, as could happen when accidentally closing a window, or even when saving session state to local storage for resuming from a restart.

e.g. clicking on http://google.com opens google.com in a new tab.

The section: "How can I change the way the terminal looks (font, color, etc.)?" of https://github.com/rpwoodbu/mosh-chrome/wiki/FAQ states that "mosh_client.html" should be opened.
This appears to be incorrect, it should be "mosh_window.html" because term_ is not defined in "mosh_client.html" (see screenshot).

Thanks for a great app. :)

hterm supports osc52 to write from the term to the system clipboard. There are examples of a shell command and vim plugin in libapps/hterm/etc. I have found this works well with Chrome Secure Shell packaged app but when I use mosh, either the packaged app or start mosh over Secure Shell the osc sequence doesn't appear to get through the mosh terminal emulation.

This is probably an upstream issue for mosh. I added a comment at mobile-shell/mosh#382 (comment) but I don't know if it is something that would be fixed upstream. It might be an idea to patch mosh for mosh-chrome because this limits mosh-chrome compared with the Secure Shell app that sets expectations on Chrome. I have looked at the mosh terminal emulation and unfortunately c++ isn't my thing. It looks like they capture OSC sequences and use them for set title and possibly discard the rest but I am not sure how to fix it.

btw tmux also eats osc52 which limits usefullness until I can find a patch for that as well. if testing make sure you aren't running tmux.

Like "Secure Shell", when Mosh exits, it should provide an easy prompt to close the window with a keystroke, rather than requiring the user to click on the "X". Bonus points for allowing starting a new session with a keystroke, too.

Just noticed this today on Chrome OS. When I do either ctrl-shift-v or right click (I'm trying to paste), mosh exits. I then see a message prompting me to hit [x] to close the window.

I'll try rebooting later to see if there's something odd on my system, but I wanted to mention this in case others are seeing it.

I noticed my mosh-server lives on for quite some time even if I close the shell window.

Is there any timeout? How high is it?

And mosh-chrome should peacefully shut down the server if I close the window.

I had a weird issue with arrow escapes occasionally (but not always) being eaten and I thought it was something server side with tmux or vim or something but it only happens using mosh-chrome.

I wondered if it was something in hterm or something with mosh in general bit it doesn't happen using Chrome Secure shell to ssh or when using Chrome Secure Shell to do mosh from a local chroot. In all cases TERM is set the same.

Backspaces are stored literally. This improvement could be fixed simultaneously with issue #1.

There's an API for checking if a new version is available. Since users will often leave the app running for long periods at a time, they might be missing out on new features and fixes without realizing it. Look into ways of surfacing this information and letting them restart the app. Possibilities include:

• Show a notice on the "new session" window.
• Use the Notification API to pop up a notice.
  • But be careful to do this in a way that's not annoying.

I've noticed that the module will take 20-75% CPU every 3 seconds or so, sometimes after about a minute of being idle, although this isn't always repeatable. A keypress seems to get it out of this funk temporarily. The clock in tmux updating every minute doesn't seem to be enough to do it, but more (or different) output seems to help, even without involving keystrokes.

I'm guessing there's some weird issue where there are rapid repeated calls to select() that aren't blocking. Or maybe this is a fundamental Mosh bug (it isn't currently built off of an official upstream release, and I've been putting off doing so until there is a new one). Some instrumentation is warranted.

Chrome OS (Samsung ARM)
Version 34.0.1847.48 beta
Platform 5500.44.0 (Official Build) beta-channel daisy
Firmware Google_Snow.2695.117.0

Copying to clipboard just doesn't work. I can select text, the "cut" icon appears then fades away, but my clipboard keeps the old data. Pasting to the terminal via right click or control shift alt works fine. Copying in Secure Shell and crosh works fine.

Manually hitting Control + C with selected text works, but selecting the text itself should copy it to the clipboard.

I now understand that the naclio library has support for UDP. See about using that instead of PepperPOSIX.

I have reason to believe that when a new update is pushed to the Chrome Web Store and received by the browser, any running copy of the app will be killed. I'm not 100% sure of this, as I've only seen it happen when I pushed the "Update extensions now" button, which may force something. But I suspected this might happen when reading the Chrome App API docs. I was really hoping that this wouldn't happen to an app with a NaCl module, and indeed, maybe it doesn't unless you push that button. More testing is required.

If this does happen during normal operation, there may be a way through the Chrome App API to prevent the app from restarting. I do recall you can get a callback to let you know your app is being "suspended". Worst case is that we could implement issue #6.

The recent feature of allowing password retries (issue #1) isn't working for key passphrases. It returns an error, then says that no ssh key is found (!), and moves on.