このドキュメントでは、SSH を使用して仮想マシン（VM）インスタンスに接続するときに発生する可能性がある一般的なエラーとその解決方法、失敗した SSH 接続の診断方法について説明します。
SSH のトラブルシューティング ツール
SSH トラブルシューティング ツールを使用して、SSH 接続に失敗した原因を特定できます。トラブルシューティング ツールは、次のテストを実行して SSH 接続の失敗の原因を確認します。
- ユーザー権限テスト: SSH を使用して VM に接続するために必要な IAM 権限があるかどうかを確認します。
- ネットワーク接続性テスト: VM がネットワークに接続されているかどうかを確認します。
- VM インスタンスのステータス テスト: VM の CPU ステータスをチェックして、VM が実行中かどうかを確認します。
- VPC 設定テスト: デフォルトの SSH ポートを確認します。
トラブルシューティング ツールを実行する
Google Cloud コンソールまたは Google Cloud CLI を使用して、SSH 接続の失敗の原因となるネットワークの問題とユーザー権限のエラーを確認できます。
コンソール
SSH 接続が失敗した場合は、接続を再試行するか、ブラウザ内の SSH トラブルシューティング ツールを使用して接続をトラブルシューティングします。
トラブルシューティング ツールを実行するには、[トラブルシューティング] をクリックします。
gcloud
トラブルシューティング ツールを実行するには、gcloud compute ssh コマンドを使用します。
gcloud compute ssh VM_NAME \
--troubleshoot
VM_NAME は、接続に失敗した VM の名前に置き換えます。
トラブルシューティング テストの実行権限を付与するように求められます。
結果を確認する
トラブルシューティング ツールを実行した後、以下を行います。
- テスト結果を確認して、VM の SSH 接続が機能しない理由を特定します。
- ツールから指示される修復手順に沿って SSH 接続の問題を解決します。
VM への再接続を試行します。
接続が成功しない場合は、次の手順に沿って手動でトラブルシューティングを試します。
一般的な SSH エラー
SSH を使用して Compute Engine VM に接続するときに発生する一般的なエラーの例を次に示します。
ブラウザでの SSH エラー
Unauthorized Error 401
Google Cloud コンソールで、ブラウザからの SSH を使用して VM に接続すると、次のエラーが発生する可能性があります。
Unauthorized Error 401
このエラーは、ユーザーが Google Workspace 内から管理されている組織に属しており、ユーザーがブラウザからの SSH と Google Cloud 内のシリアル コンソールにアクセスできないように制限する Workspace ポリシーが有効になっている場合に発生します。
この問題を解決するには、次の操作を行うよう Google Workspace 管理者に依頼します。
組織で Google Cloud が有効になっていることを確認します。
Google Cloud が無効になっている場合は、有効にしてから接続を再試行します。
個別に制御されていないサービスが有効になっていることを確認します。
これらのサービスが無効になっている場合は、有効にしてから接続を再試行します。
Google Workspace で Google Cloud の設定を有効にしても問題が解決しない場合は、次の操作を行います。
ブラウザからの SSH 接続を開始してからのネットワーク トラフィックをキャプチャし、HTTP Archive 形式（HAR）ファイルに保存します。
Cloud カスタマーケアでケースを作成して、HAR ファイルを送信します。
Could Not Connect, Retrying...
SSH セッションを開始すると、次のエラーが発生することがあります。
Could not connect, retrying ...
この問題を解決するには、次の操作を行います。
VM の起動が完了したら、接続を再試行します。接続が成功しない場合は、次のコマンドを実行して、VM が緊急モードで起動していないことを確認します。
gcloud compute instances get-serial-port-output VM_NAME \ | grep "emergency mode"
VM が緊急モードで起動している場合は、VM の起動のトラブルシューティングを行い、起動プロセスが失敗する場所を特定します。
シリアル コンソールで次のコマンドを実行して、
google-guest-agent.serviceサービスが実行されていることを確認します。systemctl status google-guest-agent.service
サービスが無効になっている場合は、次のコマンドを実行し、サービスを有効にして開始します。
systemctl enable google-guest-agent.service systemctl start google-guest-agent.service
Linux Google エージェント スクリプトがインストールされ、実行されていることを確認します。詳しくは、Google エージェントのステータスの確認をご覧ください。Linux Google エージェントがインストールされていない場合は、再インストールします。
VM への接続に必要なロールがあることを確認します。VM で OS Login を使用している場合は、OS Login の IAM ロールを割り当てるをご覧ください。VM で OS Login を使用していない場合は、コンピューティング インスタンス管理者ロールまたはサービス アカウント ユーザーロール（VM がサービス アカウントとして実行されるように設定している場合）が必要です。このロールは、インスタンスまたはプロジェクトの SSH 認証鍵メタデータを更新するために必要です。
次のコマンドを実行して、SSH アクセスを許可するファイアウォール ルールがあることを確認します。
gcloud compute firewall-rules list | grep "tcp:22"
インターネット（または踏み台インスタンス）へのデフォルト ルートがあることを確認します。詳細については、ルートの確認をご覧ください。
ルート ボリュームでディスク容量が不足していないことを確認します。詳細については、ディスクの容量不足とディスクサイズ変更のトラブルシューティングをご覧ください。
次のコマンドを実行して、VM でメモリが不足していないことを確認します。
gcloud compute instances get-serial-port-output instance-name \ | grep "Out of memory: Kill process" - e "Kill process" -e "Memory cgroup out of memory" -e "oom"
VM のメモリが不足している場合は、シリアル コンソールに接続してトラブルシューティングを行います。
Linux でのエラー
権限拒否（公開鍵）
VM に接続すると、次のエラーが発生することがあります。
USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).
このエラーは、いくつかの原因で発生します。このエラーの最も一般的な原因は次のとおりです。
メタデータに保存されている SSH 認証鍵を使用して、OS Login が有効になっている VM に接続した。プロジェクトで OS Login が有効になっている場合、VM はメタデータに保存されている SSH 認証鍵を受け入れません。OS Login が有効かどうかわからない場合は、OS Login が構成されているかどうかの確認をご覧ください。
この問題を解決するには、以下のいずれかを試します。
- Google Cloud コンソールまたは Google Cloud CLI を使用して VM に接続します。詳細については、VM への接続をご覧ください。
- SSH 認証鍵を OS Login に追加します。詳細については、OS Login を使用する VM への鍵の追加をご覧ください。
- OS Login を無効にします。詳細については、OS Login を無効にするをご覧ください。
OS Login プロファイルに保存されている SSH 認証鍵を使用して、OS Login が有効になっていない VM に接続した。OS Login を無効にすると、VM は OS Login プロファイルに保存されている SSH 認証鍵を受け入れません。OS Login が有効かどうかわからない場合は、OS Login が構成されているかどうかの確認をご覧ください。
この問題を解決するには、以下のいずれかを試します。
- Google Cloud コンソールまたは Google Cloud CLI を使用して VM に接続します。詳細については、VM への接続をご覧ください。
- OS Login を有効にします。詳細については、OS Login を有効にするをご覧ください。
- SSH 認証鍵をメタデータに追加します。詳細については、メタデータ ベースの SSH 認証鍵を使用する VM に SSH 認証鍵を追加するをご覧ください。
VM で OS Login が有効になっているが、OS Login を使用するための十分な IAM 権限が付与されていない。OS Login が有効になっている VM に接続するには、OS Login に必要な権限を付与されていることが必要です。OS Login が有効かどうかわからない場合は、OS Login が構成されているかどうかの確認をご覧ください。
この問題を解決するには、OS Login に必要な IAM ロールを付与します。
鍵の有効期限が切れ、Compute Engine によって
~/.ssh/authorized_keysファイルが削除された。VM に手動で SSH 認証鍵を追加し、Google Cloud Console を使用して VM に接続した場合、Compute Engine は接続用に新しい鍵ペアを作成します。新しい鍵ペアが期限切れになると、手動で追加した SSH 認証鍵が含まれる~/.ssh/authorized_keysファイルが Compute Engine によって VM から削除されます。この問題を解決するには、以下のいずれかを試します。
- Google Cloud コンソールまたは Google Cloud CLI を使用して VM に接続します。詳細については、VM への接続をご覧ください。
- SSH 認証鍵をメタデータに再度追加します。詳細については、メタデータ ベースの SSH 認証鍵を使用する VM に SSH 認証鍵を追加するをご覧ください。
サードパーティ ツールで接続を試みたが、SSH コマンドが正しく構成されていない。
sshコマンドを使用して接続するときに秘密鍵のパスを指定しなかったか、無効なパスを指定した場合、VM は接続を拒否します。この問題を解決するには、以下のいずれかを試します。
- 次のコマンドを実行します。
ssh -i PATH_TO_PRIVATE_KEY USERNAME@EXTERNAL_IP
次のように置き換えます。PATH_TO_PRIVATE_KEY: SSH 秘密鍵ファイルのパス。USERNAME: インスタンスに接続するユーザーのユーザー名。メタデータで SSH 認証鍵を管理している場合、ユーザー名は SSH 認証鍵の作成時に指定したユーザー名になります。OS Login アカウントの場合、ユーザー名は Google プロフィールに定義されています。EXTERNAL_IP: VM の外部 IP アドレス。
- Google Cloud コンソールまたは Google Cloud CLI を使用して VM に接続します。これらのツールを使用して接続する場合、Compute Engine が鍵の作成を管理します。詳細については、VM への接続をご覧ください。
- 次のコマンドを実行します。
VM のゲスト環境が実行されていない。VM に初めて接続し、ゲスト環境が実行されていない場合、VM によって SSH 接続リクエストが拒否されることがあります。
この問題を解決するには、次の操作を行います。
- VM を再起動します。
- Google Cloud コンソールで、シリアルポート出力のシステム起動ログを調べて、ゲスト環境が実行されているかどうかを確認します。詳細については、ゲスト環境を検証するをご覧ください。
- ゲスト環境が実行されていない場合は、VM のブートディスクのクローンを作成し、起動スクリプトを使用してゲスト環境を手動でインストールします。
OpenSSH Daemon（
sshd）が実行されていないか、正しく構成されていない。sshdは、SSH プロトコル経由でシステムへの安全なリモート アクセスを提供します。構成が誤っているか実行されていない場合、SSH 経由で VM に接続できません。この問題を解決するには、次の対処方法をいくつか試してください。
オペレーティング システムのユーザーガイドを参照して、
sshd_configが正しく設定されていることを確認します。以下のオーナー権限と権限が設定されていることを確認します。
$HOMEと$HOME/.sshディレクトリ$HOME/.ssh/authorized_keysファイル
オーナー権限
ゲスト環境では、承認済みの SSH 公開鍵が
$HOME/.ssh/authorized_keysファイルに保存されます。$HOMEディレクトリ、$HOME/.sshディレクトリ、$HOME/.ssh/authorized_keysファイルのオーナーは、VM に接続するユーザーと同じである必要があります。権限
ゲスト環境には、次の Linux 権限が必要です。
パス 権限 /home0755$HOME0700または0750または0755*$HOME/.ssh0700$HOME/.ssh/authorized_keys0600* どのオプションが
$HOMEディレクトリの適切なデフォルト権限であるかを確認するには、ご使用の Linux ディストリビューションの公式ドキュメントをご覧ください。。
また、同じイメージに基づいて新しい VM を作成し、
$HOMEのデフォルトの権限を確認することもできます。次のコマンドを実行して
sshdを再起動します。systemctl restart sshd.service次のコマンドを実行して、ステータスにエラーがあるかどうかを確認します。
systemctl status sshd.serviceステータスの出力には、終了コードや失敗の理由などの情報が含まれていることがあります。これらの詳細情報を使用して、トラブルシューティングをさらに進めることができます。
VM のブートディスクに空き容量がない。SSH 接続が確立されると、ゲスト環境でセッションの公開 SSH 認証鍵が
~/.ssh/authorized_keysファイルに追加されます。ディスクがいっぱいの場合は、接続に失敗します。この問題を解決するには、次の対処方法をいくつか試してください。
- シリアル コンソールでデバッグして
no space left errorsを特定し、ブートディスクに空き容量がないことを確認します。 - ディスクのサイズを変更します。
- どのファイルがディスク容量を消費しているかわかっている場合は、不要なファイルを削除して容量を確保する起動スクリプトを作成します。VM が起動され、VM に接続してから、
startup-scriptメタデータを削除します。
- シリアル コンソールでデバッグして
$HOME、$HOME/.ssh、$HOME/.ssh/authorized_keysの権限またはオーナー権限が間違っている。オーナー権限
ゲスト環境では、承認済みの SSH 公開鍵が
$HOME/.ssh/authorized_keysファイルに保存されます。$HOMEディレクトリ、$HOME/.sshディレクトリ、$HOME/.ssh/authorized_keysファイルのオーナーは、VM に接続するユーザーと同じである必要があります。権限
ゲスト環境には、次の Linux 権限が必要です。
パス 権限 /home0755$HOME0700または0750または0755*$HOME/.ssh0700$HOME/.ssh/authorized_keys0600* どのオプションが
$HOMEディレクトリの適切なデフォルト権限であるかを確認するには、ご使用の Linux ディストリビューションの公式ドキュメントをご覧ください。。
また、同じイメージに基づいて新しい VM を作成し、
$HOMEのデフォルトの権限を確認することもできます。
接続できませんでした
Google Cloud コンソール、gcloud CLI、踏み台インスタンス、ローカル クライアントから VM に接続すると、次のエラーが発生することがあります。
Google Cloud コンソール:
Connection Failed We are unable to connect to the VM on port 22.
gcloud CLI:
ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].
踏み台インスタンスまたはローカル クライアント:
port 22: Connection timed out.
port 22: Connection refused
こうしたエラーは、いくつかの理由で発生することがあります。このエラーの最も一般的な原因は次のとおりです。
VM の起動中で、
sshdがまだ実行されていない。 実行前に VM に接続することはできません。この問題を解決するには、VM の起動が完了してからもう一度接続してみてください。
sshdがカスタムポートで実行されている。ポート 22 以外のポートで実行するようにsshdを構成した場合、VM に接続できません。この問題を解決するには、次のコマンドを使用して、
sshdが実行されているポートでtcpトラフィックを許可するカスタム ファイアウォール ルールを作成します。gcloud compute firewall-rules create FIREWALL_NAME \ --allow tcp:PORT_NUMBER
カスタム ファイアウォール ルールを作成する方法については、ファイアウォール ルールの作成をご覧ください。
SSH ファイアウォール ルールがないか、IAP または公共のインターネットからのトラフィックが許可されていない。ファイアウォール ルールで、IAP または IP 範囲
0.0.0.0/0の TCP 上り（内向き）トラフィックからの接続が許可されていない場合、SSH 接続は拒否されます。この問題を解決するには、以下のいずれかを行います。
TCP 転送に Identity-Aware Proxy（IAP）を使用する場合は、IAP からのトラフィックを受け入れるようにカスタム ファイアウォール ルールを更新して、IAM 権限を確認します。
- カスタム ファイアウォール ルールを更新して、
35.235.240.0/20（IAP が TCP 転送に使用する IP アドレス範囲）からのトラフィックを許可します。詳細については、ファイアウォール ルールを作成するをご覧ください。 - IAP TCP 転送の使用権限を付与します（まだ付与していない場合）。
- カスタム ファイアウォール ルールを更新して、
IAP を使用しない場合は、上り（内向き）SSH トラフィックを許可するようにカスタム ファイアウォール ルールを更新します。
- カスタム ファイアウォール ルールを更新して、VM への上り（内向き）SSH 接続を許可します。
VM のカーネルをアップグレードした後に SSH 接続に失敗する。カーネルの更新後に VM にカーネル パニックが発生し、VM にアクセスできなくなる場合があります。
この問題を解決するには、次の手順を行います。
- 別の VM にディスクをマウントします。
- 以前のバージョンのカーネルを使用するように
grub.cfgファイルを更新します。 - 応答しない VM にディスクをアタッチします。
gcloud compute instances describeコマンドを使用して、VM のステータスがRUNNINGであることを確認します。- カーネルを再インストールします。
- VM を再起動します。
VM をアップグレードする前にブートディスクのスナップショットを作成した場合は、スナップショットを使用して VM を作成します。
OpenSSH Daemon（
sshd）が実行されていないか、正しく構成されていない。sshdは、SSH プロトコル経由でシステムへの安全なリモート アクセスを提供します。構成が誤っているか実行されていない場合、SSH 経由で VM に接続できません。この問題を解決するには、次の対処方法をいくつか試してください。
オペレーティング システムのユーザーガイドを参照して、
sshd_configが正しく設定されていることを確認します。以下のオーナー権限と権限が設定されていることを確認します。
$HOMEと$HOME/.sshディレクトリ$HOME/.ssh/authorized_keysファイル
オーナー権限
ゲスト環境では、承認済みの SSH 公開鍵が
$HOME/.ssh/authorized_keysファイルに保存されます。$HOMEディレクトリ、$HOME/.sshディレクトリ、$HOME/.ssh/authorized_keysファイルのオーナーは、VM に接続するユーザーと同じである必要があります。権限
ゲスト環境には、次の Linux 権限が必要です。
パス 権限 /home0755$HOME0700または0750または0755*$HOME/.ssh0700$HOME/.ssh/authorized_keys0600* どのオプションが
$HOMEディレクトリの適切なデフォルト権限であるかを確認するには、ご使用の Linux ディストリビューションの公式ドキュメントをご覧ください。。
また、同じイメージに基づいて新しい VM を作成し、
$HOMEのデフォルトの権限を確認することもできます。次のコマンドを実行して
sshdを再起動します。systemctl restart sshd.service次のコマンドを実行して、ステータスにエラーがあるかどうかを確認します。
systemctl status sshd.serviceステータスの出力には、終了コードや失敗の理由などの情報が含まれていることがあります。これらの詳細情報を使用して、トラブルシューティングをさらに進めることができます。
VM が起動せず、SSH またはシリアル コンソールで接続できない。VM にアクセスできない場合は、OS が破損している可能性があります。ブートディスクが起動しない場合は、問題を診断できます。破損した VM を復元してデータを取得する場合は、破損した VM または完全なブートディスクの復元をご覧ください。
VM がメンテナンス モードで起動している。メンテナンス モードで起動している場合、VM は SSH 接続を受け入れません。ただし、VM のシリアル コンソールに接続して、root ユーザーとしてログインできます。
この問題を解決するには、次の手順を行います。
VM の root パスワードを設定していない場合は、メタデータ起動スクリプトを使用して起動時に次のコマンドを実行します。
echo "root:NEW_PASSWORD" | chpasswd
NEW_PASSWORD は任意のパスワードに置き換えてください。
VM を再起動します。
VM のシリアル コンソールに接続して、root ユーザーとしてログインします。
予期しないエラー
Linux VM に接続しようとすると、次のエラーが発生することがあります。
Connection Failed You cannot connect to the VM instance because of an unexpected error. Wait a few moments and then try again.
この問題は、さまざまな理由で発生する可能性があります。エラーの一般的な原因は次のとおりです。
-
OpenSSH Daemon（
sshd）が実行されていないか、正しく構成されていない。sshdは、SSH プロトコル経由でシステムへの安全なリモート アクセスを提供します。構成が誤っているか実行されていない場合、SSH 経由で VM に接続できません。この問題を解決するには、次の対処方法をいくつか試してください。
オペレーティング システムのユーザーガイドを参照して、
sshd_configが正しく設定されていることを確認します。以下のオーナー権限と権限が設定されていることを確認します。
$HOMEと$HOME/.sshディレクトリ$HOME/.ssh/authorized_keysファイル
オーナー権限
ゲスト環境では、承認済みの SSH 公開鍵が
$HOME/.ssh/authorized_keysファイルに保存されます。$HOMEディレクトリ、$HOME/.sshディレクトリ、$HOME/.ssh/authorized_keysファイルのオーナーは、VM に接続するユーザーと同じである必要があります。権限
ゲスト環境には、次の Linux 権限が必要です。
パス 権限 /home0755$HOME0700または0750または0755*$HOME/.ssh0700$HOME/.ssh/authorized_keys0600* どのオプションが
$HOMEディレクトリの適切なデフォルト権限であるかを確認するには、ご使用の Linux ディストリビューションの公式ドキュメントをご覧ください。。
また、同じイメージに基づいて新しい VM を作成し、
$HOMEのデフォルトの権限を確認することもできます。次のコマンドを実行して
sshdを再起動します。systemctl restart sshd.service次のコマンドを実行して、ステータスにエラーがあるかどうかを確認します。
systemctl status sshd.serviceステータスの出力には、終了コードや失敗の理由などの情報が含まれていることがあります。これらの詳細情報を使用して、トラブルシューティングをさらに進めることができます。
SSH デーモンに関する不明な問題。SSH デーモンに関する不明な問題を診断するには、シリアル コンソールのログでエラーを確認します。
シリアル コンソールのログの出力に応じて、次の手順で VM をレスキューし、SSH デーモン関連の問題を修正します。
- 別の Linux VM にディスクをアタッチします。
- ディスクがマウントされている VM に接続します。
- VM 内のディレクトリ MOUNT_DIR に OS 内のディスクをマウントします。
- SSH 関連のログ（
/var/log/secureまたは/var/log/auth.log）で問題やエラーを確認します。修正できる問題が見つかった場合は、修正を試みます。それ以外の場合は、サポートケースを作成してログを送信します。 umountコマンドを使用して OS からディスクをマウント解除します。cd ~/ umount /mnt
VM からディスクを切断します。
元の VM にディスクをアタッチします。
VM を起動します。
バックエンドに接続できない
Google Cloud コンソールまたは gcloud CLI から VM に接続すると、次のエラーが発生することがあります。
Google Cloud コンソール:
-- Connection via Cloud Identity-Aware Proxy Failed -- Code: 4003 -- Reason: failed to connect to backend
gcloud CLI:
ERROR: (gcloud.compute.start-iap-tunnel) Error while connecting [4003: 'failed to connect to backend'].
パブリック IP アドレスがなく、ポート 22 で Identity-Aware Proxy が構成されていない VM に SSH で接続すると、このエラーが発生します。
この問題を解決するには、Identity-Aware Proxy からの上り（内向き）トラフィックを許可するポート 22 でファイアウォール ルールを作成します。
ホストキーが一致しない
VM に接続すると、次のエラーが発生することがあります。
Host key for server IP_ADDRESS does not match
このエラーは、~/.ssh/known_hosts ファイル内のホストキーが VM のホストキーと一致していない場合に発生します。
この問題を解決するには、ホストキーを ~/.ssh/known_hosts ファイルから削除して接続を再試行します。
メタデータ値が大きすぎる
新しい SSH 認証鍵をメタデータに追加しようとすると、次のエラーが発生することがあります。
ERROR:"Value for field 'metadata.items[X].value' is too large: maximum size 262144 character(s); actual size NUMBER_OF_CHARACTERS."
メタデータ値には 256 KB の上限があります。この制限を回避するには、次のいずれかを行います。
- 期限切れの SSH 認証鍵または重複している SSH 認証鍵をプロジェクトまたはインスタンスのメタデータから削除します。詳細については、実行中の VM のメタデータを更新するをご覧ください。
- OS Login を使用します。
Windows でのエラー
Permission denied, please try again
VM に接続すると、次のエラーが発生することがあります。
USERNAME@compute.INSTANCE_ID's password: Permission denied, please try again.
このエラーは、VM に接続しようとしているユーザーが VM に存在しないことを示します。このエラーの最も一般的な原因は次のとおりです。
gcloud CLI のバージョンが最新ではない
gcloud CLI が古い場合、構成されていないユーザー名を使用して接続しようとしている可能性があります。この問題を解決するには、gcloud CLI を更新します。
SSH が有効になっていない Windows VM に接続しようとしている。
このエラーを解決するには、プロジェクトまたはインスタンス メタデータで
enable-windows-sshキーをTRUEに設定します。メタデータの設定の詳細については、カスタム メタデータを設定するをご覧ください。
権限拒否（公開鍵、キーボードインタラクティブ）
SSH が有効になっていない VM に接続すると、次のエラーが発生することがあります。
Permission denied (publickey,keyboard-interactive).
このエラーを解決するには、プロジェクトまたはインスタンス メタデータで enable-windows-ssh キーを TRUE に設定します。メタデータの設定の詳細については、カスタム メタデータを設定するをご覧ください。
インスタンスに SSH 接続できない
gcloud CLI から VM に接続すると、次のエラーが発生することがあります。
ERROR: (gcloud.compute.ssh) Could not SSH into the instance. It is possible that your SSH key has not propagated to the instance yet. Try running this command again. If you still cannot connect, verify that the firewall and instance are set to accept ssh traffic.
このエラーは、いくつかの原因で発生します。このエラーの最も一般的な原因は次のとおりです。
SSH がインストールされていない Windows VM に接続しようとしている。
この問題を解決するには、実行中の VM で Windows の SSH を有効にするの手順に沿って操作します。
OpenSSH サーバー（
sshd）が実行されていないか、正しく構成されていない。sshdは、SSH プロトコル経由でシステムへの安全なリモート アクセスを提供します。構成が誤っているか実行されていない場合、SSH 経由で VM に接続できません。この問題を解決するには、Windows Server と Windows の OpenSSH サーバー構成をレビューして
sshdが正しく設定されていることを確認します。
接続がタイムアウトになった
SSH 接続がタイムアウトになった原因としては、次のいずれかが考えられます。
VM の起動がまだ完了していない。VM が起動するまで、しばらくお待ちください。
この問題を解決するには、VM の起動が完了してからもう一度接続してみてください。
SSH パッケージがインストールされていない。Windows VM では、SSH で接続する前に
google-compute-engine-sshパッケージをインストールする必要があります。この問題を解決するには、SSH パッケージをインストールします。
失敗した SSH 接続を診断する
以降のセクションでは、SSH 接続の失敗の原因を診断する手順と、接続を修正するための手順について説明します。
失敗した SSH 接続を診断する前に、次の操作を行います。
- Google Cloud CLI の最新バージョンをインストールするか、最新バージョンに更新します。
- 接続テストを行います。
- ゲスト環境が実行されてないカスタム Linux イメージを使用している場合は、Linux ゲスト環境をインストールします。
- OS Login を使用している場合は、OS Login のトラブルシューティングをご覧ください。
Linux VM と 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=project-id
ファイアウォール ルールの詳細については、Google Cloud のファイアウォール ルールをご覧ください。
ネットワーク接続をテストする
ネットワーク接続が機能しているかどうか確認するには、TCP handshake をテストします。
VM の外部
natIPを取得します。gcloud compute instances describe VM_NAME \ --format='get(networkInterfaces[0].accessConfigs[0].natIP)'VM_NAMEは、接続に失敗した VM の名前に置き換えます。ワークステーションから VM へのネットワーク接続をテストします。
Linux、Windows 2019 / 2022、macOS
curl -vso /dev/null --connect-timeout 5 EXTERNAL_IP:PORT_NUMBER
次のように置き換えます。
EXTERNAL_IP: 前の手順で取得した外部 IP アドレスPORT_NUMBER: ポート番号
TCP handshake が成功した場合、出力は次のようになります。
Expire in 0 ms for 6 (transfer 0x558b3289ffb0) Expire in 5000 ms for 2 (transfer 0x558b3289ffb0) Trying 192.168.0.4... TCP_NODELAY set Expire in 200 ms for 4 (transfer 0x558b3289ffb0) Connected to 192.168.0.4 (192.168.0.4) port 443 (#0) > GET / HTTP/1.1 > Host: 192.168.0.4:443 > User-Agent: curl/7.64.0 > Accept: */* > Empty reply from server Connection #0 to host 192.168.0.4 left intact
Connected to行は、TCP handshake に成功したことを示します。Windows 2012 と 2016
PS C:> New-Object System.Net.Sockets.TcpClient('EXTERNAL_IP',PORT_NUMBER)次のように置き換えます。
EXTERNAL_IP: 前の手順で取得した外部 IPPORT_NUMBER: ポート番号
TCP handshake が成功した場合、出力は次のようになります。
Available : 0 Client : System.Net.Sockets.Socket Connected : True ExclusiveAddressUse : False ReceiveBufferSize : 131072 SendBufferSize : 131072 ReceiveTimeout : 0 SendTimeout : 0 LingerState : System.Net.Sockets.LingerOption NoDelay : False
Connected: True行は、TCP handshake に成功したことを示します。
TCP handshake が正常に完了すると、ソフトウェア ファイアウォール ルールによって接続がブロックされません。OS はパケットを正しく転送し、サーバーが宛先ポートをリッスンします。TCP handshake に成功しても VM が SSH 接続が受け入られない場合は、sshd デーモンが正しく構成されていないか、正しく実行されていない可能性があります。オペレーティング システムのユーザーガイドを参照して、sshd_config が正しく設定されていることを確認します。
2 台の VM 間で VPC ネットワーク パス構成を分析し、プログラムされた構成でトラフィックを許可するかどうかを確認する接続性テストを行うには、Google Cloud で正しく構成されていないファイアウォール ルールを確認するをご覧ください。
別のユーザーとして接続する
ログインできない問題の原因がアカウントにある可能性もあります。たとえば、インスタンスの ~/.ssh/authorized_keys ファイルに対する権限がユーザーにとって正しく設定されていない場合があります。
SSH リクエストで ANOTHER_USERNAME を指定して、gcloud CLI で別のユーザーとしてログインしてみてください。gcloud CLI は、プロジェクトのメタデータを更新して新しいユーザーを追加し、SSH アクセスを許可します。
gcloud compute ssh ANOTHER_USERNAME@VM_NAME
次のように置き換えます。
ANOTHER_USERNAMEは、自分のユーザー名以外のユーザー名です。VM_NAMEは、接続する VM の名前です。
シリアル コンソールを使用して問題をデバッグする
シリアル コンソールのログで接続エラーがないか調べることをおすすめします。シリアル コンソールには、ローカル ワークステーションからブラウザを使用して root ユーザーでアクセスできます。このアプローチは、SSH を使用してログインできない場合や、インスタンスがネットワークに接続していない場合に便利です。どちらの状況でも、シリアル コンソールには引き続きアクセスできます。
VM のシリアル コンソールにログインして、VM に関する問題のトラブルシューティングを行うには、次の手順を行います。
VM のシリアル コンソールへのインタラクティブ アクセスを有効にします。
Linux VM の場合は、root パスワードを変更し、次の起動スクリプトを VM に追加します。
echo root:PASSWORD | chpasswd
PASSWORD は任意のパスワードに置き換えてください。
シリアル コンソールを使用して VM に接続します。
Linux VM の場合は、すべてのエラーのデバッグが完了したら、root アカウントのログインを無効にします。
sudo passwd -l root
Linux VM の診断方法
VM インスタンスをシャットダウンせずに検査する
接続できないインスタンスで本番環境トラフィックが正常に処理されている場合もあります。その場合、インスタンスを中断せずにディスクを検査できます。
ディスクを検査してトラブルシューティングするには:
- ディスクのスナップショットを作成して、ブートディスクをバックアップします。
- スナップショットから通常の永続ディスクを作成します。
- 一時インスタンスを作成します。
- 通常の永続ディスクを新しい一時インスタンスに接続し、マウントします。
この手順では、SSH 接続のみが許可される隔離ネットワークを作成します。これにより、クローン インスタンスが本番環境のサービスに干渉して予期しない結果を引き起こすのを防ぐことができます。
クローン インスタンスをホストする新しい VPC ネットワークを作成します。
gcloud compute networks create debug-network
NETWORK_NAMEは、新しいネットワークの名前で置き換えます。SSH 接続を許可するファイアウォール ルールをそのネットワークに追加します。
gcloud compute firewall-rules create debug-network-allow-ssh \ --network debug-network \ --allow tcp:22
ブートディスクのスナップショットを作成します。
gcloud compute disks snapshot BOOT_DISK_NAME \ --snapshot-names debug-disk-snapshot
BOOT_DISK_NAMEは、ブートディスクの名前に置き換えます。作成したスナップショットを使用して新しいディスクを作成します。
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
踏み台インスタンスを使用して VM に接続するの手順を沿って操作します。
デバッガ インスタンスにログインした後、インスタンスのトラブルシューティングを行います。たとえば、インスタンスのログを確認できます。
sudo su -
mkdir /mnt/VM_NAME
mount /dev/disk/by-id/scsi-0Google_PersistentDisk_example-disk-debugging /mnt/VM_NAME
cd /mnt/VM_NAME/var/log
# Identify the issue preventing ssh from working lsVM_NAMEは、接続に失敗した VM の名前に置き換えます。
起動スクリプトを使用する
前述のいずれにも該当しない場合は、インスタンスが起動したすぐ後に起動スクリプトを作成して情報を収集します。起動スクリプトの実行の手順を行います。
その後、メタデータが有効になる前に、gcloud compute instances reset を使用してインスタンスをリセットする必要もあります。
代わりに、診断用起動スクリプトを実行してインスタンスを再作成することもできます。
gcloud compute instances deleteに--keep-disksフラグを指定して実行します。gcloud compute instances delete VM_NAME \ --keep-disks boot
VM_NAMEは、接続に失敗した VM の名前に置き換えます。同じディスクを使用して新しいインスタンスを追加し、起動スクリプトを指定します。
gcloud compute instances create NEW_VM_NAME \ --disk name=BOOT_DISK_NAME,boot=yes \ --metadata startup-script-url URL
次のように置き換えます。
NEW_VM_NAMEは、作成する新しい VM の名前です。BOOT_DISK_NAMEは、接続できない VM のブートディスクの名前です。URLは、Cloud Storage のスクリプトの URL です（gs://BUCKET/FILEまたはhttps://storage.googleapis.com/BUCKET/FILEの形式）。
ディスクを新しいインスタンスで使用する
永続ブートディスクからデータを復元する必要ある場合は、ブートディスクを切断して、そのディスクをセカンダリ ディスクとして新しいインスタンスにアタッチします。
接続に失敗した VM を削除します。ブートディスクはそのまま残します。
gcloud compute instances delete VM_NAME \ --keep-disks=boot
VM_NAMEは、接続に失敗した VM の名前に置き換えます。古い VM のブートディスクを含む新しい VM を作成します。削除した VM のブートディスクの名前を指定します。
SSH を使用して新しい VM に接続します。
gcloud compute ssh NEW_VM_NAME
NEW_VM_NAMEは、新しい VM の名前に置き換えます。
VM のブートディスクの空き容量を確認する
ブートディスクが満杯の場合、VM にアクセスできない可能性があります。VM の接続性の問題がブートディスクの満杯に起因する場合は、必ずしも明確ではないため、このような状況ではトラブルシューティングが難しい場合があります。このシナリオの詳細については、ブートディスクが満杯になったためにアクセスできない VM のトラブルシューティングをご覧ください。
Windows VM の診断方法
SSH メタデータをリセットする
SSH を使用して Windows VM に接続できない場合は、enable-windows-ssh メタデータキーの設定を解除し、Windows 用の SSH を再度有効にします。
enable-windows-sshメタデータキーをFALSEに設定します。メタデータの設定方法については、カスタム メタデータを設定するをご覧ください。変更が反映されるまで数秒待ちます。
VM に再接続します。
RDP を使用して VM に接続する
Windows VM への SSH 接続の失敗の原因を診断しても解決できない場合は、RDP を使用して接続します。
VM への接続を確立したら、OpenSSH ログを確認します。
gcpdiag を使用して SSH の問題をデバッグする
gcpdiag はオープンソース ツールです。正式にサポートされている Google Cloud プロダクトではありません。gcpdiag ツールを使用すると、Google Cloud プロジェクトの問題を特定して修正できます。詳細については、GitHub の gcpdiag プロジェクトをご覧ください。
- VM の健全性: VM が実行中で、十分なリソース（CPU、メモリ、ディスク ストレージ）があるかどうかを確認します。
- 権限: SSH 鍵を構成するための適切な IAM 権限があることを確認します。
- VM 設定: SSH 鍵とその他のメタデータが正しく構成されていることを確認します。
- ネットワーク ルール: ファイアウォール ルールを確認し、SSH トラフィックが許可されていることを確認します。
- ゲスト OS: SSH をブロックする可能性のある内部 OS の問題を探します。
Google Cloud コンソール
- 次のコマンドを入力してコピーします。
- Google Cloud コンソールを開き、Cloud Shell をアクティブにします。 Cloud コンソールを開く
- コピーしたコマンドを貼り付けます。
gcpdiagコマンドを実行します。gcpdiagDocker イメージがダウンロードされ、診断チェックが実行されます。必要に応じて、出力の指示に沿って、失敗したチェックを修正します。
gcpdiag runbook gce/ssh --project=PROJECT_ID \
--parameter name=VM_NAME \
--parameter zone=ZONE \
--parameter principal=PRINCIPAL \
--parameter tunnel_through_iap=IAP_ENABLED \
--parameter check_os_login=OS_LOGIN_ENABLEDDocker
Docker コンテナで gcpdiag を起動するラッパーを使用して gcpdiag を実行できます。Docker または Podman がインストールされている必要があります。
- ローカル ワークステーションで次のコマンドをコピーして実行します。
curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
-
gcpdiagコマンドを実行します。./gcpdiag runbook gce/ssh --project=PROJECT_ID \ --parameter name=VM_NAME \ --parameter zone=ZONE \ --parameter principal=PRINCIPAL \ --parameter tunnel_through_iap=IAP_ENABLED \ --parameter check_os_login=OS_LOGIN_ENABLED
このランブックで使用可能なパラメータを表示します。
次のように置き換えます。
- PROJECT_ID: リソースを含むプロジェクトの ID。
- VM_NAME: プロジェクト内のターゲット VM の名前。
- ZONE: ターゲット VM が配置されているゾーン。
- PRINCIPAL: SSH 接続を開始するユーザーまたはサービス アカウント プリンシパル。鍵ベースの認証では、Cloud Shell コマンドライン ツールで認証されたユーザー、または Google Cloud コンソールにログインしたユーザーを使用します。サービス アカウントの権限借用の場合は、サービス アカウントのメールアドレスにする必要があります。
- IAP_ENABLED: SSH 接続の確立に Identity-Aware Proxy が使用されるかどうかを示すブール値（true または false）。デフォルト:
true - OS_LOGIN_ENABLED: SSH 認証に OS Login が使用されるかどうかを示すブール値（true または false）。デフォルト:
true
有用なフラグ:
--project: PROJECT_ID--universe-domain: 該当する場合、リソースをホストする信頼できるパートナーのソブリン クラウド ドメイン--parameterまたは-p: ランブック パラメータ
gcpdiag ツールのフラグの一覧と説明については、gcpdiag の使用手順をご覧ください。
次のステップ
- Compute Engine での Linux VM への SSH 接続の仕組みを学ぶ。