ブラウザからの SSH

ブラウザから SSH を使用すると、Google Cloud Console 内から SSH を使用して Compute Engine 仮想マシン インスタンスに接続できます。この機能を使用するために、ウェブブラウザの拡張機能や追加のソフトウェアをインストールする必要はありません。ブラウザからの SSH は、インスタンスに接続する他の方法の代わりとなります。

Linux VM インスタンスへの接続

Compute Engine は、ブラウザから Linux インスタンスに接続するたびに SSH 認証鍵を管理し、必要に応じて SSH 認証鍵ペアを作成して適用します。ブラウザからの接続に使用される SSH 鍵を管理することはできません。代わりに、ブラウザからの接続に対するユーザーのアクセスは、Identity and Access Management ロールで制御します。プロジェクトのメンバーと IAM ロールは、Google Cloud Console の [IAM] ページで表示できます。

[IAM] ページに移動

ブラウザを使用して接続するには、Compute インスタンス管理者としてプロジェクト メンバーになっている必要があります。インスタンスをサービス アカウントとして実行するには、サービス アカウント ユーザーである必要もあります。ブラウザを使用して接続するためのアクセス権がない場合は、プロジェクト オーナーに自分をプロジェクトに追加してアクセス権を付与するよう依頼してください。

アクセスが許可されたら、Cloud Console のウェブブラウザから Linux インスタンスに直接接続します。

  1. Cloud Console で、[VM インスタンス] ページに移動します。

    [VM インスタンス] ページに移動

  2. 仮想マシン インスタンスのリストで、接続するインスタンスの行にある [SSH] をクリックします。

    インスタンス名の横にある SSH ボタン。

また、インスタンスへの SSH 接続は、その名前をクリックし、インスタンスの詳細ページから [SSH] をクリックして開くこともできます。

以上で、ターミナルを使用して Linux インスタンスでコマンドを実行できます。終了したら、exit コマンドを使用してインスタンスから切断します。

Identity-Aware Proxy を介した TCP トンネリングを許可するようにインスタンスが構成されている場合は、ブラウザから SSH を使用してインスタンスに接続できます。これは、外部 IP アドレスを持たないインスタンスで特に便利です。これを有効にする場合は、Identity-Aware Proxy TCP 転送をご覧ください。注: IAP は、TCP トンネリングと外部 IP アドレスで構成されているインスタンスのデフォルト ルートです。

サポートされる環境

ブラウザからの SSH では、次の環境をサポートしています。

  • ウェブブラウザ
    • Google Chrome の最新バージョン
    • Firefox
    • Microsoft Edge
    • Microsoft Internet Explorer 11 以降
    • Safari 8 以降プライベート ブラウズモードの Safari はサポートされていません。
  • 仮想マシンの構成
    • Google Cloud でネイティブに使用できるすべての Linux VM イメージ。

既知の問題

  • SSH 認証鍵の転送時間が長い。デフォルトでは、ブラウザの SSH は新しい SSH 接続鍵をプロジェクト メタデータにプッシュします。このため、VM の数が多いプロジェクトでは処理に時間がかかることがあります。鍵の転送を高速化するには、プロジェクト全体の SSH 認証鍵をブロックするか、OS ログインを有効にします。

  • 起動レイテンシ。現在、ブラウザからの SSH を使用する際の接続時間は 5~30 秒です。ゲスト環境の現行バージョンでは、より速い接続に対応しています。

  • 新しい VM インスタンスがすぐに利用できない。新しいインスタンスでは、起動して SSH 接続が確立するまでに一定の時間を要します。新しいインスタンスに接続できない場合は、数分後に再試行してください。

  • 断続的な切断。現時点では、接続の存続時間に関する特定の SLA は提供されていません。ターミナル ウィンドウを長期間開いたままにする場合は、tmuxscreen などのターミナル マルチプレクサを使用してください。

  • 外部 IP アドレスのないインスタンスに接続する。Compute Engine インスタンスに内部 IP アドレスしかない場合は、次のいずれかの方法で接続します。

    • Cloud Identity-Aware Proxy TCP 転送が構成されているブラウザから SSH で接続する。

    • 踏み台インスタンスのブラウザから SSH で接続する。このオプションを使用するには、ターゲットと踏み台インスタンスの両方が同じ VPC ネットワーク上に存在するか、接続する VPC ネットワークに存在する必要があります。

      踏み台インスタンスのブラウザから SSH で接続するには、次の手順を行います。

      1. ブラウザから SSH を使用し、外部 IP アドレスを持つ踏み台インスタンスに接続します。これにより、一時的な SSH 認証鍵ペアが生成され、踏み台インスタンスのプロジェクトまたはインスタンス メタデータに公開鍵がアップロードされます。
      2. 踏み台インスタンスから、内部 IP アドレスのみを持つターゲット インスタンスに接続します。踏み台インスタンスからターゲット インスタンスに接続するには、次のコマンドを実行します。このとき、internal-ip はターゲット インスタンスの内部 IP アドレスに置き換えます。

        ssh -A internal-ip

        最初の手順で生成された一時鍵を使用するには、踏み台インスタンスに接続してから 2 分以内にこのコマンドを実行する必要があります。

  • Ctrl+W でウィンドウが閉じる。Ctrl+WCtrl+F4Ctrl+Tab、およびブラウザのキーボード ショートカットとして機能する他のキーの組み合わせは、SSH クライアントからターゲット システムに渡されません。このようなショートカットや他のショートカットを送信するには、ウィンドウの右上にあるキーボード アイコンをクリックします。Google Chrome ブラウザを使用する場合は、「SSH for Google Cloud Platform」拡張機能をインストールできます。この拡張機能によって、Ctrl+W など、ブラウザで一般に予約されているキーボード ショートカットに直接アクセスできるようになり、ブラウザからの SSH と Cloud Shell のコンソール エクスペリエンスが向上します。

  • 大きなファイルでは、ファイル転送が遅くなることがあります。大きなファイルを転送する場合は、gcloud compute scp の使用をおすすめします。

「Unable to connect on port 22」エラー メッセージへの対処

このエラーは、次の条件で表示されることがあります。

  • インスタンスが起動中で、sshd がまだ実行されていない。インスタンスの起動が完了したことを確認した後、再試行してください。

  • インスタンスで sshd が実行されていない。デフォルトでは、sshd は標準の Compute Engine イメージから作成されたインスタンス上で実行されます。sshd を手動で無効にした場合、またはこのサービスを実行しないカスタム イメージを構成した場合、ブラウザからの SSH は機能しません。

  • sshd が接続先以外のポートでリッスンしている。デフォルトでは、ブラウザからの SSH は、ポート 22 のインスタンスに接続します。カスタムポートで sshd を実行している場合、SSH ボタンのプルダウン リストから [ブラウザ ウィンドウでカスタムポートを開く] 項目を選択すると、そのポートに接続できます。

  • ポート上の SSH アクセスを許可するファイアウォール ルールがない。ポート 22 上の SSH アクセスは、すべての Compute Engine インスタンスでデフォルトで有効になっています。アクセスを無効にしている場合、ブラウザからの SSH は機能しません。22 以外のポートで sshd を実行する場合は、カスタム ファイアウォール ルールを使用してそのポートへのアクセスを有効にする必要があります。

  • SSH アクセスを許可するファイアウォール ルールが有効になっているが、Cloud Console サービスからの接続を許可するように構成されていない。ブラウザベースの SSH セッションの送信元 IP アドレスは、Cloud Console によって動的に割り当てられ、セッションごとに異なることがあります。この機能を動作させるには、任意の IP アドレスからの接続、または公開 SPF レコードを使用して取得できる Google の IP アドレス範囲からの接続を許可する必要があります。

  • インスタンスがシャットダウンされている。インスタンスが起動して実行されていることを確認します。正常でないインスタンスのトラブルシューティングを行う方法については、Compute Engine を使用する場合の一般的なヒントをご覧ください。

「Could not connect, retrying...」エラーへの対処

  • インスタンスがゲスト環境を実行していない可能性がある。ゲスト環境がインストールされ、実行されていることを確認します。

  • インスタンスのブートディスクの空き容量が不足している。接続が確立されると、ゲスト環境により、現在のセッションに使用されている公開 SSH 認証鍵で ~/.ssh/authorized_keys ファイルが更新されます。ディスクの空き容量が不足していると、更新に失敗します。ディスク容量の問題を特定するには、インスタンスのシリアル コンソールの出力でディスク不足エラーを探します。ディスク容量の問題を解決する方法には、次のようなものがあります。

    • インスタンスのブート永続ディスクをサイズ変更して、そのサイズを増やします。インスタンスで使用されるオペレーティング システム イメージで自動サイズ変更がサポートされている場合、インスタンスの再起動後にオペレーティング システムが新しいサイズに合わせてルート パーティションのサイズを自動的に変更するので、これが最も簡単なオプションとなります。
    • どのファイルがディスク容量を消費しているかわかっている場合は、不要なファイルを削除し、インスタンスを起動するための容量を確保する起動スクリプトを作成します。スクリプトが実行されてファイルが消去されるように、インスタンスを再起動します。正しいコマンドを使用して正しいファイルを削除するように注意してください。インスタンスが起動し、SSH 経由でインスタンスに接続できるようになった後、ファイルが削除され続けないように、startup-script メタデータ アイテムの設定を元に戻します。
    • インスタンスのディスクにアクセスする方法については、Compute Engine を使用する場合の一般的なヒントをご覧ください。
  • $HOME$HOME/.ssh$HOME/.ssh/authorized_keys の権限または所有権が間違っている。

    • 所有権: ゲスト環境では、接続ユーザーの $HOME/.ssh/authorized_keys ファイルに公開 SSH 認証鍵を保存できる必要があります。$HOME ディレクトリ、$HOME/.ssh ディレクトリ、authorized_keys ファイルの所有者が接続ユーザーと同じであることを確認してください。
    • 権限: ユーザー名を変更して別のユーザーとして接続を試み、接続できないユーザーの権限問題を修復します。

      ディレクトリ / ファイル 必要な Unix 権限
      $HOME ディレクトリ 0755 または
      0700
      $HOME/.ssh ディレクトリ 0700
      authorized_keys ファイル 0600

コピーと貼り付け

ブラウザとプラットフォームでサポートされているキーボード ショートカットを使用してテキストのコピーと貼り付けを行えます(Windows および Linux では Ctrl+CCtrl+V、macOS では Cmd+CCmd+V、Chrome OS では Ctrl+Shift+V)。一般に、これらのコマンドはほとんどの構成で機能しますが、構成によって結果が異なる場合があります。大きなテキスト ブロックをコピーして貼り付ける際に問題が発生した場合は、ファイル転送を使用してください。

ファイルを転送する

ブラウザからの SSH を使用してインスタンスへの SSH 接続を確立できる場合は、その接続を使用してファイルをインスタンスに転送できます。

詳しくは、ブラウザの SSH を使用したファイルの転送をご覧ください。

スクロール

マウスホイールやトラックパッドを使用して、ターミナルをスクロールできます。また、Windows と Linux ではキーボード ショートカット Ctrl+Shift+PageUpCtrl+Shift+PageDn で、macOS では Fn+Shift+UpFn+Shift+Down でターミナルをスクロールできます。

ログイン ユーザー名

デフォルトのユーザー名

デフォルトでは、SSH セッションのユーザー名は、アカウントにログインしているメールアドレスから、ドメイン情報を省略して、生成されます。たとえば、メールアドレスが user@gmail.com の場合、対応するユーザー名は user になります。

OS ログインを有効にした場合のデフォルトのユーザー名

OS Login が有効になっていて、Google Workspace 管理者がユーザー名を設定していない場合は、デフォルトで長いバージョンのユーザー名が設定されます。このユーザー名にはドメイン情報が含まれています。たとえば、メールアドレスが user@gmail.com の場合、対応するユーザー名は user_gmail_com になります。OS ログイン動作の詳細については、予想されるログイン動作をご覧ください。

デフォルトのユーザー名の変更

ユーザー名の変更は、SSH ウィンドウ内から次の手順で行えます。

  1. VM インスタンスに接続します
  2. SSH ウィンドウの右上隅にある設定アイコン 設定アイコン をクリックします。
  3. [Linux ユーザー名を変更] を選択します。Linux システムではログイン名の最大長が 32 文字に制限されているため、デフォルトのユーザー名と構成済みユーザー名はその制限を超えないように切り捨てられます。
  4. (省略可)データを新しいホーム ディレクトリにコピーします。新しいユーザー名はそれぞれ異なる Unix ユーザーのため、ホーム ディレクトリにデータを保存している場合は、cp コマンドを使用してデータを新しいディレクトリにコピーできます。たとえば、ユーザー名を user_gmail_com から user に変更した場合は、次の一連のコマンドを実行します。

    # This will overwrite files in the target directory, so be careful.
    $ sudo cp -r /home/user_gmail_com/. /home/user
    
    $ sudo chown -R user:user /home/user
    

ユーザー指定の秘密 SSH 認証鍵の使用

必要に応じて、[SSH] ボタンのプルダウン リストで [指定された秘密 SSH 認証鍵を使用してブラウザ ウィンドウで開く] を選択します。

ユーザー指定の秘密 SSH 認証鍵を使用してインスタンスに接続するには、次の前提条件を満たしている必要があります。

  1. プロジェクトまたは個々のインスタンスで OS Login 機能を有効にします
  2. ユーザーの OS Login プロファイルで公開 SSH 認証鍵を構成します。リクエストにプロジェクト ID を指定し、プロファイルが正しく構成されていることを確認します。