SSH のトラブルシューティング

一定の条件下で、Google Compute Engine インスタンスが SSH 接続を受け付けなくなることがあります。この問題には多くの理由が考えられます。SSH 接続の問題で一般的な原因としては、次のようなものがあります。

  • インスタンスのディスクに空き容量がない。ディスク容量を確認して、必要に応じてクリーンアップします。
  • sshd デーモンが正しく構成されていない。オペレーティング システムのユーザーガイドを参照して、ssh_d が正しく設定されていることを確認します。
  • インスタンスで OS ログインが有効になっている。インスタンスとの接続で SSH 認証鍵と OS ログインを併用することはできません。OS ログインが有効になっている場合、メタデータ ベースの SSH 認証鍵による接続が無効になります。

このトピックでは、一般的な SSH の問題のトラブルシューティング、解決へのヒントとその方法をいくつかご紹介します。

要件

大半のトラブルシューティングは、ローカルのワークステーションで行うことができます。ローカルの Linux または Windows ワークステーションを使用して VM インスタンスのトラブルシューティングを行う場合は、ワークステーションの準備を行う必要があります。

以下の手順でワークステーションを準備します。

  • gcloud コマンドライン ツールの最新バージョンをインストールするか、最新バージョンに更新します。
  • オペレーティング システム用の nmap ネットワーク検出 / セキュリティ監査ツールをインストールします。このツールを使用して、ネットワークと VM インスタンスとのネットワーク接続をテストします。
  • 環境変数を設定します。

環境変数を設定する

トラブルシューティング ガイドで頻繁に使用される可能性があるパラメータを環境変数に設定します。これにより、影響を受けるインスタンスの名前や永続ブートディスクなどの情報を取得できます。

ローカル ワークステーションに環境変数を設定します。

Linux または macOS

Linux または macOS ワークステーションの場合、export コマンドを使用します。

export PROB_INSTANCE='[INSTANCE_NAME]'
export BOOT_DISK='[BOOT_DISK_NAME]'

ここで

  • [INSTANCE_NAME] は、トラブルシューティングを行うインスタンスの名前です。
  • [BOOT_DISK_NAME] は、トラブルシューティングを行うインスタンスの永続ブートディスクの名前です。

たとえば、インスタンス名が instance1 で、ブートディスクの名前が disk1 の場合、次のコマンドを実行します。

export PROB_INSTANCE='instance1'
export BOOT_DISK='disk1'

Windows

Windows OS の場合、set コマンドを使用します。

set PROB_INSTANCE='[INSTANCE_NAME]'
set BOOT_DISK='[BOOT_DISK_NAME]'

ここで

  • [INSTANCE_NAME] は、トラブルシューティングを行うインスタンスの名前です。
  • [BOOT_DISK_NAME] は、トラブルシューティングを行うインスタンスの永続ブートディスクの名前です。

たとえば、インスタンス名が instance1 で、ブートディスクの名前が disk1 の場合、次のコマンドを実行します。

set PROB_INSTANCE='instance1'
set BOOT_DISK='disk1'

接続のテスト

ファイアウォール、ネットワーク接続またはユーザー アカウントに関する接続問題が原因で、SSH で VM インスタンスに接続できないこともあります。このセクションで説明する手順に沿って、接続の問題を特定してください。

ファイアウォール ルールを確認する

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

ネットワーク接続をテストする

nmap ツールを使用して、インスタンスのポート 22 に接続し、ネットワーク接続が機能していることを確認します。接続後に「22/tcp open ssh」というエラー メッセージが表示された場合、ファイアウォールの問題を排除できます。

  1. gcloud ツールを使用してインスタンスの外部 natIP を取得します。

    gcloud compute instances describe $PROB_INSTANCE --format='get(networkInterfaces[0].accessConfigs[0].natIP)'
198.51.100.1

  2. インスタンスとのネットワーク接続をテストします。

    nmap コマンドを実行して、インスタンスとのネットワーク接続をテストします。

    nmap [EXTERNAL_IP]

    [EXTERNAL_IP] は、インスタンスの外部 IP です。

    たとえば、インスタンスの外部 IP が 198.51.100.1 の場合、次のコマンドを実行します。

    user@local:~$  nmap 198.51.100.1

Starting Nmap 7.70 ( https://nmap.org ) at 2019-03-18 16:04 Greenwich Standard Time
Nmap scan report for 229.30.196.35.bc.googleusercontent.com (198.51.100.1)
Host is up (0.0061s latency).
Not shown: 998 filtered ports
PORT     STATE  SERVICE
22/tcp   open   ssh
Nmap done: 1 IP address (1 host up) scanned in 6.22 seconds

別のユーザーとして接続する

ログインできない問題の原因がアカウントにある可能性もあります。たとえば、インスタンスの ~/.ssh/authorized_keys ファイルに対する権限が正しく設定されていない可能性があります。

SSH リクエストで別のユーザー名を指定して、gcloud ツールで別のユーザーとしてログインしてみてください。gcloud ツールはプロジェクトのメタデータを更新して新しいユーザーを追加し、SSH アクセスを許可します。

user@local:~$ gcloud compute ssh [USER]@$PROB_INSTANCE

ここで、[USER] はログインするための新しいユーザー名です。

シリアル コンソールで問題をデバッグする

シリアル コンソールでログを確認すると、接続エラーが見つかる場合があります。シリアル コンソールには、ローカル ワークステーションのブラウザからアクセスできます。

インスタンスのシリアル コンソールへの読み取り / 書き込みアクセスを有効にして、コンソールにログインし、インスタンスの問題をトラブルシューティングできます。これは、SSH を使用してログインできない場合や、インスタンスがネットワークに接続していない場合に特に便利です。どちらの状況でも、シリアル コンソールには引き続きアクセスできます。

インタラクティブ アクセスを有効にして、インスタンスのシリアル コンソールに接続する方法については、シリアル コンソールとのやり取りをご覧ください。

VM インスタンスをシャットダウンせずに検査する

接続できないインスタンスで本番環境トラフィックが正常に処理されている場合もあります。その場合、インスタンスを中断させずにディスクを検査できます。

インスタンスを検査するには、ブートディスクのスナップショットを取得し、そのスナップショットから新しいディスクを作成します。さらに一時インスタンスを作成します。このインスタンスに新しい永続ディスクを接続してマウントし、ディスクのトラブルシューティングを行います。

  1. クローン インスタンスをホストする新しい VPC ネットワークを作成します。

    gcloud compute networks create debug-network

  2. SSH 接続を許可するファイアウォール ルールをそのネットワークに追加します。

    gcloud compute firewall-rules create debug-network-allow-ssh --allow tcp:22

  3. ブートディスクのスナップショットを作成します。

    gcloud compute disks snapshot $BOOT_DISK --snapshot-name debug-disk-snapshot

  4. 作成したスナップショットを使用して新しいディスクを作成します。

    gcloud compute disks create example-disk-debugging --source-snapshot debug-disk-snapshot

  5. 外部 IP アドレスを持たない新しいデバッグ インスタンスを作成します。

    gcloud compute instances create debugger --network debug-network --no-address

  6. そのインスタンスにデバッグ ディスクを接続します。

    gcloud compute instances attach-disk debugger --disk example-disk-debugging

  7. 外部 IP アドレスを持たないインスタンスへの接続の手順に従います。

  8. デバッグ インスタンスにログインしたら、そのインスタンスのトラブルシューティングを行います。たとえば、インスタンスのログを確認できます。

    $ sudo su -

    $ mkdir /mnt/$PROB_INSTANCE

    $ mount /dev/disk/by-id/scsi-0Google_PersistentDisk_example-disk-debugging /mnt/$PROB_INSTANCE

    $ cd /mnt/$PROB_INSTANCE/var/log

    # Identify the issue preventing ssh from working
$ ls

起動スクリプトを使用する

これまでの手順で問題が解決しない場合は、起動スクリプトを作成してインスタンスの起動直後の情報を収集できます。起動スクリプトの実行の手順に従ってください。

その後、gcloud compute instances reset を使用して、メタデータが有効になる前にインスタンスをリセットする必要もあります。代わりに、診断用起動スクリプトを使用してインスタンスを再作成することもできます。

  1. --keep-disks フラグを設定して gcloud compute instances delete を実行します。

    gcloud compute instances delete $PROB_INSTANCE --keep-disks boot

  2. 同じディスクを使用して新しいインスタンスを追加し、起動スクリプトを指定します。

    gcloud compute instances create new-instance --disk name=$BOOT_DISK,boot=yes --startup-script-url URL

最初に compute-ssh-diagnostic スクリプトを使用すると、ほとんどの一般的な問題の診断情報を収集できます。

ディスクを新しいインスタンスで使用する

このドキュメントで説明した手順で問題が解決せず、永続ブートディスクからデータを復元する必要ある場合は、ブートディスクの接続を解除して、新しいインスタンスに別のディスクとして接続します。

gcloud compute instances delete $PROB_INSTANCE --keep-disks=boot

gcloud compute instances create new-instance --disk name=$BOOT_DISK,boot=yes,auto-delete=no

gcloud compute ssh new-instance
このページは役立ちましたか？評価をお願いいたします。

フィードバックを送信...

このページ
ドキュメントのフィードバック
Compute Engine ドキュメント
サービスのフィードバック