Mobile Shell，或简称为MoSH，在GitHub上发布，是移动设备上SSH的替代品。阐释MoSh背后的原则的技术论文将在下月召开的2012 USENIX年度技术会议上发布。
下述两个重要特性是MoSH有别于其它类似产品的：
- 第一，连接的IP地址不可知；而不是采用TCP/IP连接，数据通过UDP/IP发送。好处是，如果移动设备无信号或设备的IP地址改变（因为移动设备可以在WiFi网络和蜂窝网络间漫游），那么在传输层保持有状态连接就不那么可靠。
- 第二，MoSH没有在客户端与服务器之间提供一个透明的加密字节流，让服务器通过重绘屏幕来响应的机制；MoSH客户端提供了一个本地 echo的变体。这意味着，当用户通过键盘输入了一个‘X’，MoSH不会通过客户端将‘X’发送给服务器，再由服务器传输回客户端在屏幕上显示这种方 式，而是立即在客户端屏幕上显示‘X’。
这两个改变显然与层次架构的连接流，如SSH，区别明显；SSH提供了只在两个端点之间的加密字节流，然后要远程服务器程序重绘屏幕。因为SSH完全不知道连接各个端点如何使用数据，任何击键都至少要在客户端与服务器间往返一次才能显示。
MoSH在服务器创建一个进程，运行于用户空间，监听UDP包。然后将服务器地址（和UDP端口）告知MoSH客户端，并通过以数据包的形式发送数 据来初始化连接。然而，因为连接本身在网络层是无状态的，如果客户端IP地址发生变化，则UDP包可以来自一个不同的IP地址（发送给同一服务器）而不会 失去连接。
采用UDP，而非TCP，同样意味着MoSH客户端/服务器需要各自管理状态。连接中的每一个数据包都有一个自增长的数字，同时客户端和服务器都建 立一个已知数据包的列表，当需要的时候MoSH库会重新发送数据包。（这基本上就是TCP原理的精髓。）也因为如此MoSH客户端可以在不同的IP地址或 （将来）在IPv4与IPv6之间切换。服务器端的IP地址必须保持不变。
通过MoSH连接发送的数据包采用AES-128 OCB模式加密。该加密算法提供了采用固定密钥的加密端点，密钥在服务器启动时生成，并在连接信息中显示：
$ mosh-server MOSH CONNECT 60004 4NeCCgvZFe2RnPgrcU1PQw …
虽是新方法，但AES-128 OCB已经出现了一段时间，并且该算法作者指出他们正在邀请更进一步的审查：
你们的安全数据报协议已经通过专家审核了吗？
还没有。MoSH开始被越来越多的使用，并且代码被有强烈安全意识的加密极客阅读过，他们认为MoSH的设计是合理的，但是任何新的数据报协议都要 自我证明其安全性，SSP也不例外。我们使用了AES-128和OCB的参考实现，同时我们也欢迎人们来审阅代码。我们认为设计的简单性是个显著的优势， 然而，当然别人也可能认为这是错误的。我们毫不怀疑需要花些时间（这是当然的！）才能让安全社区对MoSH的安全性感到满意。
另一个重大改变是在客户端与服务器进程间同步屏幕状态。绝大多数时候，当用户输入一个字符后（比如字符‘X’），希望看到X显示在屏幕上；并且当他们按下退格键，用户希望字符被立即删除。对于上/下/左/右键来说也类似，通常要移动一个字符。
为了达到这个目标，MoSH服务器存储了一个客户端的模拟屏幕（反之亦然），并基于在“正常”情况下按键是否会改变屏幕显示来预测。 如果预测失效，MoSH客户端将会等待与服务器间往返的时间以确认屏幕显示状态（本质上说是减少老的SSH机制），但如果MoSH确信击键会引发屏幕更 新，那么MoSH将会直接在本地显示。在类shell环境中（大部分击键都要回显），这将会减少服务器端引起的感知延迟，另外也可减少网络发送的传输量， 因为击键可以批量发送，而非像大多数交互式连接那样每次按键发送一个数据包。
一个限制是输入只支持UTF-8，因为多次按键可以转化为单一字符（反之亦然）。MoSH不是要试图解决所有的编码和输入法的问题，而只专注于UTF-8并保证其工作正常。更多细节可参考技术信息页面。
MoSH带来了一种在移动设备和服务器间连接的新方法。每个客户端连接使用一个单独的UDP端口（UDP必须在两个端点间可达），然而通道是用私钥 加密。因为连接可以转换到其它IP地址上，自然会引发对于连接可能被侵入的担忧，并且事实上“连接”在客户端断开后仍可保持对一些人来说也值得担心。
然而，它的优势，特别是提高了响应时间的感知，可能激发人们关注这个系统。同时因为两边的进程都是用户进程，MoSH可以很容易的安装在已有的环境中，而无需提升权限进行安装。