GCE Linux仮想マシンにおけるSSH接続の検証
MSP部の佐々木です。
通勤に利用しているJRが2日連続で止まってしまったので、復旧待ちがてらに会社に戻ってこのブログの執筆を始めました。
はじめに
GCE(Google Compute Engine)はGoogle Cloudの仮想マシンサービスで、AWSのEC2に相当するサービスです。
https://cloud.google.com/compute
今回は、LinuxのイメージでGCEインスタンスを作成した場合の、SSH接続の方式について書いていきたいと思います。
AWSのEC2ではインスタンス作成時にキーペアを設定し、秘密鍵をダウンロードするだけでよいのですが、
GCEの場合はSSH接続に関して様々なパターンが想定され、正直検証するまでは全然理解できていませんでした。
GCE(Linux)のログイン方式
ドキュメントで2種類のログイン方式が紹介されています。
https://cloud.google.com/compute/docs/instances/access-overview?hl=ja
■メタデータ マネージド SSH 接続
プロジェクト、またはインスタンスのメタデータに公開鍵を設定し、対応する秘密鍵を用いてSSH接続する方式です。
EC2のログインはこの方式に近いかと思います。
ログインユーザー名はメタデータに公開鍵を設定するときに指定し、ユーザーにはデフォルトでsudo権限が付与されます。
プロジェクトに公開鍵が設定されている場合、インスタンス側の設定で「プロジェクトの公開鍵をブロック」することができます。
これを使用することで、特定のインスタンスにのみ独自の公開鍵を設定することが可能です。
■OSLogin マネージド SSH接続
Googleが推奨するログイン方式で、SSH接続でIAMの情報を用いた認証が行われます。
プロジェクトまたはインスタンスのメタデータにenable-oslogin: TRUEを設定し、OSLoginを有効化する必要があります。
OSLoginが有効化されているとき、基本的にはメタデータマネージドの方式を使用することができなくなります。(例外パターンは後述)
プロジェクト全体でメタデータマネージドの方式を使用し、特定のインスタンスのみメタデータにenable-oslogin: TRUEを設定してOSLogin方式を使用するといったことも可能です。
この場合は「プロジェクトの公開鍵をブロック」していなくても、OSLogin方式でしかログインできなくなります。
だんだんややこしくなってきましたね。
この方式でログインできるのは、IAM権限「roles/compute.osLogin」もしくは「roles/compute.osAdminLogin」が付与されているユーザーになります。
ログインユーザー名としてはIAMに登録されているGoogleアカウントのメールアドレスが使用され(「.」や「@」は「_」に変換される)、自動で生成されたSSH認証鍵がアカウントに紐づけされます。
SSH認証鍵はgcloudコマンドを使用して手動で設定することも可能です。
自動で生成された認証鍵のセットはCloudShellの~/.sshディレクトリに「google_compute_engine」「google_compute_engine.pub」という名前で配置されているので、Tera TermなどでSSH接続したい場合は秘密鍵をローカルにコピーする必要があります。
sudo権限については「roles/compute.osAdminLogin」権限を持っているユーザーにのみ付与されます。
まだ試していませんが、こちらの方式では二段階認証を設定することもできるようです。
検証内容
本題に入ります。
ここまで書いてきた通り、Linuxインスタンスの接続方式は2種類あり、以下の設定項目によってどちらのログイン方式が使用されるのかが決まります。
- 公開鍵の設定場所(プロジェクトのメタデータorインスタンスのメタデータ)
- enable-osloginの設定場所(プロジェクトのメタデータorインスタンスのメタデータ)
- enable-osloginの値(TRUE or FALSE)
また、ログインに影響する要素として、インスタンス側で設定できる「プロジェクトの公開鍵をブロック」があります。
今回検証したのは「これらの要素を組み合わせて使用したとき、どの方式でSSH接続を行うことができるか」です。
■前提条件
ある程度前提を決めないと組み合わせの数が増えすぎてしまうので、以下の前提で進めていきます。
- プロジェクトのメタデータに公開鍵を設定済み
- Tera Termを使用して接続
検証結果
こんな感じになりました。
結局のところ、以下のルールさえわかっていればいい話でした。
◇インスタンスのメタデータが設定されている場合、プロジェクトのメタデータは無視される。
プロジェクトでOSLoginが有効化されていても、インスタンス側でFALSEに設定されていると、メタデータマネージドの接続方式が使用されます。
ただし、インスタンスのメタデータに公開鍵が設定されていない場合、Tera Termからの初回ログインはできません。(表中の※のケース、後述)
※のケースについて
「メタデータマネージド方式が利用できるが、メタデータに公開鍵が設定されていない場合」となります。
先述しましたが、この場合は利用できる鍵がないため、最初はTera Termからのログインができません。
さて、Google CloudではTera Termなどのサードパーティツールを使用したログインの他に、以下の接続方法があります。
- gcloud sshコマンド
- コンソールの[SSH]ボタン
これらの方法を用いた場合は、公開鍵がメタデータに自動で設定されます。
このログイン方式は以下の仕様になっているようです。
◇ログインユーザー名はGoogleアカウントのメールアドレスの「@の前」
OSLoginではメールアドレス全体が使用されていましたが、こちらでは@の前のみ使用されます。
◇gcloud sshコマンドを使用した場合、CloudShellの~/.sshディレクトリに認証鍵のセットが保存される。
したがって、ここから秘密鍵をコピーすれば2回目以降はTera Termからログインできます。
◇コンソールの[SSH]ボタンでログインした場合、一度限りのSSH認証情報が使用される。
こちらの方法ではCloudShellの~/.sshディレクトリに認証鍵のセットがないので、2回目以降もTera Termからのログインはできません。
あったとしても、認証鍵はすぐ失効されるように設定されているみたいです。
おわりに
以上が検証した結果となります。
いざまとめてみると「当然のこと書いてんじゃん…」って感じてしまうのですが、ドキュメントだけ読んでいると本当に頭がゴチャゴチャして全然わからなかったので、少しでも同じような状況に陥った方の助けになればと思っています。