如果你也經(jīng)歷過這樣的場景半夜拿到一臺新服務(wù)器初始密碼是一串十六位大小寫加特殊符號的組合在終端里敲三遍錯兩遍第四次終于登進去卻已經(jīng)沒心情干活了——那么SSH免密登錄就是為你準備的解藥。把配置做完之后ssh userhost回車即可密碼、口令、動態(tài)驗證統(tǒng)統(tǒng)不需要就像打開本地終端一樣直接。這篇文章我會把SSH免密登錄從原理到實操、再到常見故障排查的完整鏈路講一遍適合三類人每天要連多臺服務(wù)器做運維的、用VS Code做遠程開發(fā)的、以及寫腳本傳文件卻被密碼交互卡住的人。基本思路不復(fù)雜但我在真實環(huán)境里攢了不少教訓(xùn)這次一并寫出來。1. 為什么要折騰免密登錄從省時間到解鎖新能力1.1 密碼登錄的日常痛苦先說個真實感受。我記得早期做運維那會兒手里管著二十多臺機器每臺機器的密碼都不一樣為了安全還定期輪換。最崩潰的不是記密碼而是你在一條scp命令里需要用密碼在一條自動化腳本里需要密碼在和同事協(xié)作的時候還要把密碼發(fā)來發(fā)去。更別提生產(chǎn)環(huán)境里那些高強度密碼長度十六位起步大小寫數(shù)字特殊符號全占手輸一次等于做一次指法練習(xí)輸錯三次直接觸發(fā)鎖定然后還得找管理員解鎖。我見過不少團隊的做法是寫個expect腳本或者用sshpass自動填密碼。這確實能解決一部分交互問題但代價很明確密碼以明文形式躺在腳本或者歷史記錄里一臺機器被攻破所有機器跟著遭殃。而且一旦統(tǒng)一改密所有腳本全部失效運維工作量成倍上漲。這類方案說白了是在繞著問題走沒有真正解決身份認證這件事。1.2 免密登錄真正解決的三類場景把話說透一點SSH免密登錄的核心價值不是省一次輸入而是解鎖三類高頻場景。第一類是自動化傳輸與執(zhí)行。最典型的就是定時備份你寫了一個crontab腳本每天凌晨用rsync或scp把數(shù)據(jù)從生產(chǎn)機拉到備份機。只要腳本里涉及遠程操作就必須是非交互式的這時候密碼登錄直接出局。配好免密之后腳本里的遠程命令才真正可以無人值守。第二類是遠程開發(fā)。VS Code的Remote-SSH插件、JetBrains的Remote Development本質(zhì)上都是在你本地IDE和遠程服務(wù)器之間建立SSH隧道。體驗好不好很大程度取決于認證流程順不順暢。沒配免密時每次重連窗口都要輸一次密碼配好之后連接遠程工作區(qū)跟打開本地文件夾一樣無感。我在熱搜詞里看到一大串vscode連接ssh遠程服務(wù)器的搜索足以說明大家在這塊的需求很旺盛。第三類是批量運維。你手里有五十臺服務(wù)器要批量查磁盤水位、批量改配置、批量重啟服務(wù)正常做法是用Ansible這類工具或者寫個for循環(huán)串行執(zhí)行SSH命令。這兩種方式都要求認證過程不需要人工介入免密登錄是它們能夠跑起來的地基。1.3 順帶提一個安全認知有人說免密登錄是不是把安全底線放低了恰恰相反。從安全角度看基于密鑰對的認證方式比密碼認證更抗暴力破解——攻擊者猜密碼可以無限嘗試但猜私鑰簽名在計算上不可行。再加上你可以隨時禁用密碼登錄服務(wù)器就幾乎只剩密鑰這一條入口爆破面直接清零。我見過太多服務(wù)器因為開著密碼登錄、密碼又不夠強壯被掃描工具撞庫撞進來的案例。免密登錄配合關(guān)閉密碼認證屬于成本最低的高價值安全操作。2. 免密登錄的運行原理公鑰和私鑰是怎么對上暗號的2.1 非對稱加密一把掛鎖配一把鑰匙要理解SSH免密登錄先得建立非對稱加密的直覺。我習(xí)慣用一個生活化類比公鑰是一把掛鎖私鑰是這把鎖唯一的鑰匙。你把這把掛鎖公鑰交給服務(wù)器服務(wù)器把它掛在門上的許可列表里這個列表就是authorized_keys文件。以后你來敲門服務(wù)器不會問你要密碼而是拿出一把鎖讓你開——你能用私鑰打開它說明你確實是鎖的主人身份驗證通過放行。整個過程里真正值錢的私鑰始終只存在你的本地機器上服務(wù)器手里只有那把鎖別人就算把服務(wù)器硬盤拖走也倒推不出你的私鑰內(nèi)容。這里有個常見誤區(qū)需要糾正很多人以為免密登錄是把密碼存在了服務(wù)器上以后自動比對。不是的。服務(wù)器上存的是公鑰公鑰本身不具備任何機密性公開出去都沒關(guān)系。認證的本質(zhì)是證明你持有對應(yīng)的私鑰而不是告訴服務(wù)器一個秘密。2.2 一次完整的免密登錄是怎么走完的把流程拆開看一共四步。第一步客戶端發(fā)起連接請求告訴服務(wù)器自己想用哪個用戶身份登錄。第二步服務(wù)器讀自己的authorized_keys文件如果里面有客戶端的公鑰就生成一段隨機挑戰(zhàn)數(shù)據(jù)發(fā)給客戶端。第三步客戶端拿到挑戰(zhàn)數(shù)據(jù)后用本地私鑰對這個數(shù)據(jù)做簽名把簽名結(jié)果發(fā)回服務(wù)器。第四步服務(wù)器用之前存好的公鑰驗證這個簽名——如果簽名有效說明私鑰確實在客戶端手里登錄直接放行驗證失敗則退回密碼認證前提是服務(wù)器還開著密碼登錄。這整個過程發(fā)生在SSH建立的加密通道內(nèi)部挑戰(zhàn)和簽名內(nèi)容不會被中間人竊取和重放。而且默認情況下客戶端會優(yōu)先嘗試密鑰認證只有密鑰認證失敗才會落到密碼輸入環(huán)節(jié)。所以你的體驗通常是沒配好密鑰時它問密碼配好之后回車直接進。2.3 密鑰文件到底放在哪里、誰不能碰搞清楚了原理再來看文件落盤的位置這東西是絕大多數(shù)配置翻車點?？蛻舳吮緳C密鑰對默認生成在~/.ssh目錄下。私鑰文件名通常是id_ed25519或id_rsa公鑰對應(yīng)是id_ed25519.pub或id_rsa.pub。私鑰的權(quán)限必須是600僅屬主可讀寫如果權(quán)限放得太開比如組用戶和其他用戶都能讀OpenSSH會直接拒絕使用這個私鑰并報出UNPROTECTED PRIVATE KEY FILE的錯。這一點就是為什么大家在Windows上配置時經(jīng)常碰壁——后面我會專門講。服務(wù)器端公鑰內(nèi)容需要追加寫入目標用戶家目錄下的~/.ssh/authorized_keys文件。這個文件的權(quán)限必須是600~/.ssh目錄的權(quán)限必須是700且這兩個文件的屬主必須是登錄用戶自己。OpenSSH在這里有嚴格的權(quán)限校驗官方說法叫StrictModes默認開啟。它的邏輯很簡單如果.ssh目錄或authorized_keys文件能被其他用戶寫那攻擊者就可以往里面塞自己的公鑰免密登錄就成了后門。所以SSH寧可報錯也不冒險用。搞懂這套文件組織規(guī)則后面排查權(quán)限問題你就能一眼看穿原因。3. 從零配置三步走拿到你的第一次免密登錄3.1 第一步創(chuàng)建密鑰對選對算法和參數(shù)無論你是Linux、macOS還是Windows用戶第一步都在你本地機器上操作。打開終端執(zhí)行ssh-keygen -t ed25519 -C your_email_or_remark-t ed25519指定算法類型-C加上一條注釋方便你以后區(qū)分這把鑰匙是給誰用的。如果你的機器或目標服務(wù)器比較老舊比如仍停留在CentOS 6時代OpenSSH版本可能不支持ed25519那就退一步用RSAssh-keygen -t rsa -b 4096-b 4096指定位長不要用低于2048的位數(shù)。RSA的優(yōu)勢是兼容性極好ED25519的優(yōu)勢是密鑰更短、性能更好、安全性更高。除非有兼容性硬約束否則優(yōu)先ED25519。執(zhí)行后終端會問你要把密鑰保存在哪里默認路徑是~/.ssh/id_ed25519我建議用默認路徑。如果你有多臺服務(wù)器、多個身份想分開管理可以指定別的文件名比如~/.ssh/id_ed25519_company但要記住后面連服務(wù)器時要通過-i參數(shù)或SSH配置指定對應(yīng)私鑰不然客戶端不知道用哪把鑰匙去開門。接下來是兩個關(guān)鍵選項。一是passphrase口令短語它是對私鑰文件的額外加密。我不建議你留空。雖然留空意味著登錄時連一個口令都不用輸?shù)鷥r是任何拿到你這臺機器權(quán)限的人都能直接偷走私鑰。設(shè)置了passphrase后私鑰文件即使泄露沒有口令也解不開。至于設(shè)置了passphrase那不是還是要輸嗎的問題后面講ssh-agent時會有答案。3.2 第二步把公鑰安全地送到服務(wù)器上密鑰對生成完畢后公鑰測試文件和私鑰文件名一致多了一個.pub后綴是文本內(nèi)容可以安全傳輸。Linux和macOS最優(yōu)雅的方式是使用ssh-copy-idssh-copy-id -i ~/.ssh/id_ed25519.pub userserver_ip這條命令會先讓你輸一次服務(wù)器密碼然后把公鑰追加到服務(wù)器上目標用戶家目錄的authorized_keys文件里同時自動處理好目錄權(quán)限。整個過程是一次性付出無限次回報只輸這一次密碼以后就再也不用輸了。Windows用戶沒有原生ssh-copy-id新版PowerShell里其實有但用PowerShell管道也能實現(xiàn)同樣的效果type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh userserver_ip mkdir -p ~/.ssh cat ~/.ssh/authorized_keys這條命令的邏輯是先打印本地公鑰內(nèi)容通過SSH管道傳給服務(wù)器在服務(wù)器上創(chuàng)建.ssh目錄并把公鑰追加進去。執(zhí)行時會要求輸入密碼輸入之后就可以驗證免密登錄了。還有一個土辦法手動登錄服務(wù)器打開~/.ssh/authorized_keys把你本地公鑰文件里的那行文本粘貼進去保存。這招在特殊環(huán)境里最通用但要注意別把公鑰內(nèi)容敲成多行一個公鑰應(yīng)該是單行文本。3.3 第三步權(quán)限檢查最容易翻車的一步公鑰放上去之后建議先手動登錄一次檢查服務(wù)器端權(quán)限chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys如果你的用戶家目錄本身權(quán)限有問題比如組用戶或其他人有寫權(quán)限也可能被OpenSSH拒絕。多用戶Linux服務(wù)器上尤其常見解決方法通常是chmod 755 /home/username。做完權(quán)限檢查后再試一次免密登錄ssh userserver_ip如果直接進入服務(wù)器恭喜你SSH免密登錄已經(jīng)配置成功。如果沒有看下一章我把最高頻的失敗原因和排查鏈路完整列出來。3.4 讓passphrase不再煩人ssh-agent的正確用法在繼續(xù)排查前先解決一個體驗問題如果你在3.1給私鑰設(shè)置了passphrase現(xiàn)在免密登錄時還是會提示輸入passphrase這不是免密沒生效而是系統(tǒng)在解鎖你的私鑰文件。解決方案是ssh-agent。這個程序駐留在你的會話里負責(zé)緩存已解鎖的私鑰。啟動并添加私鑰eval $(ssh-agent -s) ssh-add ~/.ssh/id_ed25519輸入一次passphrase后私鑰就住進agent了之后同一會話內(nèi)的所有SSH連接都不再詢問。macOS自帶鑰匙串集成可以做到開機后只輸一次。Windows上OpenSSH的Agent服務(wù)也會自動處理配合Windows Hello還能做到更沉浸的體驗。這個機制是免密的進階體驗開關(guān)很多人配完免密之后覺得還要輸passphrase很煩其實只是還沒用上agent。4. 免密登錄失敗的完整排查鏈路從權(quán)限錯誤到握手失敗配置免密的流程很簡單但實際踩坑概率不低。我在熱搜詞里看到一堆問vscode連接ssh配置失敗ssh認證失敗ssh連接超時的基本都能歸類到下面四類問題里。這里我把排查思路完整呈現(xiàn)不是讓你照命令一個個敲而是讓你知道先看什么、后看什么、為什么這么排。4.1 bad owner or permissionsWindows用戶的第一個攔路虎熱搜詞里有一條很具體bad owner or permissions on c:\users\thinkpad/.ssh/config。這個錯誤我?guī)腿颂幚磉^太多次幾乎每個用VS Code Remote-SSH連服務(wù)器的Windows用戶都會遇到一次。先說為什么會有這個錯誤。OpenSSH對配置文件和密鑰文件的權(quán)限要求是只能被當(dāng)前用戶讀寫。Windows下用戶目錄下的文件默認會繼承自C:\Users\用戶名的ACL權(quán)限而Windows的權(quán)限模型和Linux略有不同——它往往會帶上Authenticated Users、Users這種組權(quán)限在SSH眼里這就是其他用戶也能訪問于是直接拒絕加載配置文件。排查方法很簡單在PowerShell里執(zhí)行icacls $env:USERPROFILE\.ssh\config你會看到輸出里可能包含NT AUTHORITY\Authenticated Users:(F)或類似條目這就是罪魁禍首。修復(fù)方法是用icacls命令把文件權(quán)限重置為僅當(dāng)前用戶icacls $env:USERPROFILE\.ssh\config /inheritance:r /grant:r $($env:USERNAME):F /remove NT AUTHORITY\Authenticated Users /remove BUILTIN\Users更簡單的做法是直接對.ssh整個目錄處理一次icacls $env:USERPROFILE\.ssh /inheritance:r /grant:r $($env:USERNAME):F執(zhí)行完之后再試連接這個錯誤基本就消失了。同樣的思路也適用于私鑰文件id_ed25519和 known_hosts 文件。本質(zhì)上你只需要記住一句判斷準則任何讓你的SSH私鑰或配置可能被其他用戶讀到的權(quán)限設(shè)置都會被OpenSSH拒絕不管你是Windows還是Linux。4.2 連接超時與Handshake Failed網(wǎng)絡(luò)層和服務(wù)端層的排查順序熱搜詞里有ssh: connect to host 10.180.128.220 port 22: connection timed out也有ssh: handshake failed: eof。前者是網(wǎng)絡(luò)層問題后者是協(xié)議層問題完全不是一回事。我把排查順序固定成這樣效率最高先確認端口能不能通再確認SSH進程有沒有活著最后看認證環(huán)節(jié)。端口不通的排查鏈路是先ping一下目標IP看主機能不能通——注意IP通不代表端口通。接著用telnet或nc測試22端口telnet 10.180.128.220 22 nc -vz 10.180.128.220 22如果端口測試直接失敗別急著看SSH配置先檢查三件事云廠商安全組是否放行了22端口這是現(xiàn)在的頭號嫌疑犯、服務(wù)器本地防火墻firewalld或ufw是否放行、目標機器上sshd服務(wù)是否在運行且監(jiān)聽了正確端口。查看監(jiān)聽狀態(tài)ss -tlnp | grep sshd如果輸出里有0.0.0.0:22或:::22說明sshd在監(jiān)聽。如果端口沒監(jiān)聽啟動服務(wù)systemctl start sshd systemctl enable sshd至于ssh: handshake failed: eof這個錯誤本質(zhì)是SSH連接建立后服務(wù)器在協(xié)議握手階段直接把連接關(guān)了于是你看到EOF。常見原因有兩個其一sshd的配置寫錯了加載失敗后進程退出客戶端收到的就是EOF其二服務(wù)端不兼容你本地的算法或協(xié)議版本。排查第一件事永遠是看服務(wù)端日志。CentOS/RHEL系看/var/log/secureUbuntu看/var/log/auth.log或者直接journalctl -u sshd -n 50順便在服務(wù)器上執(zhí)行sshd -t做一次配置語法檢查這條命令能幫你快速發(fā)現(xiàn)sshd_config里的拼寫或者語法錯誤。我處理過一個案例某同事在sshd_config里寫了兩行重復(fù)的Subsystem配置sshd檢測到?jīng)_突直接拒絕啟動客戶端的表現(xiàn)就是Handshake EOF。4.3 密鑰明明傳上去了卻還是被要求輸密碼第三種高頻問題最讓人窩火公鑰確定放進authorized_keys了權(quán)限也對了但連接時還是要求密碼。我自己早期也在這里卡過很長時間。這類問題的可能原因和排查優(yōu)先級我給你按概率排個序。第一客戶端沒有使用你生成的那把密鑰。如果客戶端手里有多把私鑰SSH默認會嘗試id_rsa、id_ed25519這些默認文件名如果你生成的密鑰用自定義文件名客戶端根本不知道要用它。連接時用-i顯式指定私鑰ssh -i ~/.ssh/id_ed25519_company userserver_ip第二服務(wù)器端SSH配置沒有開啟公鑰認證。檢查/etc/ssh/sshd_configPubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys第三authorized_keys文件的屬主不是登錄用戶。比如你用root身份手動創(chuàng)建了文件然后把文件chown給了普通用戶但文件所在目錄或文件的SELinux上下文沒對也會被拒絕。比較隱蔽的是SELinux場景CentOS等發(fā)行版默認啟用SELinux公鑰文件的上下文如果不對會出現(xiàn)權(quán)限全對但仍被拒的詭異現(xiàn)象。修復(fù)restorecon -Rv ~/.ssh這條命令會把.ssh目錄及其內(nèi)部文件的SELinux上下文恢復(fù)為默認值解決大部分因為cp或重定向創(chuàng)建文件導(dǎo)致的上下文錯亂。第四PasswordAuthentication和PubkeyAuthentication的判定順序問題。即便公鑰認證成功如果服務(wù)器配置有問題也可能靜默跳到密碼認證。想看真實原因永遠用verbose模式連一次ssh -v userserver_ip輸出里會有Authenticated to xxx或Permission denied (publickey,password)這類關(guān)鍵行。前者說明認證完成后者會告訴你服務(wù)器當(dāng)前接受哪些認證方式如果列表里沒有publickey立刻去查sshd_config。4.4 一套可快速落地的排查清單把上面所有排查步驟壓縮成一張表你照著順序過一遍90%的問題都能在十分鐘內(nèi)定位。癥狀優(yōu)先排查方向快速操作提示 bad owner or permissions客戶端文件權(quán)限被其他用戶可讀檢查icacls/chmod讓權(quán)限只屬于當(dāng)前用戶connect timed out網(wǎng)絡(luò)鏈路或防火墻攔截安全組、firewalld/ufw然后用nc測端口handshake failed: eof服務(wù)端sshd掛掉或配置錯誤sshd -t檢查配置看auth日志Permission denied (publickey)密鑰未被識別或未啟用公鑰認證ssh -v查看認證方式列表檢查authorized_keys密鑰傳上去了仍輸密碼authorized_keys內(nèi)容/屬主/SELinux檢查單行公鑰、chown、restorecon這不是理論清單是我在真實排障中反復(fù)驗證過的順序。遇到問題不要慌從最外層網(wǎng)絡(luò)開始往內(nèi)層協(xié)議推進每一層用一條命令確認通常很快就能收口。5. 免密登錄的進階玩法從單臺服務(wù)器到批量運維5.1 VS Code遠程開發(fā)配好免密之后才有的絲滑網(wǎng)上到處是vscode連接ssh遠程服務(wù)器的求助帖其中很大的比例不是不會配而是沒配免密之前每次重連、每次vscode重啟都要輸密碼體驗極其勸退。配好免密后再配合Remote-SSH插件你的IDE和遠程服務(wù)器之間就變成了一條無縫銜接的隧道。遠程打開項目文件夾、編輯代碼、啟動調(diào)試器、跑終端命令和在本地開發(fā)幾乎沒有區(qū)別。具體配置方式安裝Remote-SSH擴展后在VS Code命令面板CtrlShiftP里輸入Remote-SSH: Connect to Host選擇或填寫userserver_ip。你會發(fā)現(xiàn)它其實就是調(diào)用你本機SSH客戶端去連接所以你在前幾章配好的密鑰、SSH配置、agent緩存它全都能用上。如果有多個服務(wù)器提前管理SSH Config文件能讓你省下大量時間——這就是下一小節(jié)的內(nèi)容。順帶說一個常見卡頓連接遠程服務(wù)器時VS Code會在服務(wù)端下載一個server包如果你的網(wǎng)絡(luò)到服務(wù)器路徑不佳可能卡在downloading server package甚至顯示0B不動。這個通常不是免密配置的問題而是網(wǎng)絡(luò)問題。可以換時間試、或者手工在服務(wù)端預(yù)置server包。但記住一點沒有免密登錄連這個下載環(huán)節(jié)都過不踏實。5.2 用SSH Config管理多臺主機別名、端口、跳板機服務(wù)器數(shù)量增多之后每次都敲完整的userip -p 端口太累了。你可以在本地~/.ssh/config里維護一份主機清單Host prod-server HostName 192.168.1.100 User deploy Port 22 IdentityFile ~/.ssh/id_ed25519_prod Host jump-zone HostName 10.0.0.5 User admin ProxyJump prod-server配好之后連接只需要一句ssh prod-server其他參數(shù)SSH會自動從配置里讀取。ProxyJump是跳板機場景的利器你可以在本地直連跳板機讓它替你轉(zhuǎn)發(fā)到內(nèi)網(wǎng)目標機免密登錄會沿著鏈條一路走完。這意味著你在本地提交代碼、同步文件時仍感覺是直連的體驗。這套配置和免密登錄是天然搭檔。每個Host單獨指定屬于自己的IdentityFile互不干擾。我在熱搜詞里看到一條bad owner or permissions on c:\users\thinkpad/.ssh/config用VS Code的人尤其要注意config文件的權(quán)限如果不過關(guān)IDE連接時同樣會報錯。處理方式就是上一章4.1講的icacls處理完一勞永逸。5.3 批量登錄與自動化傳輸scp、rsync和循環(huán)腳本免密配置真正的爆發(fā)點出現(xiàn)在批量和自動化的場景里。先看傳輸有了免密之后scp和rsync不再有任何交互阻塞scp ./backup.tar.gz prod-server:/data/backup/ rsync -avz --delete ./dist/ prod-server:/var/www/html/再看批量執(zhí)行。假如你有十臺機器IP寫在servers.txt里一行一個免密配置好之后可以這樣批量查磁盤while read ip; do echo $ip ssh root$ip df -h | grep -E ^/dev/ done servers.txt注意我用的遠程命令帶了路徑過濾避免每臺機器輸出太多干擾項。實際生產(chǎn)里我更推薦用Ansible這類工具來管理批量操作但免密登錄依然是它的地基——Ansible默認就是走SSH密鑰認證的。這里分享一個真實踩坑如果某些機器還沒配免密混合批量腳本會在某臺機器上停下來等密碼后面的機器全部排隊卡住你還會誤以為腳本執(zhí)行到一半正常結(jié)束了。所以批量操作前務(wù)必確認清單里的每一臺機器都完成了免密驗證。我自己的習(xí)慣是先寫一個ssh -o BatchModeyes rootip true的預(yù)檢循環(huán)把所有免密不通的機器提前篩出來。5.4 安全加固別讓免密變成免安全最后必須聊一聊安全這一步做過和沒做過效果天差地別。第一件事確認免密登錄跑通后建議關(guān)閉密碼登錄。編輯服務(wù)器上的/etc/ssh/sshd_configPasswordAuthentication no PermitRootLogin prohibit-password第一行關(guān)閉密碼認證第二行意思是禁止root用密碼登錄但允許root用密鑰登錄。改完重啟sshd服務(wù)systemctl restart sshd重啟前一定要確保你的密鑰可以在當(dāng)前配置下成功登錄否則可能出現(xiàn)把自己關(guān)在外面的悲劇。在前一章的排查基礎(chǔ)上用ssh -v看過一次Authenticated to輸出后再動配置我可以負責(zé)任地說這個習(xí)慣值得養(yǎng)成——我見過太多人在服務(wù)器上改完配置然后掉線最后只能跑到機房控制臺去救。第二件事給私鑰設(shè)置passphrase并配合ssh-agent使用。這等于在私鑰文件層面加了一道保險。私鑰文件丟失了沒有passphrase一樣用不了你不會一夜之間失去所有服務(wù)器。第三件事留意異常登錄。即便關(guān)閉了密碼登錄目標SSH服務(wù)仍然會收到大量掃描探測請求。可以用fail2ban這類工具做暴力破解攔截同時定期檢查auth.log或/var/log/secure的異常連接記錄。免密登錄解決的是密碼被爆破的弱點而不是所有人都能連22端口的問題后者靠防火墻和監(jiān)控來兜底。最后再補一個運維習(xí)慣上的建議密鑰也會過期建議按照團隊安全規(guī)范定期輪換。輪換時不比大動干戈生成新密鑰對、用一次密碼登錄把新公鑰放上去、再移除authorized_keys里的舊公鑰整個流程十分鐘之內(nèi)完成。把SSH免密登錄做成標準操作流程的一部分之后服務(wù)器數(shù)量再多心里也有底。我個人這些年最深的體會是SSH免密登錄不是一個配一次就忘的小技巧它本質(zhì)上是在重構(gòu)你與服務(wù)器之間的交互方式。配置它的成本是十分鐘收益卻是往后每一次連接、每一行自動化腳本、每一次遠程開發(fā)時的順暢體驗。最后分享一個我自己一直在用的小習(xí)慣每次配置完新機器不要急著關(guān)閉密碼登錄先ssh -v看一眼確認走的是publickey認證路徑確認無誤后再改服務(wù)端配置。這一步看著不起眼但能省下的是未來無數(shù)個排障夜晚。