【ITニュース解説】ssh from 3 places: Why TinyCore inside Oracle VM worked when PuTTY and PowerShell didn't

リモートのコンピューターに安全に接続し、コマンドを実行したりファイルを転送したりするための重要な技術として、SSH（Secure Shell）がある。今回の記事では、VyOSというルーターOSが稼働する仮想マシンに対し、異なる環境からSSH接続を試みる中で直面したネットワークのトラブルとその解決方法、そしてそこから学べる基本的な知識について解説する。

コンピュータ同士が通信する際、データは複数の段階を経てやり取りされる。これを「階層（レイヤー）」と呼ぶ。SSH接続を理解するには、少なくとも以下の三つの階層の概念が重要だ。

一つ目は「L3（ネットワーク層）」である。この層では、IPアドレスを使ってデータがどのコンピューターに送られるかを決める。それぞれのコンピューターには固有のIPアドレスが割り当てられ、このアドレスを使って通信相手を特定する。pingコマンドは、特定のIPアドレスを持つコンピューターにデータが到達できるかを確認するためのツールであり、L3の接続性を確認する際に利用される。

二つ目は「L4（トランスポート層）」である。この層では、特定のプログラム（アプリケーション）にデータを届けるための通信経路を確立する。SSHのようなサービスは、一般的に「ポート番号」という識別子を使用して通信を行う。SSHは通常22番ポートを使用する。例えば、nmapやncatといったツールは、特定のIPアドレスの特定ポートが開いているか、サービスが待ち受けているかを確認するために使われ、L4の接続性をテストできる。

三つ目は「L7（アプリケーション層）」である。この層は、実際にユーザーが使うアプリケーションのデータがやり取りされる部分だ。SSHクライアントとSSHサーバーが具体的な通信を行い、ユーザー認証を経て安全なリモート操作を可能にする。

まず、WindowsのPCからVyOS仮想マシンへSSH接続を試みた。具体的には、PowerShellのSSHクライアントやPuTTYというツールを使った。しかし、これらの試みは全く成功しなかった。表示されたエラーメッセージは「Connection timed out（接続が時間切れになった）」や「Request timed out（要求が時間切れになった）」といった内容だった。これらのメッセージは、SSH接続を試みたVyOSのIPアドレス（192.168.56.101）に対し、そもそもWindows PCから到達できていないことを示していた。L3の接続性を確認するためpingコマンドでVyOSのIPアドレスに通信を試みたが、これも一切応答がなかった。これは、L3（ネットワーク層）の段階で通信が途絶えている明確な証拠である。

通信ができない根本的な原因は、VyOS仮想マシンのネットワーク設定にあった。VyOSのLAN側インターフェース（eth0）が、仮想化ソフトウェアであるVirtualBoxの「Internal Network（内部ネットワーク）」というモードに設定されていたためだ。この設定では、同じ「Internal Network」に属する仮想マシン同士でしか通信ができず、VyOSを動かしているWindowsホストPCからは直接アクセスできない状態になっていた。WindowsホストPCから仮想マシンにアクセスするためには、「Host-Only Adapter（ホストオンリーアダプター）」という別のモードに設定する必要があった。「Host-Only Adapter」は、ホストPCと仮想マシン間で直接通信できるようにする機能である。L3で通信が確立できない以上、その上位層であるL4（ポート22）やL7（SSHサービス）へのテストは不可能だった。この問題はVyOSのSSHサービス自体に不具合があったわけではなく、WindowsホストPCとVyOS仮想マシンの間の「ネットワーク境界」の設定ミスによって引き起こされたのである。

次に、VyOS仮想マシンと同じVirtualBox上で稼働する、別の軽量なLinux仮想マシン「TinyCore」からSSH接続を試みた。TinyCoreからVyOSのIPアドレス（192.168.56.101）へpingを実行したところ、問題なく応答があり成功した。これはL3（ネットワーク層）での接続がTinyCoreとVyOSの間で確立されていることを意味する。

L3接続ができたため、SSHクライアントで接続を試みた。しかし、最初の試みでは「Connection refused（接続が拒否された）」というエラーメッセージが表示された。これは、L4の段階でVyOSのポート22に到達できたものの、SSHサービスが接続を拒否したことを示唆する。この状況から、VyOSのSSHサービスが稼働していないか、何らかの設定で接続を拒否している可能性が考えられた。

そこで、VyOSの仮想マシン内で、SSHサービスが実際に稼働しているかを確認した。sudo ss -tlnpというコマンドを実行すると、VyOS上でSSHデーモン（sshd）がポート22で接続待ちの状態にあることが確認できた。この結果から、VyOSのSSHサービス自体は正常に動作しており、外部からの接続を待ち受けていることが判明した。VyOS側が正常なのに接続できないのはなぜだろうか。さらに調査を進めると、今度はTinyCore仮想マシン自体に「SSHクライアント」がインストールされていなかったことが判明した。まるで電話をかける相手はいるのに、手元に電話機がない状態と同じである。tce-load -wi opensshというコマンドを実行してSSHクライアントをTinyCoreにインストールすると、ようやくVyOSへのSSH接続が成功した。

このTinyCoreからの接続が成功した背景には、TinyCore仮想マシンとVyOS仮想マシンが、VirtualBoxの同じ「Host-Only Adapter」ネットワーク（192.168.56.0/24）内に存在していたことが大きい。これにより、二つの仮想マシン間には特別なネットワーク障壁がなく、L3からL7までスムーズな通信が可能だった。

今回の経験から、Windows PCからSSH接続ができなかったのは、VyOS仮想マシンのネットワークアダプターが「Internal Network」に設定されていたため、WindowsホストPCとVyOSの間でL3接続が確立されなかったことが直接の原因である。さらに、WindowsホストPCと仮想ネットワークの間にはWindowsファイアウォールも存在し、これも通信を阻む要因となる場合がある。一方、TinyCore仮想マシンから成功したのは、TinyCoreとVyOSが同じVirtualBoxの「Host-Only」ネットワーク内にあり、L3接続が問題なく確立され、間に特別な障壁がなかったからだ。最終的には、TinyCoreに必要なSSHクライアントをインストールすることで接続が完了した。

今回の検証から学ぶべき重要な教訓は、ネットワークのトラブルシューティングでは、まずL3（ネットワーク層）の接続を確認し、次にL4（トランスポート層）のポート接続、そしてL7（アプリケーション層）のサービスが動作しているか、さらにクライアントに必要なツールがインストールされているか、という段階を踏んで検証することが非常に重要であるということだ。仮想環境のネットワーク設定一つで、通信の可否が大きく変わるため、その設定には特に注意を払う必要がある。エラーメッセージはトラブルの原因を特定する上で非常に貴重な情報源となるが、そのメッセージの背後にある真の原因を見抜く洞察力も求められる。