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

Compute Engine インスタンスで SSH 接続が拒否される理由はさまざまです。SSH 接続の問題は、一般的に次のような原因により発生します。

  • インスタンスで OS ログインが有効になっている。メタデータベースの SSH 認証鍵と OS ログインの両方を使用してインスタンスに接続することはできません。OS Login が有効になっている場合、OS ログインで SSH 認証鍵が承認済み鍵ファイルに保存されないため、メタデータ ベースの SSH 認証鍵による接続が無効になります。
  • OS Login が有効になっていない。OS ログインが有効のとき、Google がメタデータの SSH 認証鍵に基づいて新しいユーザー アカウントの承認済み鍵ファイルを管理します。Compute Engine インスタンスが、ユーザー アカウントの一部として構成された SSH 認証鍵を使用した SSH 接続を受け付けなくなる。
    • 公開イメージでは、SSH パスワードによるログインが無効になっています。
    • アカウント デーモンはゲスト内のファイルを保管して、Google により管理されるユーザー アカウントの状態を維持します。
    • メタデータからユーザー アカウントのすべての SSH 認証鍵を削除すると、Google が管理するユーザー アカウントの承認済みの鍵ファイルが削除されます。
    • アカウント デーモンは、Google が管理していないユーザー アカウントを変更しません。
  • インスタンスのディスクに空き容量がない。ディスク容量を確認して、必要に応じてクリーンアップしてください。
  • sshd デーモンが正しく構成されていない。オペレーティング システムのユーザーガイドを参照して、ssh_d ファイルが正しく設定されていることを確認します。

このトピックでは、SSH に関する一般的な問題とその解決方法について説明します。

要件

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

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

接続のテスト

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

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

Compute Engine では、SSH トラフィックを許可するファイアウォール ルールのデフォルト セットが各プロジェクトに用意されます。インスタンスにアクセスできない場合は、gcloud compute コマンドライン ツールでファイアウォールのリストを確認し、default-allow-ssh ルールがあることを確認します。

ローカル ワークステーションで、次のコマンドを実行します。

gcloud compute firewall-rules list

このファイアウォール ルールがない場合は、追加し直してください。

gcloud compute firewall-rules create default-allow-ssh --allow tcp:22

プロジェクトの default-allow-ssh ファイアウォール ルールに関連付けられたすべてのデータを表示するには、gcloud compute firewall-rules describe コマンドを使用します。

gcloud compute firewall-rules describe default-allow-ssh --project

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

ネットワーク接続が機能しているかどうか確認するには、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 コマンドを実行してインスタンスとのネットワーク接続をテストします。external-ip をインスタンスの外部 IP に置き換えてください。

    nmap external-ip
    

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

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

gcloud compute ssh another-username@$PROB_INSTANCE

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

シリアル コンソールのログを見て接続エラーがないか調べることをおすすめします。シリアル コンソールには、ローカル ワークステーションからブラウザを使用してアクセスします。

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

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

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

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

ディスクを検査してトラブルシューティングするには:

  1. ディスクのスナップショットを作成して、ブートディスクをバックアップします。
  2. スナップショットから通常の永続ディスクを作成します。
  3. 一時インスタンスを作成します。
  4. 通常の永続ディスクを新しい一時インスタンスに接続し、マウントします。

この手順では、SSH 接続のみが許可される隔離ネットワークを作成します。これにより、クローン インスタンスが本番環境のサービスに干渉して予期しない結果を引き起こすのを防ぐことができます。

  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-names 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. gcloud compute instances delete--keep-disks フラグを指定して実行します。

    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