【AWS】RDPポートを開けずにEC2のWindows Serverへ接続する｜aws login＋SSMをワンクリック化

スポンサーリンク
AWS
スポンサーリンク

AWS上のEC2に構築したWindows Serverに、手元のPCからリモートデスクトップ(RDP)で接続したい。ただ、RDPの3389番ポートをインターネットに向けて開けるのは避けたい。そこで、AWS Systems Manager(SSM)のSession Managerにあるポートフォワーディングを使って接続することにした。

この方法自体は以前からあるが、毎回「認証して、長いコマンドを打って、リモートデスクトップを起動して…」とやるのは地味に面倒だ。そこで、ダブルクリック一発でRDP接続まで終わるバッチを作った。認証には、AWS CLIに新しく追加されたaws loginを使っている。アクセスキーをPCに保存しなくていいのが気に入っている。

以前、Tailscaleでポート開放なしに自宅PCへ接続する記事を書いたが、今回はそのAWS版のような話だ。

この方法のメリット

  • セキュリティグループで3389番を開けなくていい。EC2側のインバウンドの許可は不要
  • 踏み台サーバーやVPNを用意しなくていい
  • aws loginを使えば、アクセスキーを発行してPCに保存しなくていい
  • バッチにしておけば、接続はダブルクリックだけで済む

環境と構成

  • 手元のPC: Windows 11
  • AWS CLI 2.33.22
  • Session Manager plugin 1.2.779.0
  • 接続先: EC2(東京リージョン)上のWindows Server

構成はこうなる。手元のリモートデスクトップは自分のPCの13389番につなぐだけで、その先はSSMのトンネルを通ってEC2の3389番に届く。

手元のPC
  リモートデスクトップ(mstsc) → localhost:13389
      ↓
  Session Manager plugin(aws ssm start-session)
      ↓ HTTPS(443)の暗号化されたトンネル
AWS Systems Manager
      ↓
EC2(Windows Server)のSSM Agent → 3389番(RDP)

EC2側からはSSMへ外向きに通信するだけなので、外からEC2へ入ってくる通信を許可する必要がない。これがポートを開けずに済む理由だ。

事前に必要なもの

EC2側

  • SSM Agentが動いていること(AWSが提供するWindows ServerのAMIなら最初から入っている)
  • インスタンスに、Systems Managerを使うための権限を持つIAMロールが付いていること(次の節で説明する)
  • EC2からSSMのエンドポイントへ通信できること(インターネットへ出られるか、VPCエンドポイントがあること)

Systems Managerのコンソールの「フリートマネージャー」に対象のインスタンスが表示されていれば、EC2側の準備はできている。

手元のPC側

  • AWS CLI v2(aws loginはバージョン2.32.0以降が必要)
  • Session Manager plugin(AWS CLIとは別にインストールが必要)

入っているかどうかは、次のコマンドで確認できる。

aws --version
session-manager-plugin --version

必要なIAMポリシー

権限は、EC2に付けるIAMロールと接続する人(IAMユーザー)の2か所に必要になる。どちらも、手早く済ませるならAWS管理ポリシーを付ければいいし、権限を絞りたいならカスタムポリシーを作る。

付ける先 AWS管理ポリシーで済ませる カスタムポリシーで絞る
EC2のIAMロール AmazonSSMManagedInstanceCore ssm:UpdateInstanceInformation
ssmmessages:CreateControlChannel
ssmmessages:CreateDataChannel
ssmmessages:OpenControlChannel
ssmmessages:OpenDataChannel
IAMユーザー(aws login) SignInLocalDevelopmentAccess signin:AuthorizeOAuth2Access
signin:CreateOAuth2Token
IAMユーザー(Session Manager) AmazonSSMFullAccess(強すぎるので非推奨) ssm:StartSession(対象: 接続先のインスタンスとAWS-StartPortForwardingSessionドキュメント)
ssm:TerminateSession
ssm:ResumeSession
ssmmessages:OpenDataChannel(対象: 自分のセッション)

以下のカスタムポリシーは、AWSの公式ドキュメントのサンプルをもとに、今回の用途に合わせて組み立てたものだ。環境によって必要な権限が変わることもあるので、使うときはまず検証用のユーザーで動作を確かめてほしい。

EC2に付けるIAMロール

AWS管理ポリシーならAmazonSSMManagedInstanceCoreを付ける。Session Managerだけでなく、Run CommandなどSystems Manager全般の基本機能に必要な権限がまとまっている。Systems Managerを他の用途にも使うなら、これでいい。

Session Managerだけでいいなら、カスタムポリシーで次の5つのアクションに絞れる。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:UpdateInstanceInformation",
        "ssmmessages:CreateControlChannel",
        "ssmmessages:CreateDataChannel",
        "ssmmessages:OpenControlChannel",
        "ssmmessages:OpenDataChannel"
      ],
      "Resource": "*"
    }
  ]
}

ssm:UpdateInstanceInformationは、EC2のSSM AgentがSystems Managerに自分の状態を報告するための権限だ。ssmmessages:CreateControlChannel・ssmmessages:CreateDataChannel・ssmmessages:OpenControlChannel・ssmmessages:OpenDataChannelの4つは、セッションの通り道(チャネル)を作って開くための権限になる。セッションのログをS3やCloudWatch Logsに保存したり、KMSで暗号化したりしている場合は、その分の権限も追加で必要になる。

接続する人(IAMユーザー):aws login用

aws loginを使うには、AWS管理ポリシーのSignInLocalDevelopmentAccessを付ける。中身は次の2つのアクションだけなので、カスタムポリシーにする場合も同じものを書けばいい。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "signin:AuthorizeOAuth2Access",
        "signin:CreateOAuth2Token"
      ],
      "Resource": "arn:aws:signin:*:*:oauth2/public-client/*"
    }
  ]
}

1つ目はブラウザでの認証で認可コードを受け取る権限、2つ目はそのコードをCLI用のトークンと交換する権限だ。リソースの末尾がlocalhostなら同じPCでaws loginする場合、remoteならaws login --remoteで別の端末のブラウザを使う場合に対応する。同じPCでしか使わないなら、リソースをarn:aws:signin:*:*:oauth2/public-client/localhostに絞ってもいい。

接続する人(IAMユーザー):Session Manager用

Session Managerを使う側には、ちょうどいいAWS管理ポリシーがない。AmazonSSMFullAccessでも足りるが、Systems Managerのあらゆる操作ができてしまうので、検証用の環境以外ではおすすめしない。次のようなカスタムポリシーを作るのがいい。アカウントID・リージョン・インスタンスIDは自分の環境に合わせて書き換える。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "StartPortForwardingToTarget",
      "Effect": "Allow",
      "Action": "ssm:StartSession",
      "Resource": [
        "arn:aws:ec2:ap-northeast-1:123456789012:instance/i-xxxxxxxxxxxxxxxxx",
        "arn:aws:ssm:ap-northeast-1::document/AWS-StartPortForwardingSession"
      ],
      "Condition": {
        "BoolIfExists": {
          "ssm:SessionDocumentAccessCheck": "true"
        }
      }
    },
    {
      "Sid": "ManageOwnSessions",
      "Effect": "Allow",
      "Action": [
        "ssm:TerminateSession",
        "ssm:ResumeSession",
        "ssmmessages:OpenDataChannel"
      ],
      "Resource": "arn:aws:ssm:*:*:session/${aws:username}-*"
    }
  ]
}

1つ目のブロックでは、セッションを開始できる相手を接続先のインスタンスとポートフォワーディング用のドキュメント(AWS-StartPortForwardingSession)だけに絞っている。このドキュメントはAWSが用意したものなので、ARNにアカウントIDが入らない(::になる)。条件のssm:SessionDocumentAccessCheckは、--document-nameを省略して普通のシェルのセッションを開こうとしたときにも、ドキュメントの権限チェックを効かせるためのものだ。これで、このユーザーはEC2にシェルでは入れず、ポートフォワーディングしかできなくなる。

2つ目のブロックは、自分が開始したセッションだけを終了・再開できるようにするものだ。IAMユーザーで接続すると、セッションIDは「IAMユーザー名-ランダムな文字列」になる。私の環境でも、SSMのウィンドウに表示されたセッションIDはIAMユーザー名で始まっていた。そこで${aws:username}で絞っている。

ちなみに、バッチの最初で使っているaws sts get-caller-identityは、権限がなくても必ず実行できるAPIなので、ポリシーに書く必要はない。

aws loginで認証する

aws loginは、AWSマネジメントコンソールにサインインするのと同じ認証情報で、AWS CLI用の一時的な認証情報を発行してくれるコマンドだ。これまでCLIを使うには、アクセスキーを発行してcredentialsファイルに保存するのが一般的だったが、それが不要になる。

aws login --profile aws-dev

新しいプロファイルの場合は、最初にリージョンを聞かれる。そのあとブラウザが自動で開き、ターミナルには次のように表示される(下はバッチから実行したときの画面だが、aws loginを直接実行しても同じだ)。

aws loginを実行したときのターミナル。ブラウザでサインインページを開いている旨と、開かない場合のURLが表示されている

ブラウザには次の画面が出る。「Continue to sign in」を押すとサインイン画面に進む。別のタブで既にコンソールにサインインしていれば、「Refresh」を押してそのセッションを使うこともできる。

ブラウザに表示されるSign in to AWSの画面。Continue to sign inボタンとRefreshボタンがある

あとは、いつもコンソールにサインインするのと同じように、アカウントID・IAMユーザー名・パスワードを入れてサインインする。

IAMユーザーのサインイン画面。アカウントID、IAMユーザー名、パスワードを入力する

サインインが終わると、.aws\configに次のようなプロファイルが書き込まれる。

[profile aws-dev]
login_session = arn:aws:iam::123456789012:user/<ユーザー名>

一時認証情報は15分ごとに自動で更新され、セッション自体はIAM側で設定された時間(最大12時間)まで有効だ。切れたらもう一度aws loginすればいい。ちゃんとログインできているかは、次のコマンドで確認できる。

aws sts get-caller-identity --profile aws-dev

まずは手動で接続してみる

バッチにする前に、手動でつながることを確認しておく。ポートフォワーディングは次のコマンドで始まる。--targetには接続先のインスタンスIDを指定する。

aws ssm start-session --target i-xxxxxxxxxxxxxxxxx --document-name AWS-StartPortForwardingSession --parameters "portNumber=3389,localPortNumber=13389" --profile aws-dev --region ap-northeast-1

Port 13389 opened for sessionId ...、Waiting for connections...と表示されれば準備完了だ。この画面は開いたままにして、リモートデスクトップでlocalhost:13389に接続する。

mstsc /v:localhost:13389

接続すると資格情報を聞かれるので、EC2のWindows Serverのユーザー名とパスワードを入れる。接続先はlocalhostと表示されるが、実際にはEC2につながる。「このアカウントを記憶する」にチェックを入れておけば、次回から入力を省ける。

リモートデスクトップの資格情報の入力画面。localhostへの接続に使用されますと表示されている

手元側のポートを3389ではなく13389にしているのは、手元のPC自身の3389番とぶつからないようにするためだ。空いていれば番号は何でもいい。

ワンクリックで接続するバッチ

ここまでの手順を1本のバッチにまとめた。冒頭の設定部分を自分の環境に合わせて書き換えるだけで使える。

なお、このバッチはaws loginの認証情報をPCに残したままにする。権限の強いアカウントで使う場合や、AIエージェントなどにもコマンドを実行させているPCで使う場合は、後半の「参考:認証情報をPCに残さないバージョン」の方を使ってほしい。

@echo off
setlocal

rem ===== Settings =====
set PROFILE=aws-dev
set REGION=ap-northeast-1
set INSTANCE_ID=i-xxxxxxxxxxxxxxxxx
set LOCAL_PORT=13389
set REMOTE_PORT=3389
rem ====================

rem 1. Check credentials (run aws login if expired)
aws sts get-caller-identity --profile %PROFILE% --region %REGION% >nul 2>&1
if errorlevel 1 (
    echo [INFO] Session expired. Running aws login...
    aws login --profile %PROFILE% --region %REGION%
    if errorlevel 1 (
        echo [ERROR] aws login failed.
        pause
        exit /b 1
    )
)

rem 2. Start port forwarding (skip if already listening)
netstat -an | findstr /r /c:"127.0.0.1:%LOCAL_PORT% .*LISTENING" >nul
if not errorlevel 1 (
    echo [INFO] Port %LOCAL_PORT% already listening. Reusing existing session.
    goto CONNECT
)
echo [INFO] Starting SSM port forwarding...
start "SSM-RDP %INSTANCE_ID% - close to disconnect" cmd /k aws ssm start-session --target %INSTANCE_ID% --document-name AWS-StartPortForwardingSession --parameters "portNumber=%REMOTE_PORT%,localPortNumber=%LOCAL_PORT%" --profile %PROFILE% --region %REGION%

rem 3. Wait for the port to open (max 30s)
set /a WAIT=0
:WAITLOOP
netstat -an | findstr /r /c:"127.0.0.1:%LOCAL_PORT% .*LISTENING" >nul
if not errorlevel 1 goto CONNECT
set /a WAIT+=1
if %WAIT% geq 30 (
    echo [ERROR] Port %LOCAL_PORT% did not open. Check the SSM window for errors.
    pause
    exit /b 1
)
timeout /t 1 /nobreak >nul
goto WAITLOOP

rem 4. Connect via RDP
:CONNECT
echo [INFO] Connecting RDP to localhost:%LOCAL_PORT%
start "" mstsc /v:localhost:%LOCAL_PORT%
exit /b 0

バッチの中のメッセージやコメントを英語にしているのは、文字コードの違いで日本語が文字化けするのを避けるためだ。メモ帳で保存するときも、このままなら文字コードを気にしなくていい。

ダブルクリックすると、次の順に動く。

  1. 認証の確認: aws sts get-caller-identityが失敗したら(=セッションが切れていたら)aws loginを実行する。ブラウザが開くのでサインインすれば先に進む
  2. ポートフォワーディングの開始: 別ウィンドウでSSMのセッションを始める。既に13389番で待ち受け中なら、それをそのまま使う
  3. ポートが開くのを待つ: netstatで13389番の待ち受けを確認する。最大30秒待って開かなければエラーにする
  4. RDP接続: リモートデスクトップをmstsc /v:localhost:13389で起動する(.rdpファイルを使わない理由は後述)

SSMのセッションは「SSM-RDP …」という別ウィンドウで動き続ける。このウィンドウを閉じると接続が切れるので、RDPを使い終わったら閉じればいい。

ハマりポイント1:RDPを閉じると「Default.rdp に保存中にエラーが発生しました」と出る

接続自体は問題なくできたが、RDPを閉じたところで「ファイル C:\Users\<ユーザー名>\Documents\Default.rdp に保存中にエラーが発生しました」というエラーが出た。

RDPを閉じたときに表示された、ドキュメントフォルダのDefault.rdpに保存中にエラーが発生しましたというダイアログ

リモートデスクトップは、.rdpファイルを指定せずに起動すると、閉じるときに接続の設定をドキュメントフォルダのDefault.rdpに書き戻す。その書き戻しに失敗している。

最初は、Default.rdpが隠しファイルになっているのが原因かと思った。しかしこれは見当違いで、Default.rdpはリモートデスクトップが普段から隠しファイルとして作るものだ。Windows Defenderのイベントログ(イベントビューアーの「アプリケーションとサービス ログ → Microsoft → Windows → Windows Defender → Operational」)を見ると、ちょうどエラーが出た時刻に、次の記録(イベントID 1123)が残っていた。

C:\Windows\System32\mstsc.exe has been blocked from modifying %userprofile%\Documents\ by Controlled Folder Access.

原因は、Windowsセキュリティの「コントロールされたフォルダーアクセス」だった。ランサムウェア対策の機能で、許可されていないアプリがドキュメントフォルダなどに書き込むのをブロックする。私のPCではこれを有効にしていたので、リモートデスクトップ(mstsc.exe)の書き込みもブロックされていた。

対処として、mstsc.exeを許可するアプリに追加した。Windowsの「設定 → プライバシーとセキュリティ → Windows セキュリティ」を開き、「ウイルスと脅威の防止」を選ぶ。

Windowsセキュリティの保護の領域の一覧。ウイルスと脅威の防止が一番上にある

開いた画面を下にスクロールすると「ランサムウェアの防止」があるので、「ランサムウェア防止の管理」を開く。

ウイルスと脅威の防止の画面にあるランサムウェアの防止の項目と、ランサムウェア防止の管理のリンク

「コントロールされたフォルダー アクセス」がオンになっていることが分かる。ここで「アプリをコントロールされたフォルダー アクセスで許可する」を開く。

ランサムウェアの防止の画面。コントロールされたフォルダーアクセスがオンになっていて、その下にアプリをコントロールされたフォルダーアクセスで許可するのリンクがある

「許可されたアプリを追加する」からC:\Windows\System32\mstsc.exeを選んで追加した。一覧にmstsc.exeが表示されればOKだ。

許可されたアプリの一覧にC:\Windows\System32のmstsc.exeが追加された画面

これでエラーは出なくなった。なお、このエラーは閉じるときに設定を保存できなかったというだけで、接続そのものには影響しない。セキュリティの設定を変えたくなければ、OKを押して閉じるだけでも実害はない。

ハマりポイント2:.rdpファイルで起動すると毎回「警告: 不明なリモート接続」が出る

実は、上の原因にたどり着く前に別の回避策を試していた。「.rdpファイルを指定して起動すれば、Default.rdpには書き戻さないはず」と考えて、バッチと同じフォルダに専用の.rdpファイルを作り、それを開いて接続するように変えたのだ。保存エラーは出なくなったが、今度は接続のたびに「リモート デスクトップ接続のセキュリティ警告」が出るようになった。「警告: 不明なリモート接続」と表示され、公開元は「不明な発行元」になっている。

リモートデスクトップ接続のセキュリティ警告。警告: 不明なリモート接続と表示され、クリップボードなどのリソース共有のチェックがすべて外れている

これは2026年4月のWindowsの更新で追加された、.rdpファイルを悪用したフィッシングへの対策だ。署名されていない.rdpファイルを開くと毎回この警告が出て、クリップボードなどのリソースの共有も既定でオフになる。以前のような「今後このメッセージを表示しない」のチェックボックスも無い。

.rdpファイルに署名すれば警告は消せるが、自分用のバッチのためにそこまでするのは大げさだ。結局、.rdpファイルを使うのはやめてmstsc /v:localhost:13389で起動する形に戻し、保存エラーの方は上のとおり根本原因を解消した。/v:で起動する場合は、この警告は出ない。

複数のインスタンスに接続したいとき

接続先を増やすときは、バッチをコピーして次の部分を書き換える。

  • INSTANCE_ID: 接続先のインスタンスID
  • LOCAL_PORT: 同時につなぐなら、インスタンスごとに別の番号にする(13390など)

参考:認証情報をPCに残さないバージョン

上のバッチでは、aws loginで取得した認証情報が、%USERPROFILE%\.aws\login\cacheにキャッシュとして残る。認証情報はセッションが切れるまで(最大12時間)自動で更新され続け、その間は、同じWindowsユーザーで動いているプログラムならどれでもこの認証情報を使えてしまう。

私が使っているのは権限の強いアカウントで、本来は自分が手で操作するときだけ使いたかった。ところが、このPCではClaude CodeのようなAIエージェントにコマンドを実行させることがある。AIエージェントは、頼んだ作業の延長で、キャッシュに残っている認証情報を使ってAWSを操作できてしまう。強いアカウントの認証情報がPCに残りっぱなしなのはまずいと考えた。

そこで、トンネルが開いた直後にaws logoutするバージョンを作った。SSMで認証情報が必要なのはセッションを開始するときだけで、一度開いたトンネルはログアウトしても使い続けられる。実際に試したところ、ログアウトした後もRDPで普通に操作できた。これで、認証情報がPCに残るのは、ログインしてからトンネルが開くまでの数秒だけになる。

上のバッチとの違いは次のとおりだ。

  • トンネルが開いたら、すぐにaws logoutでキャッシュの認証情報を消す
  • リモートデスクトップをstart /waitで起動し、RDPの画面が閉じられるまで待つ
  • RDPを閉じたら、13389番で待ち受けているプロセス(Session Manager plugin)をnetstat -anoで探して終了させる。これでトンネルが止まり、SSMのウィンドウとバッチのウィンドウも自動で閉じる
  • SSMのウィンドウは必ず自動で閉じるので、エラーは一時フォルダのログファイルに書き出しておき、トンネルが開かなかったときにバッチの画面に表示する
@echo off
setlocal

rem ===== Settings =====
set PROFILE=aws-dev
set REGION=ap-northeast-1
set INSTANCE_ID=i-xxxxxxxxxxxxxxxxx
set LOCAL_PORT=13389
set REMOTE_PORT=3389
rem ====================

set ERRLOG=%TEMP%\ssm-rdp-%LOCAL_PORT%-error.log

rem 1. Check credentials (run aws login if not logged in)
aws sts get-caller-identity --profile %PROFILE% --region %REGION% >nul 2>&1
if errorlevel 1 (
    echo [INFO] Not logged in. Running aws login...
    aws login --profile %PROFILE% --region %REGION%
    if errorlevel 1 (
        echo [ERROR] aws login failed.
        pause
        exit /b 1
    )
)

rem 2. Start port forwarding (skip if already listening)
netstat -an | findstr /r /c:"127.0.0.1:%LOCAL_PORT% .*LISTENING" >nul
if not errorlevel 1 (
    echo [INFO] Port %LOCAL_PORT% already listening. Reusing existing session.
    goto TUNNEL_READY
)
echo [INFO] Starting SSM port forwarding...
rem The SSM window always closes when the tunnel ends. Errors are written to ERRLOG.
start "SSM-RDP %INSTANCE_ID%" cmd /c "aws ssm start-session --target %INSTANCE_ID% --document-name AWS-StartPortForwardingSession --parameters portNumber=%REMOTE_PORT%,localPortNumber=%LOCAL_PORT% --profile %PROFILE% --region %REGION% 2> "%ERRLOG%" & exit 0"

rem 3. Wait for the port to open (max 30s)
set /a WAIT=0
:WAITLOOP
netstat -an | findstr /r /c:"127.0.0.1:%LOCAL_PORT% .*LISTENING" >nul
if not errorlevel 1 goto TUNNEL_READY
set /a WAIT+=1
if %WAIT% geq 30 goto TUNNEL_FAILED
timeout /t 1 /nobreak >nul
goto WAITLOOP

:TUNNEL_FAILED
echo [ERROR] Port %LOCAL_PORT% did not open.
if exist "%ERRLOG%" type "%ERRLOG%"
aws logout --profile %PROFILE% >nul 2>&1
pause
exit /b 1

:TUNNEL_READY
rem 4. Log out right away. The open tunnel keeps working without the cached credentials.
echo [INFO] Tunnel is up. Logging out to remove cached credentials...
aws logout --profile %PROFILE% >nul 2>&1

rem 5. Connect via RDP and wait until the RDP window is closed
echo [INFO] Connecting RDP to localhost:%LOCAL_PORT%
echo [INFO] Do not close this window. It stops the tunnel when RDP is closed.
start "" /wait mstsc /v:localhost:%LOCAL_PORT%

rem 6. Stop the tunnel (the SSM window closes with it)
echo [INFO] RDP closed. Stopping the tunnel...
for /f "tokens=5" %%P in ('netstat -ano ^| findstr /r /c:"127.0.0.1:%LOCAL_PORT% .*LISTENING"') do taskkill /PID %%P /F >nul 2>&1
exit /b 0

注意点もある。

  • 毎回ログアウトするので、接続のたびにブラウザでのログインが必要になる。別のタブでコンソールにサインインしていれば、「Refresh」で済む
  • RDPを使っている間にバッチのウィンドウを閉じると、後片付けが動かずトンネルが残る(認証情報は既に消えている)
  • 途中でネットワークが一瞬切れたとき、トンネルが自動で再接続できない可能性がある。その場合はバッチを実行し直せばいい
  • 既に13389番でトンネルが開いていた場合も、RDPを閉じたときにそのトンネルを止める

権限の弱いアカウントで使うなら上のバッチで十分だが、強いアカウントを使う場合や、AIエージェントなど他のツールも動かしているPCで使う場合は、こちらのバージョンをおすすめする。

まとめ

3389番を開けず、アクセスキーもPCに置かずに、ダブルクリックだけでEC2のWindows Serverにつながるようになった。毎回コマンドを打っていた頃と比べると、接続までの手間がほとんど無くなった。

この記事のまとめ: SSMのポートフォワーディングなら、3389番を開けずにEC2へRDPできる。aws loginを使えば、アクセスキーをPCに保存しなくていい。認証の確認からRDPの起動までをバッチ1本でワンクリック化した。閉じたときのDefault.rdpの保存エラーは、コントロールされたフォルダーアクセスが原因。.rdpファイルで起動すると2026年4月の更新から毎回警告が出るが、/v:で起動すれば出ない。強いアカウントを使うなら、トンネルが開いた直後にaws logoutして認証情報を残さない。

参考: Login for AWS local development using console credentials - AWS CLI、Start a session - AWS Systems Manager、Create a custom IAM role for Session Manager - AWS Systems Manager、Sample IAM policies for Session Manager - AWS Systems Manager、SignInLocalDevelopmentAccess - AWS Managed Policy、Microsoft adds Windows protections for malicious Remote Desktop files - BleepingComputer

スポンサーリンク

コメント

タイトルとURLをコピーしました