AWS Session Manager を利用してSSH 接続以外でAzure 仮想マシンへ接続する。

はじめに

Azureで仮想マシンへの接続に対してネイティブサービスではSSH 以外で接続することができません。Azure Bastionでも結局のところはSSHで接続は捨てることができません。あくまでも踏み台という立ち位置です。

そこで、AWS Systems Manager Session Manager を利用します。Session Manager ではオンプレミスインスタンス管理が行えます。この機能を利用します。

ただし、EC2の管理とはことなりSystems Manager アドバンスドインスタンスへアカウントレベルを変更にする必要があり、これは従量課金制になっています。

: 料金 - AWS Systems Manager | AWS

AWS Systems Manager の機能の大部分は、追加料金なしで利用できます。制限が適用される場合があります。残りの機能については、最低料金や前払いの義務はなく、使用した分だけお支払いいただき ...

aws.amazon.com

従量課金制ではあるものの1時間単位で変更して課金を節約することが可能です。これは常時立ち上げが必要となるAzure Bastion では行えないところでもあります。

Azure環境をオンプレミスに見立てただけです。ドキュメントに沿って設定を行っていきます。

: ハイブリッドおよびマルチクラウド環境に Systems Manager をセットアップする - AWS Systems Manager

ハイブリッドおよびマルチクラウド環境で使用する非 EC2 マシンを設定および管理するために Systems Manager をセットアップします。

docs.aws.amazon.com

構成としてはAzureへの接続管理はSession Managerが行います。仮想マシンにはSSM Agentをインストールする必要があります。当然これらの経路もTLS1.2による暗号化がなされています。

前提

検証にあたり以下の環境が前提として必要になります。

AWSのアカウントがあること
Azureのアカウントがあること
クライアント側でAWS CLIがセットアップされて、CLIによるアクセスが可能であること

: AWS CLIの最新バージョンのインストールまたは更新 - AWS Command Line Interface

AWS CLI をシステムにインストールまたはアップデートする手順。

docs.aws.amazon.com

AWS Systems Managerの設定

Systems Managerでハイブリッドアクティベーションを行う必要があります。これはリージョンに対して行われます。ap-northeast-1で設定しています。

とりあえず1台だけ接続するので、そのままの設定でアクティベーションを行います。実行ロールも作成されるように設定されています。

作成が完了するとActivation CodeとActivation IDが発行されるのでコピーしておきます。これはSSM Agentを設定するために利用されます。

新しいアクティベーションが正常に作成されました。アクティベーションコードを以下に記載します。このコード、IDに再度確認することはできないため、コピーして安全な場所に保存してください。
Activation Code xxxxxxxxxxxxxxxxxxx

Activation ID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

次に仮想マシンでSSM Agentをインストールします。

仮想マシンの設定

仮想マシンを起動し、SSM Agentをインストールします。検証用はUbuntuを利用しています。

検証のため外部からのアクセスを行う必要がありパブリックIPアドレスは付与していますが、VNET内からアクセスできる場合には付与する必要はありません。

SSM Agentがドキュメントに従いインストールします。

: ステップ 3: ハイブリッドおよびマルチクラウド環境 (Linux) に SSM Agent をインストールする - AWS Systems Manager

ハイブリッドおよびマルチクラウド環境の非 EC2 Linux マシンに SSM Agent をインストールします。

docs.aws.amazon.com

インストールにはdebパッケージを利用しています。activation-cod、activation-idは上記で確認したコードとIDを入力します。regionはアクティベーションを行ったap-northeast-1です。

mkdir /tmp/ssm
curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/debian_amd64/amazon-ssm-agent.deb -o /tmp/ssm/amazon-ssm-agent.deb
sudo dpkg -i /tmp/ssm/amazon-ssm-agent.deb
sudo service amazon-ssm-agent stop
sudo -E amazon-ssm-agent -register -code "activation-code" -id "activation-id" -region "region" 
sudo service amazon-ssm-agent start

実行結果

root@vm1:~# mkdir /tmp/ssm
root@vm1:~# curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/debian_amd64/amazon-ssm-agent.deb -o /tmp/ssm/amazon-ssm-agent.deb
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 29.4M  100 29.4M    0     0  61.3M      0 --:--:-- --:--:-- --:--:-- 61.2M
root@vm1:~# sudo dpkg -i /tmp/ssm/amazon-ssm-agent.deb
Selecting previously unselected package amazon-ssm-agent.
(Reading database ... 60359 files and directories currently installed.)
Preparing to unpack /tmp/ssm/amazon-ssm-agent.deb ...
Preparing for install
-> Systemd detected
active
Failed to stop amazon-ssm-agent.service: Unit amazon-ssm-agent.service not loaded.
Unpacking amazon-ssm-agent (3.2.582.0-1) ...
Setting up amazon-ssm-agent (3.2.582.0-1) ...
Starting agent
Created symlink /etc/systemd/system/multi-user.target.wants/amazon-ssm-agent.service → /lib/systemd/system/amazon-ssm-agent.service.
root@vm1:~# sudo service amazon-ssm-agent stop
root@vm1:~# sudo -E amazon-ssm-agent -register -code "xxxxxxxxxxxxxxxxxxx" -id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" -region "ap-northeast-1"
Error occurred fetching the seelog config file path:  open /etc/amazon/ssm/seelog.xml: no such file or directory
Initializing new seelog logger
New Seelog Logger Creation Complete
2023-02-18 13:44:30 WARN Could not read InstanceFingerprint file: InstanceFingerprint does not exist
2023-02-18 13:44:30 INFO No initial fingerprint detected, generating fingerprint file...
2023-02-18 13:44:31 INFO Successfully registered the instance with AWS SSM using Managed instance-id: mi-0459cca9688f0a039
root@vm1:~# sudo service amazon-ssm-agent start

完了するとSession Managerで登録されたことがわかります。

仮想マシンに接続する

確認のためAWSコンソールからセッションを開始してみたいと思います。

フリートマネージャー、もしくはセッションマネージャーの画面からセッションを開始してみます。

セッションを開始するためには、アドバンスドインスタンスティアの有効化を行う必要かあり設定の変更のダイアログが表示されます。有効化します。有効化により課金が開始されることに注意してください。

有効化を確認したらセッションを再度開始します。

セッションが開始されると「$」だけが表示されるの bash を実行します。見慣れたAzureの仮想マシンにSSHで接続したときの画面になります。ただし接続ユーザーがssm-userになっていることに注意しましょう。

以上、ブラウザでのセッションの確立が確認出来ました。

次にAWS CLIで接続してみましょう。検証ではWSLから接続を行っています。インスタンスIDはセッションマネージャーの画面で確認できるものです。

aws ssm start-session --target "インスタンス ID"

実行結果

root@DESKTOP-FI2UMJO:~# aws ssm start-session --target mi-0459cca9688f0a039

Starting session with SessionId: azureuser-0bc6c5a59d3eb4e67
$ bash
ssm-user@vm1:/usr/bin$ sudo -i
root@vm1:~# ll
total 36
drwx------  6 root root  4096 Feb 18 14:10 ./
drwxr-xr-x 19 root root  4096 Feb 18 13:09 ../
drwx------  2 root root  4096 Feb 18 13:45 .aws/
-rw-------  1 root root   412 Feb 18 14:01 .bash_history
-rw-r--r--  1 root root  3106 Oct 15  2021 .bashrc
drwxr-xr-x  2 root mdatp 4096 Feb 18 14:10 .osquery/
-rw-r--r--  1 root root   161 Jul  9  2019 .profile
drwx------  2 root root  4096 Feb 18 13:09 .ssh/
-rw-r--r--  1 root root     0 Feb 18 13:43 .sudo_as_admin_successful
drwx------  3 root root  4096 Feb 18 13:09 snap/
root@vm1:~#

問題なく仮想マシンに接続できていることがわかります。

課金の停止

課金を停止するためにはアドバンスドインスタンスティアからスタンダードインスタンスティア（標準インスタンス）に変更する必要があります。

AWSコンソールではフリートマネージャーで行うことができます。インスタンス枠の設定で行います。

ダイアログが表示されるので同意して変更します。

同様にアドバンスドインスタンスティアに変更も行えます。

AWSコンソールで変更は都度ログインが必要なので面倒です。そこでCLIで行ってみます。

update-service-settingで変更することができます。

スタンダードインスタンスティアへの変更、ARNのリージョンやアカウントIDは環境に合わせて変更してください。

aws ssm update-service-setting --setting-id arn:aws:ssm:ap-northeast-1:xxxxxxxxxxxx:servicesetting/ssm/managed-instance/activation-tier --setting-value standard

特に変更されたことは表示されません。get-service-setting で確認します。ドキュメントなどには30後ぐらいに確認してくださいとありますが5分もかからず反映されていたように思います。

aws ssm get-service-setting --setting-id arn:aws:ssm:ap-northeast-1:xxxxxxxxxxxx:servicesetting/ssm/managed-instance/activation-tier

実行結果

SettingValueがstandardになっていることが確認できれば課金は停止されます。

{
    "ServiceSetting": {
        "SettingId": "/ssm/managed-instance/activation-tier",
        "SettingValue": "standard",
        "LastModifiedDate": "2023-02-19T01:30:22.099000+09:00",
        "LastModifiedUser": "arn:aws:iam::xxxxxxxxxxxx:user/azureuser",
        "ARN": "arn:aws:ssm:ap-northeast-1:xxxxxxxxxxxx:servicesetting/ssm/managed-instance/activation-tier",
        "Status": "Customized"
    }
}

アドバンスドインスタンスティアに変更する

aws ssm update-service-setting --setting-id arn:aws:ssm:ap-northeast-1:xxxxxxxxxxxx:servicesetting/ssm/managed-instance/activation-tier --setting-value advanced

仮想マシンへの接続が必要な場合にadvancedに変更し、終わったらstandardに戻す運用を行えば費用の節約になります。

閉域網

Session Managerは閉域網に構築された環境への接続でも利用できます。

例えばパブリックIPアドレスやポートが開いていない状態でもSSM Agentが設定されているのであれば接続可能です。

これはAzure仮想マシンではパブリックIPアドレスを設定しなくても外部接続が利用できる既定のアウトバウンドアクセスの仕様によるものです。NATなども必要ありません。

: Azure での既定の送信アクセス - Azure Virtual Network | Microsoft Learn

Azure での既定の送信アクセスについて説明します。

learn.microsoft.com

まとめ

Azureでは簡単に実現できないSSH接続の断捨離ですが、AWS Systems Manager Session Managerを利用することで実現できます。AWS Systems Manager Session ManagerはAWSだけでなく、AzureやGoogle Cloud、オンプレミスなどへのSSH接続の代わりとなり一括で管理できるようになります。

Session Managerが利用できるようになった時からこのような使い方ができることは確認していましたが、面倒だったので意外とだれも記事にしないので。オンプレミス接続系の仕組みは色々と応用が利くので面白いと思います。

2024年4月
月	火	水	木	金	土	日
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

AWS Session Manager を利用してSSH 接続以外でAzure 仮想マシンへ接続する。

はじめに

料金 - AWS Systems Manager | AWS

ハイブリッドおよびマルチクラウド環境に Systems Manager をセットアップする - AWS Systems Manager

前提

AWS CLIの最新バージョンのインストールまたは更新 - AWS Command Line Interface

AWS Systems Managerの設定

仮想マシンの設定

ステップ 3: ハイブリッドおよびマルチクラウド環境 (Linux) に SSM Agent をインストールする - AWS Systems Manager

実行結果

仮想マシンに接続する

実行結果

課金の停止

閉域網

Azure での既定の送信アクセス - Azure Virtual Network | Microsoft Learn

まとめ