このページは Cloud Translation API によって翻訳されました。

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

Linux Windows

このドキュメントでは、SSH を使用して仮想マシン（VM）インスタンスに接続するときに発生する可能性がある一般的なエラーとその解決方法、失敗した SSH 接続の診断方法について説明します。

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

SSH トラブルシューティングツールを使用して、SSH 接続に失敗した原因を特定できます。トラブルシューティングツールは、次のテストを実行して SSH 接続の失敗の原因を確認します。

ユーザー権限テスト: SSH を使用して VM に接続するために必要な IAM 権限があるかどうかを確認します
ネットワーク接続テスト: VM がネットワークに接続されているかどうかを確認します。
VM インスタンスのステータステスト: VM の CPU ステータスをチェックして、VM が実行中かどうかを確認します。
VPC 設定テスト: デフォルトの SSH ポートを確認します。

トラブルシューティングツールを実行する

Google Cloud コンソールまたは Google Cloud CLI を使用して、SSH 接続の失敗の原因となるネットワークの問題とユーザー権限のエラーを確認できます。

このタスクに必要な権限

このタスクを行うには、次の権限が必要です。

VM に対する networkmanagement.connectivitytests.create
VM に対する networkmanagement.connectivitytests.delete
VM に対する networkmanagement.connectivitytests.get

上の権限がない場合、トラブルシューティングツールはネットワーク接続テストをスキップします。

Console

SSH 接続が失敗した場合は、接続を再試行するオプションとブラウザ内の SSH トラブルシューティングツールを使用して接続をトラブルシューティングするオプションがあります。

トラブルシューティングツールを実行するには、[トラブルシューティング] をクリックします。

SSH トラブルシューティングツールを起動します。

gcloud

トラブルシューティングツールを実行するには、gcloud compute ssh コマンドを使用します。

gcloud compute ssh VM_NAME \
    --troubleshoot

VM_NAME は、接続に失敗した VM の名前に置き換えます。

トラブルシューティングテストの実行権限を付与するように求められます。

結果を確認する

トラブルシューティングツールを実行した後、以下を行います。

テスト結果を確認して、VM の SSH 接続が機能しない理由を理解します。
ツールで提供される修復手順を実行して SSH 接続を解決します。
VM への再接続を試行します。

接続が成功しない場合は、次の手順に沿って手動でトラブルシューティングを試します。
- シリアルコンソールを使用して問題をデバッグする
- 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 ファイルを送信します。

接続できませんでした。再試行しています。

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 を使用しない場合は、Compute インスタンス管理者ロールまたはサービスアカウントユーザーロール（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 接続リクエストが拒否されることがあります。

この問題を解決するには、次の手順を行います。
1. VM を再起動します。
2. Google Cloud コンソールで、シリアルポート出力のシステム起動ログを調べて、ゲスト環境が実行されているかどうかを確認します。詳細については、ゲスト環境を検証するをご覧ください。
3. ゲスト環境が実行されていない場合は、VM のブートディスクのクローンを作成し、起動スクリプトを使用してゲスト環境を手動でインストールします。
OpenSSH Daemon（sshd）が実行されていないか、正しく構成されていない。sshd は、SSH プロトコル経由でシステムへの安全なリモートアクセスを提供します。構成が誤っているか実行されていない場合、SSH 経由で VM に接続できません。

注: sshd を使用して問題のトラブルシューティングを行うには、root ユーザーとして VM のシリアルコンソールに接続する必要があります。をご覧ください。
この問題を解決するには、次の対処方法をいくつか試してください。
- オペレーティングシステムのユーザーガイドを参照して、sshd_config が正しく設定されていることを確認します。
- 以下のオーナー権限と権限が設定されていることを確認します。
  - $HOME と $HOME/.ssh ディレクトリ
  - $HOME/.ssh/authorized_keys ファイル
  オーナー権限
  ゲスト環境では、承認済みの SSH 公開鍵が $HOME/.ssh/authorized_keys ファイルに保存されます。$HOME ディレクトリ、$HOME/.ssh ディレクトリ、$HOME/.ssh/authorized_keys ファイルのオーナーは、VM に接続するユーザーと同じである必要があります。
  
  権限
  ゲスト環境には、次の Linux 権限が必要です。
  
  パス権限
  
  /home 0755
  
  $HOME 0700 または 0750 または 0755^*
  
  $HOME/.ssh 0700
  
  $HOME/.ssh/authorized_keys 0600
  
  ^* どのオプションが $HOME ディレクトリの適切なデフォルト権限であるかを確認するには、ご使用の Linux ディストリビューションの公式ドキュメントをご覧ください。。
  
  また、同じイメージに基づいて新しい VM を作成し、$HOME のデフォルトの権限を確認することもできます。
  
  権限とオーナー権限を変更する方法については、chmod と chown をご覧ください。
- 次のコマンドを実行して 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 権限が必要です。

パス権限

/home 0755

$HOME 0700 または 0750 または 0755^*

$HOME/.ssh 0700

$HOME/.ssh/authorized_keys 0600

^* どのオプションが $HOME ディレクトリの適切なデフォルト権限であるかを確認するには、ご使用の Linux ディストリビューションの公式ドキュメントをご覧ください。。

また、同じイメージに基づいて新しい VM を作成し、$HOME のデフォルトの権限を確認することもできます。

権限とオーナー権限を変更する方法については、chmod と chown をご覧ください。

パス	権限
`/home`	`0755`
`$HOME`	`0700` または `0750` または `0755`^*
`$HOME/.ssh`	`0700`
`$HOME/.ssh/authorized_keys`	`0600`

パス	権限
`/home`	`0755`
`$HOME`	`0700` または `0750` または `0755`^*
`$HOME/.ssh`	`0700`
`$HOME/.ssh/authorized_keys`	`0600`

接続できませんでした

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 権限を確認します。
  1. カスタムファイアウォールルールを更新して、35.235.240.0/20（IAP が TCP 転送に使用する IP アドレス範囲）からのトラフィックを許可します。詳細については、ファイアウォールルールを作成するをご覧ください。
  2. IAP TCP 転送の使用権限を付与します（まだ付与していない場合）。
- IAP を使用しない場合は、上り（内向き）SSH トラフィックを許可するようにカスタムファイアウォールルールを更新します。
  1. カスタムファイアウォールルールを更新して、VM への上り（内向き）SSH 接続を許可します。
VM のカーネルをアップグレードした後に SSH 接続に失敗する。カーネルの更新後に VM にカーネルパニックが発生し、VM にアクセスできなくなる場合があります。

この問題を解決するには、次の手順を行います。
1. 別の VM にディスクをマウントします。
2. 以前のバージョンのカーネルを使用するように grub.cfg ファイルを更新します。
3. 応答しない VM にディスクをアタッチします。
4. gcloud compute instances describe コマンドを使用して、VM のステータスが RUNNING であることを確認します。
5. カーネルを再インストールします。
6. VM を再起動します。
VM をアップグレードする前にブートディスクのスナップショットを作成した場合は、スナップショットを使用して VM を作成します。
OpenSSH Daemon（sshd）が実行されていないか、正しく構成されていない。sshd は、SSH プロトコル経由でシステムへの安全なリモートアクセスを提供します。構成が誤っているか実行されていない場合、SSH 経由で VM に接続できません。

注: sshd を使用して問題のトラブルシューティングを行うには、root ユーザーとして VM のシリアルコンソールに接続する必要があります。をご覧ください。
この問題を解決するには、次の対処方法をいくつか試してください。
- オペレーティングシステムのユーザーガイドを参照して、sshd_config が正しく設定されていることを確認します。
- 以下のオーナー権限と権限が設定されていることを確認します。
  - $HOME と $HOME/.ssh ディレクトリ
  - $HOME/.ssh/authorized_keys ファイル
  オーナー権限
  ゲスト環境では、承認済みの SSH 公開鍵が $HOME/.ssh/authorized_keys ファイルに保存されます。$HOME ディレクトリ、$HOME/.ssh ディレクトリ、$HOME/.ssh/authorized_keys ファイルのオーナーは、VM に接続するユーザーと同じである必要があります。
  
  権限
  ゲスト環境には、次の Linux 権限が必要です。
  
  パス権限
  
  /home 0755
  
  $HOME 0700 または 0750 または 0755^*
  
  $HOME/.ssh 0700
  
  $HOME/.ssh/authorized_keys 0600
  
  ^* どのオプションが $HOME ディレクトリの適切なデフォルト権限であるかを確認するには、ご使用の Linux ディストリビューションの公式ドキュメントをご覧ください。。
  
  また、同じイメージに基づいて新しい VM を作成し、$HOME のデフォルトの権限を確認することもできます。
  
  権限とオーナー権限を変更する方法については、chmod と chown をご覧ください。
- 次のコマンドを実行して sshd を再起動します。
```
systemctl restart sshd.service
```
  次のコマンドを実行して、ステータスにエラーがあるかどうかを確認します。
```
systemctl status sshd.service
```
  ステータスの出力には、終了コードや失敗の理由などの情報が含まれていることがあります。これらの詳細情報を使用して、トラブルシューティングをさらに進めることができます。
VM が起動せず、SSH またはシリアルコンソールで接続できない。VM にアクセスできない場合は、OS が破損している可能性があります。ブートディスクが起動しない場合は、問題を診断できます。破損した VM を復元してデータを取得する場合は、破損した VM または完全なブートディスクの復元をご覧ください。
VM がメンテナンスモードで起動している。メンテナンスモードで起動している場合、VM は SSH 接続を受け入れません。ただし、VM のシリアルコンソールに接続して、root ユーザーとしてログインできます。

この問題を解決するには、次の手順を行います。
1. VM の root パスワードを設定していない場合は、メタデータ起動スクリプトを使用して起動時に次のコマンドを実行します。
```
echo "root:NEW_PASSWORD" | chpasswd
```
  NEW_PASSWORD は任意のパスワードに置き換えてください。
2. VM を再起動します。
3. VM のシリアルコンソールに接続して、root ユーザーとしてログインします。

パス	権限
`/home`	`0755`
`$HOME`	`0700` または `0750` または `0755`^*
`$HOME/.ssh`	`0700`
`$HOME/.ssh/authorized_keys`	`0600`

予期しないエラーが発生しました

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 を使用して問題のトラブルシューティングを行うには、root ユーザーとして VM のシリアルコンソールに接続する必要があります。をご覧ください。
この問題を解決するには、次の対処方法をいくつか試してください。
- オペレーティングシステムのユーザーガイドを参照して、sshd_config が正しく設定されていることを確認します。
- 以下のオーナー権限と権限が設定されていることを確認します。
  - $HOME と $HOME/.ssh ディレクトリ
  - $HOME/.ssh/authorized_keys ファイル
  オーナー権限
  ゲスト環境では、承認済みの SSH 公開鍵が $HOME/.ssh/authorized_keys ファイルに保存されます。$HOME ディレクトリ、$HOME/.ssh ディレクトリ、$HOME/.ssh/authorized_keys ファイルのオーナーは、VM に接続するユーザーと同じである必要があります。
  
  権限
  ゲスト環境には、次の Linux 権限が必要です。
  
  パス権限
  
  /home 0755
  
  $HOME 0700 または 0750 または 0755^*
  
  $HOME/.ssh 0700
  
  $HOME/.ssh/authorized_keys 0600
  
  ^* どのオプションが $HOME ディレクトリの適切なデフォルト権限であるかを確認するには、ご使用の Linux ディストリビューションの公式ドキュメントをご覧ください。。
  
  また、同じイメージに基づいて新しい VM を作成し、$HOME のデフォルトの権限を確認することもできます。
  
  権限とオーナー権限を変更する方法については、chmod と chown をご覧ください。
- 次のコマンドを実行して sshd を再起動します。
```
systemctl restart sshd.service
```
  次のコマンドを実行して、ステータスにエラーがあるかどうかを確認します。
```
systemctl status sshd.service
```
  ステータスの出力には、終了コードや失敗の理由などの情報が含まれていることがあります。これらの詳細情報を使用して、トラブルシューティングをさらに進めることができます。
SSH デーモンに関する不明な問題。SSH デーモンに関する不明な問題を診断するには、シリアルコンソールのログでエラーを確認します。

シリアルコンソールのログの出力に応じて、次の手順で VM をレスキューし、SSH デーモン関連の問題を修正します。
1. 別の Linux VM にディスクをアタッチします。
2. ディスクがマウントされている VM に接続します。
3. VM 内のディレクトリ MOUNT_DIR に OS 内のディスクをマウントします。
4. SSH 関連のログ（/var/log/secure または /var/log/auth.log）で問題やエラーを確認します。修正できる問題が見つかった場合は、修正を試みます。それ以外の場合は、サポートケースを作成してログを送信します。
5. umount コマンドを使用して OS からディスクをマウント解除します。
```
cd ~/
umount /mnt
```
6. VM からディスクを切断します。
7. 元の VM にディスクをアタッチします。
8. VM を起動します。

パス	権限
`/home`	`0755`
`$HOME`	`0700` または `0750` または `0755`^*
`$HOME/.ssh`	`0700`
`$HOME/.ssh/authorized_keys`	`0600`

バックエンドに接続できない

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 のエラー

アクセスが拒否されました。もう一度お試しください

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 に設定します。medata の設定の詳細については、カスタムメタデータを設定するをご覧ください。

アクセスの拒否（公開鍵、キーボードインタラクティブ）

SSH が有効になっていない VM に接続すると、次のエラーが発生することがあります。

Permission denied (publickey,keyboard-interactive).

このエラーを解決するには、プロジェクトまたはインスタンスメタデータで enable-windows-ssh キーを TRUE に設定します。medata の設定の詳細については、カスタムメタデータを設定するをご覧ください。

インスタンスに 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 の名前に置き換えます。

注: IAP を使用して内部 IP アドレスを介してインスタンスにアクセスする場合は、IP アドレスが異なる場合があります。また、内部 IP アドレスの場合、インスタンスには VPC ネットワーク内からのみアクセスできます。

ワークステーションから 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: 前の手順で取得した外部 IP
PORT_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
ls
```
VM_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 に設定します。メタデータの設定方法については、カスタムメタデータを設定するをご覧ください。

変更が反映されるまで数秒待ちます。
Windows で SSH を再度有効にします
VM に再接続します。

RDP を使用して VM に接続する

Windows VM への SSH 接続の失敗の原因を診断しても解決できない場合は、RDP を使用して接続します。

VM への接続を確立したら、OpenSSH ログを確認します。

gcpdiag を使用して SSH の問題をデバッグする

gcpdiag はオープンソースツールです。正式にサポートされている Google Cloud プロダクトではありません。 gcpdiag ツールを使用すると、Google Cloud プロジェクトの問題を特定して修正できます。詳細については、GitHub の gcpdiag プロジェクトをご覧ください。

この gcpdiag ランブックでは、Google Cloud の Windows VM と Linux VM の両方で SSH 接続の問題が発生する可能性のある原因を調査します。

VM の健全性: VM が実行中で、十分なリソース（CPU、メモリ、ディスクストレージ）があるかどうかを確認します。
権限: SSH 鍵を構成するための適切な IAM 権限があることを確認します。
VM 設定: SSH 鍵とその他のメタデータが正しく構成されていることを確認します。
ネットワークルール: ファイアウォールルールを確認し、SSH トラフィックが許可されていることを確認します。
ゲスト OS: SSH をブロックする可能性のある内部 OS の問題を探します。

Google Cloud コンソール

次のコマンドを入力してコピーします。

gcpdiag runbook gce/ssh \
    --parameter project_id=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
    --parameter local_user=LOCAL_USER \
    --parameter check_ssh_in_browser=CHECK_SSH_IN_BROWSER

Google Cloud コンソールを開き、Cloud Shell をアクティブにします。

Cloud コンソールを開く

コピーしたコマンドを貼り付けます。
gcpdiag コマンドを実行します。gcpdiag Docker イメージがダウンロードされ、診断チェックが実行されます。該当する場合は、出力指示に従って失敗したチェックを修正します。

Docker

Docker コンテナで gcpdiag を起動するラッパーを使用して gcpdiag を実行できます。Docker または Podman がインストールされている必要があります。

ローカルワークステーションで次のコマンドをコピーして実行します。
```
curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
```

gcpdiag コマンドを実行します。

./gcpdiag runbook gce/ssh \
    --parameter project_id=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
    --parameter local_user=LOCAL_USER \
    --parameter check_ssh_in_browser=CHECK_SSH_IN_BROWSER

このランブックで使用可能なパラメータを表示します。

次のように置き換えます。

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
LOCAL_USER:VM 上の Posix ユーザー。
CHECK_SSH_IN_BROWSER:ブラウザでの SSH が実行可能かどうかを確認するブール値。

有用なフラグ:

--universe-domain: 該当する場合、リソースをホストする信頼できるパートナーのソブリンクラウドドメイン
--parameter または -p: ランブックパラメータ

gcpdiag ツールのフラグの一覧と説明については、gcpdiag の使用手順をご覧ください。

次のステップ

Compute Engine での Linux VM への SSH 接続の仕組みを学ぶ。

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

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

トラブルシューティング ツールを実行する

このタスクに必要な権限

Console

gcloud

結果を確認する

一般的な SSH エラー

ブラウザからの SSH でのエラー

Unauthorized Error 401

接続できませんでした。再試行しています。

Linux のエラー

権限の拒否（公開鍵）

オーナー権限

権限

オーナー権限

権限

接続できませんでした

オーナー権限

権限

予期しないエラーが発生しました

オーナー権限

権限

バックエンドに接続できない

ホストキーが一致しない

メタデータ値が大きすぎる

Windows のエラー

アクセスが拒否されました。もう一度お試しください

アクセスの拒否（公開鍵、キーボードインタラクティブ）

インスタンスに SSH 接続できなかった

接続がタイムアウトになった

失敗した SSH 接続を診断する

Linux VM と Windows VM の診断方法

接続のテスト

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

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

Linux、Windows 2019/2022、macOS

Windows 2012 と 2016

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

シリアル コンソールを使用して問題をデバッグする

Linux VM の診断方法

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

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

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

VM のブートディスクの空き容量を確認する

Windows VM の診断方法

SSH メタデータをリセットする

RDP を使用して VM に接続する

gcpdiag を使用して SSH の問題をデバッグする

Google Cloud コンソール

Docker

次のステップ

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

トラブルシューティングツールを実行する

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

シリアルコンソールを使用して問題をデバッグする