バガボンドScanシリーズ掲載原稿：

F-Secure社のSSHサーバーとクライアント導入、構築から運用までのレポート（第二回）

まずは前回の補足から。
F-Secure File Transferクライアントの説明のところで、Tera Term Pro＋TTSSHとffftpという組み合わせについて書いたが、Tera Term Pro2.3＋TTSSH1.5.4という組み合わせの場合SSHはバージョン１しかサポートしていない。そのためSSH2でffftpをトンネルするにはPUTTYを用いなければならない（ちなみにSSH1とSSH2はどんな違いがあるのか、と言えば、SSH1はMan in the middle 攻撃（中間者攻撃と呼ばれることもある）にヤラレてしまうが、SSH2は今のところはヤラレない、という違いだろうか）。

前回はとりあえず動かしたところまで書いた。
今回はさらにいろいろな使い方などを掘り下げてみよう。

まず、サーバーのインストールと起動についてだが、さすがにサーバーソフトウエアを起動する場合はAdministrator権限が必要とのことだ。まあそれはそうだ。管理者権限を持つ人以外が、ネットワーク待ち受けサービスを起動できてしまったらさすがにまずいだろう。
もうひとつ。F-SecureSSHサーバーは、OS再起動時も自動的に起動するようになっている。CygwinベースでOpenSSHデーモンを導入する場合、このあたりも手動で設定しなければならないことを考えると、ますます使い勝手は良いと言えるだろう。
ではSSHの他の実装との接続性はどうだろうか。手元にあるSolaris8上のOpenSSHでテストしてみたところ、F-SecureSSHのクライアントもF-SecureSSHのサーバーも問題なく接続できた。と、クライアントの方で一つ気になったのはデフォルトのウインドウサイズである。デフォルトでは横幅67半角文字分しかない。クライアントソフトウエアで有名なTera Term ProのSSH版TTSSHもPUTTYもデフォルトは80なのに。UNIX端末のデフォルト値でもある80に慣れた身には、この67というのは気にかかる。それにUNIXサーバーにログインする場合、デフォルトでの端末サイズはだいたい80になっていることが多い。で、もっと気になるのはこの値をどうやって変えればいいのかがわからないことだ。しかも調べようとしたらヘルプの日本語？が化けて良く分からない。これにはちょいと閉口した。こんなささいな部分で、使い勝手や印象などは変わって来るものだ（もっとも本連載の主旨は「サーバー」のレビューであるが）。
接続性のテストは逆のパターン（サーバーがWindows2000上のF-SecureSSH、クライアントがSolaris8上のOpenSSH）でもやってみた。もちろんそれもOK。しかしやはりここでも漢字コードの壁が。基本的に単なるSolarisではEUCなので、Windowsのサーバーにログインすると文字化けしてしまうのだ。これは避けがたい問題なのか。しかし、SSHというものの主な用途を考えると、端末がUNIX機であることが多いのではないだろうか。そうなると何らかの回避策もしくは対策が必要になるように思える。
例えばクライアントがWindowsでサーバーがUNIXであれば、ログイン時にLANG環境変数などが設定されなければ日本語表示されないなどの回避策がある。日本語表示でなければ文字化けはしないからだ。
漢字コードの問題はOSに依存してしまうため、また、ログイン時に起動しているのがcmd.exeであるために、SSHサーバー側ではいかんともし難いという気もするが、それでも何とかしておきたいところだ。・・・何とかする方法を一つ思いついた。cmd.exeではなく、cygwinを起動してしまえば、文字化け無く、かつcygwin環境を利用できる。（前回の記事では「Cygwin環境に耐えられないマシンなどは・・・」と書いているので、その言い方とは矛盾してしまうが（笑））
接続性について、Windows上のF-SecureSSHサーバーに対し、WindowsのPUTTY（＋ISO2022日本語入力パッチ）からログインしてみた。すると画面上の各行にアンダーラインが入ってしまい、かつ文字化けしてしまう。試してみて驚いたのだが、PUTTY（＋ISO2022日本語入力パッチ）の変換可能コードにはShift-JISは入っていないようだ。今回までには試すことができなかったが、PUTTY本体のみであれば、
"Received data assumed to be in which character set": UTF-8
"Translate ISO 2022 from/to UTF-8": check
"Initialisation code": ms_kanji
という設定にすれば表示できるらしい。これについては検証環境が手元に無いため、宿題とさせていただきたい。なお、TTSSHはSSH1のみにしか対応していないためこれも今回は試していない。また、Tera Term Web 3ベースのクライアントも、筆者の手元にある3.1は端末設定がバギーであるため、こちらも連載中にバグフィクス版が間に合えば試してみたい。
（ただし、相互接続性ということで言えば、この2月27日にF-SecureSSHクライアントUNIX版、MAC版が発表されているため、Windows上のF-SecureSSHサーバーへの接続性は良くなっているかも知れない。後日ばかりで申し訳ないが、ここも追跡調査とさせていただきたい）

さて、さらにサーバーがわの機能を掘り下げてみよう。
まずひとつ気になったのは、インストール直後のデフォルトではいわゆるPermit administrator loginの状態になっているということだ。管理用途のツールはやはりセキュリティに気を配らなければならないはずなので、直接administrator権限でのログインはできれば避けたい。しかし、UNIXでのsshdサーバーを起動している場合などと異なりPAM認証なども無くsudoも無くsuログインもできない。つまり、administrator権限でリモートからログインの許可をしないと、金輪際administrator権限を使えないということなのだ。OSの仕様によるのでこのあたりはF-Secure SSH Serverの責任ではぜんぜん無いが、直接administratorでログインできるサービスとして公開しなければならないのは気持ちが悪い。しかしこの点は、例えCygwin＋OpenSSHであろうと同じだ。
もうひとつ気になったのは、Configurationで言えば「Network」のところにある「Rewuire reverse DNS mapping」という設定だ。なぜ気になったのかと言えば、GUIから見た設定値が「No,but try」となっているのに、テキストエディタベースで直接設定ファイルを見ると（ProgramからView Configurationを選ぶ）おそらくこれは、
RequireReverseMapping no
#(Specifies whether the server should map IP-address to a domain name.
# If "yes", server doesn't accept connections from hosts whose
# IP-address doesn't map to a valid domain name.)
ResolveClientHostName yes
という設定値のところだと思うが、この見せ方だと意味がわかりにくいと感じた。設定値は「No,but try」の他に「No」「Yes」があるが、「No」の場合はRequireReverseMapping、ResolveClientHostNameともにnoとなり、「Yes」の場合は両方yesになる。これはわかるが、No,But tryという選択肢だと今ひとつピンと来ない。
気になるところはその程度だ。

次回はトンネリング機能の利用や、無線LAN環境での利用について検証してみたい。