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