一定の条件下で、Google Compute Engine インスタンスが SSH 接続を受け付けなくなることがあります。これには、ディスクの容量不足から sshd の構成ミスまで、さまざまな理由が考えられます。このセクションでは、一般的な SSH の問題のトラブルシューティングと解決のためのヒントと方法をいくつかご紹介します。
ファイアウォール ルールを確認する
Google Compute Engine では、SSH トラフィックを許可するファイアウォール ルールのデフォルト セットが各プロジェクトに用意されます。このデフォルトのファイアウォール ルールがなんらかの理由で削除されると、インスタンスにアクセスできなくなります。gcloud compute コマンドライン ツールでファイアウォールのリストを調べて、default-allow-ssh ルールがあることを確認してください。
gcloud compute firewall-rules list
このファイアウォール ルールがない場合は、追加し直してください。
gcloud compute firewall-rules create default-allow-ssh --allow tcp:22
シリアル コンソールで問題をデバッグする
インスタンスのシリアル コンソールへの読み取り / 書き込みアクセスを有効にして、コンソールにログインし、インスタンスの問題をトラブルシューティングできます。これは、SSH を使用してログインできない場合や、インスタンスがネットワークに接続していない場合に特に便利です。どちらの条件でも、シリアル コンソールには引き続きアクセスできます。
インタラクティブ アクセスを有効にして、インスタンスのシリアル コンソールに接続する方法については、シリアル コンソールとのやり取りをご覧ください。
ネットワークをテストする
netcat ツールを使用してインスタンスのポート 22 に接続すると、ネットワーク接続が正常に動作しているかどうかを確認できます。接続に成功して ssh のバナー（例: SSH-2.0-OpenSSH_6.0p1 Debian-4）が表示された場合は、ネットワーク接続が正常に動作しているため、ファイアウォールの問題を排除できます。まず、gcloud ツールを使用してインスタンスの外部 natIP を取得します。
gcloud compute instances describe example-instance --format='get(networkInterfaces[0].accessConfigs[0].natIP)'
198.51.100.8
nc コマンドを使用してインスタンスに接続します。
# Check for SSH banner user@local:~$ nc [EXTERNAL_IP] 22 SSH-2.0-OpenSSH_6.0p1 Debian-4
新しいユーザーで試してみる
インスタンスにログインできない場合は、そのアカウントだけの問題である可能性があります（インスタンスの ~/.ssh/authorized_keys ファイルの権限が正しく設定されていない場合など）。
SSH リクエストで別のユーザー名を指定して、gcloud ツールで新規ユーザーとしてログインしてみてください。gcloud ツールはプロジェクトのメタデータを更新して新しいユーザーを追加し、SSH アクセスを許可します。
user@local:~$ gcloud compute ssh [USER]@example-instance
ここで、[USER] はログインするための新しいユーザー名です。
ディスクを新しいインスタンスで使用する
これまでの手順で問題が解決しない場合、目的のインスタンスが永続ディスクから起動していれば、その永続ディスクを接続解除して、新しいインスタンスに接続して使用します。次の例の DISK をお使いのディスクのディスク名に置き換えてください。
gcloud compute instances delete old-instance --keep-disks=boot
gcloud compute instances create new-instance --disk name=DISK,boot=yes,auto-delete=no
gcloud compute ssh new-instance
インスタンスをシャットダウンせずに検査する
接続できないインスタンスで本番環境トラフィックが正常に処理されている場合もあります。その場合は、ユーザーにサービスを提供するインスタンスの機能を中断させずにディスクを検査できます。まず、インスタンスのブートディスクのスナップショットを作成して、そのスナップショットから新しいディスクを作成します。次に、一時インスタンスを作成し、その一時インスタンスに新しい永続ディスクを接続およびマウントして、ディスクのトラブルシューティングを行います。
-
クローン インスタンスをホストする新しい VPC ネットワークを作成します。
gcloud compute networks create debug-network -
SSH 接続を許可するファイアウォール ルールをそのネットワークに追加します。
gcloud compute firewall-rules create debug-network-allow-ssh --allow tcp:22 -
問題のディスクのスナップショットを作成します。
DISKをそのディスクの名前に置き換えてください。gcloud compute disks snapshot DISK --snapshot-name debug-disk-snapshot -
作成したスナップショットを使用して新しいディスクを作成します。
gcloud compute disks create example-disk-debugging --source-snapshot debug-disk-snapshot -
外部 IP アドレスを持たない新しいデバッグ インスタンスを作成します。
gcloud compute instances create debugger --network debug-network --no-address -
そのインスタンスにデバッグ ディスクを接続します。
gcloud compute instances attach-disk debugger --disk example-disk-debugging -
外部 IP アドレスを持たないインスタンスへの接続の手順に従います。
-
デバッグ インスタンスにログインしたら、そのインスタンスのトラブルシューティングを行います。たとえば、インスタンスのログを確認することができます。
$ sudo su -$ mkdir /mnt/myinstance$ mount /dev/disk/by-id/scsi-0Google_PersistentDisk_example-disk-debugging /mnt/myinstance$ cd /mnt/myinstance/var/log# Identify the issue preventing ssh from working $ ls
起動スクリプトを使用する
これまでの手順で問題が解決しない場合は、起動スクリプトを作成してインスタンスの起動直後の情報を収集できます。起動スクリプトの実行の手順に従ってください。
その後、gcloud compute instances reset を使用して、メタデータが有効になる前にインスタンスをリセットする必要もあります。代わりに、診断用起動スクリプトを使用してインスタンスを再作成することもできます。
-
--keep-disksフラグを設定してgcloud compute instances deleteを実行します。gcloud compute instances delete INSTANCE --keep-disks boot -
同じディスクを使用して新しいインスタンスを追加し、起動スクリプトを指定します。
gcloud compute instances create example-instance --disk name=DISK,boot=yes --startup-script-url URL
最初に compute-ssh-diagnostic スクリプトを使用すると、ほとんどの一般的な問題の診断情報を収集できます。
