Q: 誰が Mosh を書いたのですか?
Mosh は Keith Winstein と Anders Kaseorg, Quentin Smith, Richard Tibbetts, Keegan McAllister, John Hood によって書かれました。
Q: なぜ別のリモート端末プロトコルなのですか? Q: moshの原則は他のネットワークアプリケーションにも当てはまりますか?
私たちはそう考えています。 表示されている状態が古くなった場合にユーザーに警告すること、警告がない場合、ユーザーは以前のすべてのトランザクションが成功したことを知っているので、すべてのトランザクションをシリアライズおよびチェックポイントすること、および期待されるイベント (ある WiFi ネットワークから別のネットワークへのローミングなど) を優雅に処理することです。 (Gmailが10時間も「送信中…」になったまま、新しいメールを陽気に取得し、何のエラーも表示しないことはありませんか? 私たちもそうでした)。
Q: “mosh requires a UTF-8 locale” と表示されるのですが。 どうしたらいいですか?
この問題を診断するには、ローカル端末でlocale
を実行し、ssh remotehost locale
を実行してください。 Mosh を使うには、接続の双方が LC_CTYPE="en_US.UTF-8"
.
のような UTF-8 ロケールを示す必要があります。
多くのシステムでは、SSH はロケール関連の環境変数を転送し、それは mosh-server
によって継承されます。 このメカニズムが失敗した場合、Mosh (バージョン 1.2 以降) はその変数を自分自身で渡します。 どちらのメカニズムも成功しなかった場合、
mosh remotehost --server="LANG=en_US.UTF-8 mosh-server"
リモートサーバに en_US.UTF-8
が存在しない場合、これを存在する UTF-8 ロケールに置き換えるというようなことが可能です。 また、mosh-client
の恩恵を受けて、ローカルにLANGを設定する必要があるかもしれません。 ローカルとリモートのマシンが異なるロケール名を必要とする可能性があります。
Q: “Nothing received from the server on UDP port 60003” というメッセージは何を意味しているのでしょうか?
これは、mosh
がリモートマシンでmosh-server
を正常に起動できたが、クライアントがサーバと通信できないことを意味します。 これは一般に、何らかのファイアウォールがクライアントとサーバー間のUDPパケットをブロックしていることを意味します。 もしSSHのためにNATでTCPポート22を転送しなければならなかったのなら、UDPポートも転送しなければならないでしょう。 Moshは60001から始まって60999で止まる、最初に利用可能なUDPポートを使用します。 もし、サーバー上で少数の同時セッションしか行わないのであれば、より小さな範囲のポートを転送することができます(例:60000から60010)。
netstat、netcat、socat、tcpdump のようなツールは、ネットワークやファイアウォールの問題をデバッグするのに便利でしょう。
この問題は、protobuf や utempter とリンクし、積極的なコンパイラ強化フラグを使用するプログラムに影響を与える glibc 2.22 のバグの結果である可能性もあります。 (glibc bugtracker のエントリ、および Mosh bugtracker のエントリ) この問題は mosh-server が起動時にすぐにセグメンテーションフォールトを起こす原因となっています。 私たちは Mosh 1.2.6 でこの問題を回避したと考えていますが、もしそうでなければ、 バグを報告してください。
私たちは本当に UTF-8 の狂信者ではありません。 しかし、さまざまな難しいエッジケースで正しいことをしようとするよりも、ひとつの端末エミュレータを正しく実装する方がずっと簡単です。 (これはGNU screenがやろうとしていることで、わたしたちの経験では、非常にトリッキーなデバッグの状況を引き起こします)。 ですから、moshは、ユーザがUTF-8クリーン経路のためにすべてを設定するまで、起動しないのです。 これは迷惑なことかもしれませんが、おそらく将来的なフラストレーションを軽減してくれるでしょう。 (残念ながら、8 ビット vt220 と UTF-8 vt220 は異なる、互換性のないターミナルタイプです。)
Q: 異なる SSH ポート (22 以外) を使うにはどうしたらよいですか?
Mosh 1.2 では、ssh
に以下のように引数を渡すことができます:
mosh remotehost --ssh="ssh -p 2222"
あるいは ~/.ssh/config
に Port
命令でホスト・エイリアスを設定することも可能です。
Q: 「mosh-server not found」と表示されるのですが。
クライアントにmoshがインストールされていて、接続しようとしているサーバにmosh (少なくともmosh-server) がインストールされていることを確認してください。 また、サーバーのデフォルトログインPATH
で利用できることが期待されますが、OS XやBSDサーバー、あるいはホームディレクトリにmosh-serverをインストールした場合は、通常そうではありません。
Q: SSH では Kerberos チケットで認証されるのに、Mosh ではパスワードを要求されるのですが、どうしたらいいでしょうか?
いくつかの構成では、SSHはKerberos GSSAPIプラグインに渡す前にホスト名を正規化します。 最初のフォワードDNSルックアップはMoshのラッパースクリプトによって行われるため、これはMoshのために壊れます。 これを回避するには、Moshを
mosh remotehost --ssh="ssh -o GSSAPITrustDns=no"
として起動します。これはラウンドロビンDNSセットアップでしばしば失敗します。 この場合、おそらくラウンドロビン・プールから特定のホストを選ぶのが最善でしょう。
Q: なぜ端末のスクロールバックバッファが不完全なのでしょうか?
Mosh は端末の可視状態のみを同期します。 この問題を追跡しています。この問題と、そこからリンクされている他の問題を参照してください。
Q: どうすれば256色になりますか?
256 色が使えると宣伝しているターミナルで mosh を起動していることを確認してください。 (これは一般に TERM が xterm-256color か screen-256color-bce であることを意味します)
Q: Mosh のデフォルトのエスケープ文字である C-^ はどのように入力すればいいのでしょうか?
米国配列のキーボードでは、Ctrl-Shift-6、またはCtrl-6と入力できます(これはOSと端末エミュレータに依存します)。 米国以外のキーボードでは、正しいキーを見つけるのが難しいことが多く、まったく利用できないこともあります。 キーボードにアクセント記号付きのデッドキーがある場合、このキーが正しいキーである可能性は高くありません。 Ctrl-6が使えることもありますが。 もしこの文字が入力できないなら、MOSH_ESCAPE_KEY
変数を設定する必要があります。
mosh-server(1) manページの MOSH_SERVER_NETWORK_TMOUT
とMOSH_SERVER_SIGNAL_TMOUT
の項目を参照してください。
Q: Moshのセキュリティの実績はどうなっていますか?
Mosh 1.0は2012年3月にリリースされました。 2017年7月のMosh 1.3.2リリース時点では、開発者が把握している限りでは。
- 過去4年間、Moshにいかなる種類のセキュリティ脆弱性(メジャーまたはマイナー)も報告されていない。
- これまで Mosh で重大なセキュリティ脆弱性が報告されたことはありません。 私たちは主要なセキュリティ脆弱性を、特権の昇格、リモートコードの実行、第三者によるサービス拒否などを含めて定義しています。
- 2012年のリリースでは、2つのサービス拒否の問題が発見され修正されています。 1つは、mosh-server が themosh-client に過剰な CPU を使わせる問題です (CVE-2012-2385, Mosh1.2.1, released May 2012 で修正済み)。 もう一つの問題は、サーバーホストによって mosh-client が不正なアドレスに UDP データグラムを送信し、接続しようとすると失敗するというものです (2012 年 10 月にリリースされた Mosh 1.2.3 で修正済み)。
Q: Mosh のセキュリティは SSH と比べてどうなのでしょうか?
Mosh の保守的な設計は、その攻撃対象が OpenSSL や OpenSSH のようなより複雑なシステムと比べて有利であることを意味すると考えています。 Moshの実績は今のところこれを裏付けています。 しかし、結局のところ、Moshに最初の深刻なセキュリティ上の脆弱性が発見されるのは、それが最初からあったのか、それとも開発中に不注意で追加されたものなのかは、時間が経ってからしかわかりません。 OpenSSH と OpenSSL はより多くの脆弱性を抱えていますが、 より長くリリースされ、より普及しています。
具体的な一面では、Mosh プロトコルは SSH よりも安全です。 SSH は安全なストリームの内容を運ぶために認証されていない TCP に依存しています。 つまり、攻撃者はたったひとつの偽の “RST” セグメントで SSH 接続を終了させることができるのです。 対照的に、Mosh はそのセキュリティを別の層で適用します (すべてのデータグラムを認証します)。したがって、攻撃者が継続的にパケットが相手側に到達するのを妨げない限り、攻撃者は Mosh セッションを終了させることはできません。
しかし、典型的な使用法では、Mosh はセッションの最初に鍵を交換するために SSH に依存するので、Mosh は SSH の弱点を受け継ぎます-少なくとも、長く続く Mosh セッションを設定するために使われる短い SSH セッションに影響がある限りは。
私たちが知っている限りではありません-MoshはOCB3を使用しています。 論文の著者は、この攻撃はOCB3には適用できないと書いています。
Q: なぜmoshはセッションキーにAES-192やAES-256ではなく、AES-128を使っているのですか?
- AES-128 はセッションキーとして十分すぎる長さです。
- OCB FAQ では AES-128 を推奨しています。 (Schneier: “256ビット版のキースケジュールはかなりお粗末で、私たちが2000年の論文で指摘したことですが、128ビットキーのAESには適用されません。”) このブログ記事を参照)
Q: mosh は Amazon EC2 で動作しますか?
はい、動作しますが、EC2のファイアウォールでUDPポート60000-61000を開放することを忘れないでください。
Q: moshが正しく動作しているかどうかは、どのようにすればわかりますか?
mosh user@server
を実行した後、成功すれば、リモートマシンのログインシェルにドロップされます。 もし、sshの代わりにmoshが使われていることを確認したい場合は、Ctrl-^ Ctrl-Z
と入力してセッションを中断してください (クライアントがmosh 1.2.4以降である場合)。 その後、fg
を実行すると戻ります。
Q: mosh, mosh-client, mosh-server はどう違うのですか? どれを使えばいいのでしょうか?
mosh
コマンドはラッパースクリプトで、moshの主な使用方法となるように設計されています。 ほとんどの場合、コマンドラインで “ssh” を “mosh” に置き換えるだけでよいのです。 裏側では、mosh
ラッパー・スクリプトはサーバーに SSH 接続し、mosh-server
を起動し、SSH 接続を終了します。 その後、クライアント上で mosh-client
実行ファイルを起動し、新しく生成された mosh-server
インスタンスに接続するために必要な情報を渡します。
通常の使用では、mosh-client
と mosh-server
は直接実行される必要はありません。
Q: moshクライアントとサーバを別々に実行するにはどうしたらよいですか?
mosh
ラッパースクリプトがうまく動作しない場合、mosh-client
と mosh-server
プログラムを別々に実行して、接続を形成してみることができます。 これは便利なデバッグのテクニックになります。 リモートホストにログインし、mosh-server
を実行します。
以下のような出力が得られます:
$ mosh-server MOSH CONNECT 60004 4NeCCgvZFe2RnPgrcU1PQwmosh-server (mosh 1.1.3)Copyright 2012 Keith Winstein <[email protected]>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.
2. ローカルホストで、
$ MOSH_KEY=key mosh-client remote-IP remote-PORT
を実行します。ここで、「キー」は mosh-server が出力する22バイトの文字列(この例では「4NeCCgvZFe2RnPgrcU1PQw」)、「リモートポート」はサーバーが与えるポート番号(この場合は60004)、「リモートIP」はサーバーのIPアドレスになります。 サーバのIPアドレスは “host remotehost “で調べることができます。
3.すべてがうまくいけば、Moshの接続はうまくいっているはずです。
Q: FreeBSD や OS X で mosh-server を使うと、時々変な色の問題が出ます。 どうしたのでしょうか?
このバグは Mosh 1.2 で修正されました。 Ed SchoutenとPeter Jeremyに感謝します。
Q: moshに貢献するにはどうしたらいいですか?
私たちはあなたの貢献を歓迎します! Freenode IRCの#mosh
チャンネルに参加するか、GitHubにアクセスするか、[email protected]
にメールしてください。 コードベースに貢献するには、GitHubでリポジトリをフォークして、そこでプルリクエストを開いてください。
Q: 誰がmoshに協力したのですか?
- Hari Balakrishnan はこの作業に助言を与え、名前を考えてくれました。
- Paul Williams は vt500 状態図をリバースエンジニアリングして、Mosh パーサーの基礎とした方です。
- Mosh の predictive echo のチューニングと計測のためにセッションログを提供してくれた匿名ユーザー。
- Nickolai Zeldovich は Mosh 研究論文について有益なコメントをくれました。
- Richard Stallman は SUPDUP Local Editing Protocol の能力について有益な議論をしました。
- Nelson Elhage
- Christine Spang
- Stefie Tellex
- Joseph Sokol-.マーゴリス
- Waseem Daher
- Bill McCloskey
- Austin Roach
- Greg Hudson
- Karl Ramm
- Alexander Chernyakhovsky
- Peter Iannucci
- Evan Broder
- Neha Narula
- Katrina LaCurts
- Ramesh Chandra
- Peter Jeremy
- Ed(エド Schouten
- Ryan Steinmetz
- Jay Freeman
- Dave Täht
- Larry Doolittle
- Daniel Drown
- Timo Juhani Lindfors
- Timo Sirainen
- Ira Cooper
- Felix Gröbert
- Luke Mewburn
- Anton Lundin
- Philipp Haselwarter
- Timo J. Rinne
- Barosl Lee
- Andrew Chin
- Louis Kruger
- Jérémie Courrèges-
- Louis Kruger
- Andrew Chin
- パシ・シェホルム
- リチャード・ウッドベリー
- イゴール・ブカノフ
- ジェフリー・トーマス
- スティーブ・ディグナム
- 樋口裕太
- バルシュ・シェアク
Andrew Chin
Andrew Chin
(敬称略、以下同