AWS Systems Manager のセッションマネージャで EC2 (Linux) にアクセスした際に気をつけたいこととその緩和策

AWS Systems Manager のセッションマネージャは非常に便利で強力なツールですが、SSH の代替と考えるとすこし気をつけないとならないところがあります。その対応策も含めてまとめました。

#AWS

#AWS Systems Manager（SSM）

渡辺聖剛

2018.10.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

AWS Systems Manager 使ってますか！（挨拶）

先月 9/11（現地時間）にリリースされたセッションマネージャは、インバウンドの SSH ポートを開いたりしなくても EC2 にシェルアクセスできるという待望の機能です。

AWS Systems Manager セッションマネージャーで EC2 インスタンスへのシェルアクセスを実現 | Amazon Web Services ブログ

この機能はクラメソ社内でも注目度が高く、複数の記事が書かれました。使ってみたというかた、気になっているというかたも多いのではないでしょうか。

早速わたしも使ってみたのですが、テスト的に EC2（OS は Amazon Linux）へアクセスした瞬間に違和感を感じました。

・・・違和感ないです？

通常 Amazon Linux 2 の環境に SSH ログインした場合と比べると、いろいろとすっきりとしています。

その後いろいろとコマンドを打ってみました。

セッションは ssm-user で開かれているので、そちらの設定を見てみると。。。ちゃんとホームディレクトリもあるしログインシェルも設定されています。

ホームディレクトリはちゃんと設定された場所にあるし、.bashrcなんかもそろってます。

なのに何故、プロンプトは sh-4.2 だしアクセス直後のカレントディレクトリは /usr/bin/ なんでしょう？

謎解き

調べた結果を基にした解釈でしかありませんが、OS から見て、セッションマネージャからのアクセスは「ログイン」状態ではない、と言えると思います。

シェルの親プロセスは ssm-session-worker、その上は amazon-ssm-agent となっています。あくまでエージェントプロセスの子プロセスとして /bin/sh が起動されたという状態なのでしょう。

改めて上述した公式ドキュメントを読み返してみると、どこにも「ログイン（login）」という文字列は使われておらず、「シェルアクセス」と言っていますね。

ログインしていないということはつまり、w で見ても見えませんし、last コマンドでも表示されません。SSH やコンソールログインと同じ感覚、あるいはその代替として使おうとするには注意が必要ということになります。

注意すべき点

1. カレントディレクトリ

最初に気をつけたいのはカレントディレクトリでしょう。前述したとおりアクセス直後は /usr/bin なので、ここにファイルなどを作ったりは出来ません。

2. シェル

また .bashrc などが読み込まれておらず、そもそもシェルが BASH ではないため、そのつもりで使おうとするとどこかで非互換性を踏むかも知れません。例えば .bashrc に環境変数の設定をしても有効にならないというわけです。

3. ログイン状態ではない

そして前述したとおり、w で見えませんし wtmp に残りません。last で履歴をみても出てきません。

sudo を使えば /var/log/secure 等には痕跡が残りますが、一般的に「OS へのログイン履歴を調べる」となった場合には注意が必要です。もちろん AWS 側には証跡が残っているので、履歴などは代わりにそちらを調べればよいのですが、「いま他に誰か作業していないかな」などと思って w コマンドを実行することは多いと思うので気をつける必要があります。

挙げれば他にもありそうですが、シェルアクセスという基本的なところとしてはこの 3 つかなと考えました。

緩和策について

ログイン時リソースを読み込ませる

まず 1 と 2 です。/etc/passwd にはちゃんと設定が書かれているので、手っ取り早く sudo しなおすのが早そうです。

$ sudo -iu `whoami`

あるいは whoami の結果はわかりきっているので、展開してしまっても良いでしょう。

$ sudo -iu ssm-user

SUDO コマンドの -i オプションは「シェルのログイン時リソース（.profileなど）を読み込む」というものです。ssm-user ユーザのログイン時リソース .bash_profile が読み込まれることになり、プロンプトや環境変数が設定された状態になります。

カレントディレクトリもホームディレクトリ（ /home/ssm-user ）になってますね。ただしこの状態でも、3 つまり w や last での表示はできません。

ログインの痕跡を残す

ではどうしたら、ということですが、手軽に思いつくのは script や screen コマンドなどを使ってログインしなおすことです。

$ script

ただしこれは自己申告のようなものなので、実行し忘れたり、あえて実行しないで隠れているなどのことは可能です（それにどんな意味があるかまでは、ここではふれません）。またもちろん、script コマンドや screen コマンドが動作していることの影響（副作用？）も考慮する必要があるので、手放しでお勧めできるものではありません。

まとめ：セッションマネージャの使いどころ

以上のことを踏まえると、セッションマネージャを SSH ログインの完全な置き換えと考えるのは難しいです。個人的な意見ですが日常的に EC2 へログインするような場面ではなく、上述のような事柄をふまえた上で、一時的にシェル操作が必要な場面に限定して使うのが いまのところは良いのではないかと思いました。

例えばですが、普段必要が無いために SSHd を落としておく環境の一時的なメンテナンスのためや、ec2-user で SSH ログインできなくなった時にシステム管理者が SSH 公開鍵を置き直すときなどにはとても有効だと思います。あくまで 「AWS上に」証跡を残しつつ EC2 上でインタラクティブな操作を行う手段 と捉えると良いのではないでしょうか。

ただしそのためには、普段から使えるように設定しておくことが大切です。権限等に気をつけた上で是非ともご検討ください。

なおアナウンスによると、現在「インバウンドポートを開くことなく、セッションマネージャーの上に、SSH セッションを作成」する機能が開発中とのことですので、こちらがリリースされればこういった問題は解消しているかも知れません。楽しみですね！