利用AWS SSM Session Manager實現無公網IP、無密鑰安全登錄EC2

在傳統的雲服務器運維里,要登錄一台 Linux EC2,標準配置通常是:給服務器綁定一個公網 IP(或者走 NAT 網關),在安全組上放行

TCP:22

端口,然後本地配置好 SSH 密鑰(

. Pem

文件),最後通過終端連上去。

但這套跑了十幾年的標準流程,在現代企業級安全規範下,正面臨巨大的挑戰:

公網裸奔風險:只要開了 22 端口,不管你改不改默認端口,每天都會有成千上萬個黑客腳本在瘋狂掃描、暴力破解。

密鑰管理災難:密鑰文件一旦分發給多個開發或運維,極易發生員工離職未銷毀、密鑰不小心誤傳到公共 GitHub 的重大安全事故。

成本高昂:為了不給服務器配公網 IP,很多團隊不得不花錢搭堡壘機(Jumpbox)或者配置複雜的 VPN 隧道,增加了不小的日常預算。

在 AWS 體系裡,有一個堪稱降維打擊的免費高級玩法,能完美幹掉上面所有的痛點,它叫

AWS Systems Manager Session Manager(會話管理器)

。

今天不扯複雜的安全理論。 手把手帶你配通全流程,實現

服務器不需要公網 IP、安全組不需要開任何端口、本地不需要任何 . Pem 密鑰文件

,就能穩穩登錄 EC2 終端。

第一階段:深度拆解,session Manager 的「反向連接」黑科技

為什麼不需要公網 IP 和 22 端口,我們還能遠程連上服務器?

傳統的 SSH 登錄是

正向連接

:你的電腦作為客戶端,主動穿過公網,去敲 EC2 伺服器的 22 端口大門。 這就要求服務器必須有公網入口,大門必須敞開。

Session Manager 採用的是

反向連接

邏輯:

你的 EC2 伺服器內部,安裝了一個叫 SSM Agent 的官方小守護進程。

這個進程不需要外部流量進來,它自己會主動由內向外(Outbound),通過 HTTPS(443 端口)跟 AWS 官方的 SSM 服務端建立一個安全的雙向持久長連接。

當你登錄 AWS 控制台或者通過本地 AWS CLI 想要連接服務器時,你的請求先發給 AWS SSM 服務端,服務端再通過剛才那條早已建好的內網管道,把指令傳給 EC2 內部的 Agent 執行。

核心安全結論:因為流量全是由內向外發的,你的 EC2 安全組入站規則可以完

全清空(徹底關閉所有入站端口),連黑客拿探測器都找不到你服務器的存在,安全直接拉滿。

第二階段:實戰演練一--賦予 EC2 說話的權利(IAM 角色配置)

EC2 要想主動去連 AWS 的 SSM 服務端,它必須獲得你的授權。 在 AWS 里,給資源授權的唯一通行證叫

IAM Role(身份與訪問管理角色)

。

登錄 AWS 控制台,搜索並進入 IAM 服務。

點擊左側菜單「角色(Roles)」 -> 「創建角色(Create role)」。

受信實體類型選擇「AWS 服務」,服務或用例選擇 EC2。 點擊下一步。

添加權限策略(關鍵點):在搜索框裡輸入 AmazonSSMManagedInstanceCore(這是 AWS 官方專門為 Session Manager 定製的最小化核心權限策略),勾選它。

點擊下一步,給角色起個名字,比如 EC2-SSM-Access-Role,點擊創建。

第三階段:實戰演練二--啟動一台「全面封閉」的私有 EC2

地基打好了,我們現在去拉起一台伺服器做真實測試。

進入 EC2 控制台,點擊「啟動實例」。

系統鏡像(AMI):強烈建議選擇最新的 Amazon Linux 2023 或 Amazon Linux 2。 避坑提示:這兩款系統默認已經內置安裝並開機自啟了 SSM agent,不需要你再手動敲命令去裝。 如果你選的是原生的 Ubuntu 或 CentOS,啟動後需要自己用 apt 或 yum 手動裝一下 SSM Agent 軟件。

實例類型:隨便選個免費級別的 t3.micro。

密鑰對(Key pair):直接在下拉菜單里選擇 「在沒有密鑰對的情況下繼續」(真正體驗無密鑰登錄的爽快)。

網絡設置(成本與安全精算):自動分配公網 IP:選擇 「禁用」。 我們不需要公網 IP。 安全組入站規則:把默認帶的「允許 SSH 22 端口」那條規則直接點擊垃圾桶刪掉。 保持入站規則空空如也。

高級詳細信息(注入靈魂):往下翻,找到 「IAM 實例配置文件(IAM instance profile)」。 下拉菜單里,精準選中我們在第二階段創建好的 EC2-SSM-Access-Role。

點擊啟動實例。

第四階段:見證奇蹟的時刻--三種高能登錄方式

服務器啟動 2~ 3 分鐘後,確保底層的 SSM Agen

T 已經成功和雲端接上頭。 我們來看怎麼進去系統。

方式一:控制台一鍵直達(懶人最愛)

在 EC2 實例列表里,選中你剛剛建好的那台無公網、無端口的服務器。

點擊頂部的 「連接(Connect)」。

切換到 「會話管理器(Session Manager)」 標籤頁(你會發現由於配置正確,原本灰色的「連接」按鈕已經亮起)。

點擊「連接」。 瀏覽器會瞬間彈出一個純黑色的原生終端,你已經是 ssm-user 權限了,執行 sudo su - 直接提權到 root 完美控盤。

方式二:本地終端直接連(專業運維流)

很多資深運維不喜歡用瀏覽器寫代碼,習慣了本地的本地終端(如 Mac Terminal、iTerm2 或 Windows PowerShell)。 沒問題,Session Manager 同樣支持。

確保你本地電腦安裝了 AWS CLI 工具,並且通過 aws configure 配置好了你個人的 IAM 訪問密鑰。

本地電腦需要額外裝一個免費的小插件叫 Session Manager plugin(去 AWS 官網下載對應操作系統的安裝包,一步無腦安裝)。

打開你本地的終端,直接敲下這行命令(把實例 ID 換成你自己的):Bashaws ssm start-session --target i-0123456789abcdef0 沒有任何密鑰提示,不需要輸入密碼,一秒鐘後,你的本地終端直接跨越宇宙,接入到了那台沒有公網 IP 的雲服務器內部。

第五階段:企業級高級審計--誰在我的服務器里幹了啥?

如果以為 Session Manager 只是為了圖省事,那就小看 AWS 的大廠規範了。 它真正被金融、證券等高合規要求企業青睞的核心原因,是它自帶

完美的無死角審計流水線

。

傳統的 SSH 登錄,開發人員連進去刪了什麼文件、改了什麼配置,除非你在系統內部大費周章地配日誌轉儲,否則很難追查。

在 AWS Systems Manager 的設置里,你可以配置將會話日誌直接開啟投遞:

投遞到 S3 存儲桶:用戶在終端里敲下的每一行命令、屏幕上打印出的每一個字符(包含退格、報錯),都會被實時錄製成加密文本文件,上傳到 S3 永久封存。

投遞到 CloudWatch Logs:實現實時日誌告警。

即使某個擁有最高權限的運維在服務器里執行了

r

M -rf

,他也沒辦法刪掉已經飛到 S3 審計桶里的鐵證。 誰做的操作,什麼時間做的,一查便知,滿足最嚴格的合規審計要求。

第六階段:日常運維的避坑血淚史

連接提示「實例未註冊或未在線」:新拉起伺服器後,如果發現控制台連接按鈕是灰色的,99% 是因為你的私有子網(Private Subnet)完全斷網了。 雖然 SSM Agent 是由內向外發請求,但如果你的私有子網既沒有配置 NAT 網關,也沒有配置 VPC Endpoints(終端節點),agent 連 AWS 官方域名的 HTTPS 流量都發不出,就會徹底失聯。 確保私有網絡至少能連通 AWS 服務的公網域名,或者在 VPC 內新建 ssm、ssmmessages、ec2messages 這三個 VPC 終端節點。

權限卡得太死導致團隊無法協作:session Manager 不再認 . Pem 文件,它認的是個人的 AWS IAM 用戶權限。 如果想讓新來的開發小張能登錄這台機器,你需要在 IAM 裡給他個人的賬號追加一條允許對該 EC2 實例執行 ssm:startSession 的策略。 用 IAM 徹底取代物理密鑰的分發,才是現代雲原生的正道。

總結

利用 AWS SSM Session Manager 登錄 EC2,本質上是用

現代身份認證(IAM)取代了古老的網絡認證(22端口與物理密鑰)

。 用好這套免費的黑科技,不僅能幫你砍掉不必要的堡壘機和公網 IP 預算,更能讓你的雲端基礎設施在公網上「瞬間隱身」。 安全與便利兼得,這才是優雅、地道的雲上運維標準姿勢。