View Single Post
  #22  
Old 01-31-2018, 02:08 PM
mdella's Avatar
mdella mdella is offline
Registered User
 
Join Date: Mar 2004
Location: Scotts Valley, CA
Posts: 44
Adding my support for request...

Well, was tracing this down and I think this is the "final" and authoritative thread here about MOSH.

Recognizing the limits on licensing, I still wanted to add my +1 as all the terminal features, etc of SecureCRT I enjoy and prefer however due to the types of networks I'm dealing with lately, MOSH has been our only option to deal with "run away display processes". Playing with screen and other systems just isn't quite giving us the flexability needed. And now that I personally am commuting on the "Silicon Valley" highway 17 bus, I'm almost resigned to that being the only way to work while commuting (and since its 2 hours a day, its quite a bit of time).

BTW, it appears that the GPL license has changed from that previously reported. I just looked at its using GPLv3+... Don't know if that makes a difference....

Code:
mosh 1.3.0 [build mosh 1.3.0]
Copyright 2012 Keith Winstein <mosh-devel@mit.edu>
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
So, experimenting with the suggested "local shell" above and the like. See what we turn up overall.

Followup #1: Further investigation of "how" the MOSH protocol works and the keyboard display unit as well as the network stack shows that this is more and more unlikely to be implemented in something like SecureCRT natively (although there might be a way to hook in the transport). Additionally, for licensing purposes you'd want the mosh body of work to be independent from SecureCRT as there are other restrictions in the licensing beyond "open source your code". Specifically, since this is dealing with security software, there are a number of "three letter word" customers out there are would NOT fit into the MOSH MIT version of licensing. No one in their right mind would want to implement something that then destroys a large portion of their customer base.

I'm still trying to noodle around if there is a way to insert this in the "stream" of traffic so that I can still use CRT (or in this case, SecureCRT) as my "terminal" and MOSH as the transport outside of the terminal. The "key exchange" portion of MOSH is too "command line'ish" for it to be a serious protocol IMHO. And since its a symmetric key being exchanged (over SSH of course, but still, it lives somewhere), there are a ton of other vetting issues that would need to happen there as well to be a "serious" security tool. But for what the protocol is meant to be... and how it was originally designed... thats still a highly useful piece that many of us have come to rely on for our "faulty" connections (glad the internet is improving over time... cough cough cough).

Followup #2: Turns out if I'm on a unix based machine (like ubuntu, MacOS, etc) I can sort of make this work. On a windows box so far I have been thwarted from using SSH to get the process started on the other side and send the session key back to me. I have however found that MobiXterm (https://mobaxterm.mobatek.net/) has a mosh client built into it. The SSH connection portion is rudimentary at best and the terminal emulation seems to have a lot to be desired, but since there is no way to get SecureCRT to use MOSH currently, this is probably the next best way to get MOSH working on your windows box inside of a native Windows environment.

I have just finished setting up a VirtualBox with a minimal Ubuntu inside of it and the mosh client as well as ssh. So you can bring up a 256Mb VirtualBox VM and basically create a unix-to-unix session connection over the MOSH protocol. Again, this is painful when you consider what you have to give up as a terminal client like SecureCRT, but at this point, its pretty much (for those of us with PCs) 2 of your 3 options (the third being running Cygwin on your machine... cough cough).

If ALL of this is too much (and it practically is for many), then your next best fallback to "retaining sessions over breaking TCP links" is to run something on the unix server your logging into like screen (via your login shell) with enough smarts to know if this is a "reconnect" to connect to an existing screen rather than starting a new one (https://superuser.com/questions/5800...upon-ssh-login)

Marcos
__________________
Marcos Della
Data Center Cloud Architect
Nutanix

PGP Fingerprint: BDC7 AFFD E94F FA09 C839 9153 F5FF E128 3094 2B9E
Key ID: 0x30942B9E

Last edited by mdella; 01-31-2018 at 09:13 PM.
Reply With Quote