Session Manager 使えば踏み台サーバーが不要に

2019年7月、AWS Systems Manager セッションマネージャーを使用して、クライアントとサーバー間で SSH (Secure Shell) および SCP (Secure Copy) トラフィックをトンネリングすることができるようになった。

セッションマネージャーが SSH と SCP のトンネリングサポートを開始

何が嬉しいのかというと、一番大きいのは、

踏み台サーバーを使用せずに、 Session Manager 経由で対象のEC2に接続できる

ということではないだろうか。
実際にやってみた。

前提条件

  • SSM Agent のバージョン 2.3.672.0 以上
  • ProxyCommand をサポートする SSH クライアント
  • AWS CLI のバージョン 1.16.12 以上
  • Session Manager Plugin のバージョン 1.1.22.0 以上

EC2側の設定

必要な SSM Agent のバージョンが 2.3.672.0 以上 なので、そうなっていない場合は、アップデートする。

SSM Agentのバージョンアップデート

AWSコンソールの AWS Systems ManagerRun Command から AWS-UpdateSSMAgent を実行する。

もしくは、 AWS CLI から、下記のコマンドを実行する。

1
2
aws ssm send-command --document-name "AWS-UpdateSSMAgent" \
--instance-ids <インスタンスID> --region ap-northeast-1

EC2にロール付与

IAM インスタンスプロファイルロールを確認し、作成する。
AWS 管理ポリシー AmazonSSMManagedInstanceCore を含んだロールを付与する。

クライアント側

Session Manager の IAM エンドユーザーポリシーを作成

下記のドキュメントを参考に、ポリシーを作成、使用するIAMユーザーに付与する。

クイックスタート Session Manager のデフォルト IAM ポリシー - AWS Systems Manager

AWS CLI に Session Manager Plugin をインストールする

(オプション) AWS CLI 用の Session Manager Plugin をインストールする

上記のURLの手順の通り。

  1. バンドルされたインストーラをダウンロード
1
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/sessionmanager-bundle.zip" -o "sessionmanager-bundle.zip"
  1. パッケージを解凍
1
unzip sessionmanager-bundle.zip
  1. インストールコマンドを実行
1
sudo ./sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-plugin
  1. インストールできたことを確認
1
2
session-manager-plugin --version
1.1.31.0

~/.ssh/config 設定

~/.ssh/config に下記のように設定する。

1
2
3
# SSH over Session Manager
host i-* mi-*
ProxyCommand bash -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

あとは通常のオペレーションと同じように、SSHをするだけ。
違うのは、パブリックIPではなくてインスタンスIDを指定する点。

1
2
3
4
5
6
7
8
$ ssh -i ./genedev ec2-user@i-0f0963977fbd1a5bb

__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|

https://aws.amazon.com/amazon-linux-2/
[ec2-user@genedev ~]$

SCP もOK

1
2
$ scp -i ./genedev abc.txt ec2-user@i-0f0963977fbd1a5bb:/tmp/
abc.txt 100% 18 0.4KB/s 00:00
1
2
3
[ec2-user@genedev ~]$ ls -l /tmp/abc.txt
-rw-r--r-- 1 ec2-user ec2-user 18 Sep 16 01:34 /tmp/abc.txt
[ec2-user@genedev ~]$

※ セキュリティグループは、ご覧の通り、インバウンドは何も許可していない

Windowsもやってみた

Windowsの場合は、 AWS-StartPortForwardingSession を使用して、ポート転送を行う。
下記コマンドを実行する。

1
2
3
4
5
6
$ aws ssm start-session --target i-05bc3e1e3e92f1eed \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["3389"], "localPortNumber":["13389"]}'

Starting session with SessionId: eugene_sasaki-0f6e15b8de94ffd19
Port 13389 opened for sessionId eugene_sasaki-0f6e15b8de94ffd19.

セッションが開始されるので、リモートデスクトップクライアント側の設定。
ここでのポイントは、 localPortNumber で指定したポート13389を入れて、 localhost:13389 とすること。

無事接続できた。

今回のハマリポイント

SSM Agent のバージョンをしっかりと確認していなかった( 2.3.662.0 だった)ため、
「つながらないなー。何が悪いんだー」って無駄な調査時間を費やしてしまった……。
ちゃんとバージョンは確認しましょう。

SSM Agent のバージョンは、 AWS Systems ManagerManaged Instances から確認可能。

再度メリットとデメリットをおさらい

メリット

  • VPC内のアプリケーション・サーバーにアクセスするためだけの踏み台サーバーが不要になる。 踏み台サーバーの使用料が不要。合わせて踏み台サーバーの運用コスト(脆弱性対応など)もかからない
  • セキュリティグループでSSHポートを外に開放しなくていい
  • IAMでの一元的なアクセス制御が可能
  • AWS CloudTrailSession Manager API の呼び出しをログ記録できる

デメリット?

  • プラグインインストールなど、若干の手間が必要
  • お客様が普段からSSH接続して運用しているケースが多い場合、通常のSSHではなくて、 AWS CLI を使って、Session Manager 経由でSSHしてもらうことになるので、少しだけハードル高いかも?しれない。MMMのメンバーのみがオペレーションするような環境なら、問題なさそう

参考URL

このエントリーをはてなブックマークに追加