[mosh-users] Server install instructions and binaries

[Keegan McAllister]

> Tried compiling from source as well, but got "configure: error: Unable to
> find byte swapping functions"

That's odd.  If you send me the file "config.log" I can try to debug the
problem.  But it should go away with the latest source from Git, or the
upcoming Mosh 1.2 release.  We added a bulit-in fallback for those
byte-swapping routines.

By the way, which version of Debian are you running?


> In that case, it's like a complete alternative to sshd and I strongly suggest
> to work on improving the gnu ssh tools instead of a separate tool, in the sense
> of open source.

Mosh's approach is fundamentally different from SSH's.  Mosh contains a full
VT220 terminal emulator; I don't think the OpenSSH maintainers would appreciate
importing this into their codebase!  On the other hand, Mosh doesn't do any
user authentication or public-key cryptography, because we delegate those
things to SSH.

Furthermore, baking Mosh into sshd would *guarantee* that nobody can install it
without root, and would introduce a delay of years to get Mosh into stable
versions of popular operating systems.  By contrast, many people are already
using mosh-server without root (though I'm sorry that you are not able to).

There's nothing "un-open-sourcey" about running our own project.  To the
contrary, an open-source operating system consists of thousands of separate
projects.  They cooperate through well-defined interfaces, as Mosh cooperates
with SSH.  There's no need to have everyone committing to the same repository
and stepping on each other's toes.

By the way, which gnu ssh tools are you referring to?  OpenSSH is not a GNU
project; it came out of OpenBSD: http://www.openssh.com

We've generated a lot of confusion by saying both that Mosh is an SSH
replacement and that Mosh uses SSH.  It's a replacement in the sense of user
experience: if all goes well, you type "mosh user at host" instead of "ssh
user at host".  But it's not at all a replacement for the SSH codebase.  We rely
on existing SSH infrastructure to make Mosh's security story much simpler.  So
I think you were correct when you said it's a tool to seamlessly make existing
ssh better -- with the caveat that the Mosh project is very young and so there
are still a lot of seams!


> that's what the intro video and website conveys.

We have an intro video??  Cool, I want to see it. :D


> the latest .tar.gz on http://mosh.mit.edu/ is a couple of weeks out of date.

To be clear, this is deliberate: the periodic releases get more testing than
each individual Git commit.


> > In the end, I expect the mosh client to install the necessary mosh-server
> > binary *automatically* for me.
>
> I sincerely hope this bug (it's not a feature) is never implemented.
>
> This sounds like a horrible idea and I would never ever configure any of the
> systems I administer to allow this.

Well, I haven't made up my mind yet about whether it's a bug or a feature. :)
But I certainly want to hear more detail about why people dislike this idea.
We're tracking the issue as https://github.com/keithw/mosh/issues/188 .
Comments there would be greatly appreciated.  In addition to administrative /
policy problems, there are a number of technical issues we would need to
overcome.

Alex is right that, in principle, Mosh uploading a binary to the user's homedir
is no different from the user doing it 'manually'.  In fact there's no way for
Mosh to do anything the user couldn't, because all of Mosh's code runs as that
user.  It's not clear how one *would* technically prevent the upload, without a
blunt instrument like trusted path execution or mounting /home noexec.

But I can still appreciate that admins are suspicious of this kind of action at
a distance.

keegan