授權與合規(guī)聲明本文全部操作對象均為自建隔離靶場本機容器或隔離虛擬機涉及安全測試的環(huán)節(jié)必須以取得合法授權為前提。未經授權的滲透測試違反《中華人民共和國網絡安全法》與《刑法》相關條款須承擔相應法律責任。本文只講環(huán)境配置、版本對照與靶場隔離不含任何攻擊步驟、利用載荷與繞過手法請勿將文中環(huán)境指向任何非自有系統(tǒng)。一、那句確認到底在比什么1.1 第一次連一臺沒連過的機器用 SSH 第一次連一臺機器會出現一段要你回答的確認大意是對方的身份是這樣一串你接受嗎。手冊把這件事講得很直接首次連接服務器時會向用戶呈上該服務器公鑰的指紋KH03。你認下它、回車這串身份就被記在本機再連同一臺機器便不再問你同樣的問題。很多人把這個動作當成允許我連它。它的對象其實更窄也更重你確認的是這臺主機的身份不是這次連接的許可。后文那行長字符串、以及身份變了的提醒都從這個動作長出來。1.2 指紋和密鑰不是一回事這是最值得先分清的一處。日常聊天里大家把指紋“密鑰”證書混著說一到看那一行就糊涂。公鑰是服務器用來證明我是誰的身份材料本身是一長串指紋是把公鑰做一次摘要得到的短標識用途是讓人能比得過來KH03。手冊還提到一條邊界若手上只有舊的、基于 MD5 的指紋可以用ssh-keygen的-E選項把指紋算法降下來對齊KH04——這說明指紋的算法可以換而它指向的公鑰不變。于是關鍵結論是你確認時看到的往往是指紋被記住并在日后用來核驗的是公鑰本身。指紋是用來認的標簽公鑰才是被核對的身份。把三者擺在一起看服務器公鑰是你不直接看到、卻被記住并用于日后核驗的身份材料指紋是首次連接時擺在你面前、供你比對的那串短標識而你回的那個yes含義是我認下這臺主機的身份。# 查看本機 SSH 客戶端版本本文 2026-10-09 實測ssh-V1.3 它驗的是主機身份不是文件內容這條邊界必須說清。主機身份這條線問的是這臺機器的公鑰我此前認過嗎、還對得上嗎。而下載完先驗一遍那類做法驗的是某個文件的內容有沒有被改動——對象是一份文件不是一臺主機。至于服務端證書由誰簽發(fā)、信任鏈怎么走那是另一套信任憑據。三件事都和信任沾邊但比對的對象、依賴的材料、含義都不同。本文只把主機身份這一條講透另兩條只在區(qū)分時點到為止。本章可以帶走的一句第一次連接時你確認的是主機指紋它指向的那把公鑰才是被記住、被日后核驗的東西這條線講的是主機身份與文件內容校驗證書信任鏈是三件不同的事。二、它把這些記到了哪里2.1 每個人自己的一本手冊對這套機制的定位是一句話SSH 會自動維護并檢查一個數據庫里面存著它歷來用過的主機的身份KH01。落到文件上用戶的那一本就放在家目錄下主機密鑰存放在~/.ssh/known_hostsKH01。它是自動維護的每當用戶連到一臺未知主機那臺主機的密鑰就會被加進用戶自己的這份文件KH06。也就是說這本賬不由你手工登記——是連接這個動作本身在寫“為什么不該手打”第四章再講。2.2 系統(tǒng)級的那一本除了用戶自己那一本還有一本系統(tǒng)級的/etc/ssh/ssh_known_hosts會被自動檢查KH01。手冊把兩本的分工說得很清楚它們都存放已知主機的公鑰其中全局那本由管理員準備可選每用戶那本由程序自動維護KH06。還有一個名字可能與直覺不符手冊給的默認是一串而非單個文件——UserKnownHostsFile的默認是~/.ssh/known_hosts,~/.ssh/known_hosts2KH16。兩本并列這是本節(jié)要照記的一條。2.3 什么時候被寫進去寫進去的時機兩種情形最常見連一臺未知主機時被自動加進用戶這本KH06以及由腳本或工具批量生成第四章展開。另有一條不那么顯眼按默認口徑是否落入用戶文件還受一個開關影響這個開關放到第五章講。文件誰維護什么時候用到~/.ssh/known_hosts程序自動維護你連過的每臺主機的公鑰~/.ssh/known_hosts2同為用戶級默認之一與上一本并列為默認值/etc/ssh/ssh_known_hosts管理員準備可選會被自動檢查的全局那本本章可以帶走的一句主機密鑰默認存在用戶級~/.ssh/known_hosts默認值還含~/.ssh/known_hosts2系統(tǒng)級/etc/ssh/ssh_known_hosts會被自動檢查、由管理員準備且可選用戶這本是自動寫的不用你手工登記。三、那一行長字符串拆開看3.1 一行由五個字段拼成打開known_hosts看到的是若干行很長的字符串。手冊把每行的字段寫得很明確每一行包含以下字段——marker可選、hostnames、keytype、base64 編碼的密鑰、comment字段之間用空格分隔KH07。五個字段里決定這臺主機是誰的是hostnames與keytype base64 編碼的密鑰這兩組前者說明這一行說的是哪臺或哪些主機后者就是那把被記住的公鑰。comment 字段則一直延續(xù)到行尾、不被使用手冊原文如此更像一句自由備注。字段是否必需它管什么marker可選給這一行加特殊身份標記見 3.3hostnames必需這一行對應的主機名或地址可用模式匹配keytype必需公鑰的算法類型base64 編碼的密鑰必需被記住的那把公鑰本體comment可選一直延續(xù)到行尾不被使用??代碼待驗證# 一行 known_hosts 的字段順序結構示意非真實樣例# [marker] hostnames keytype base64-encoded-key comment# 字段之間以空格分隔照手冊字段說明記本文不給任何手寫樣例3.2 hostnames 這一格的花樣最多hostnames 不是一個名字而是逗號分隔的一串模式其中*與?按通配符處理每個模式依次與主機名比對KH09。它還帶一個反選機制模式前可加!表示否定——若主機名命中了被否定的模式即便同時命中本行別的模式也不被本行接受KH09。此外主機名或地址可用[]括起后接:與非標準端口號KH09——這就是同一臺機器不同端口各算各的。還有一種會讓人認不出的寫法哈希形式。手冊說為在文件內容被看到時隱藏主機名與地址主機名可存成哈希形式以|字符開頭且一行里只允許一個哈希主機名否定與通配都不能用KH10。哈希所用算法本文未核。3.3 可選前綴、注釋行與同名多行回到第一格的 marker它是可選的一旦出現就必須是cert-authority表示這一行是某認證機構的密鑰或revoked表示這行的密鑰處于吊銷狀態(tài)之一一行只應使用一個 markerKH08。吊銷這件事手冊另有一句被吊銷的密鑰不再被接受用于認證或作為認證機構遇到時會產生一條來自 ssh 的警告KH12。還有兩條與讀文件相關的規(guī)則以#開頭的行與空行都按注釋忽略KH11允許但不推薦為同一個名字留多行或不同主機密鑰文件可能出現互相沖突的信息能從任一文件找到有效信息即接受認證KH13。這也解釋了一個現象——同一個名字出現好幾次不一定是寫壞了而是規(guī)范允許的容錯。本章可以帶走的一句known_hosts一行就是可選 marker hostnames keytype base64 密鑰 comment五個字段hostnames 支持逗號分隔的通配與!否定、[主機]:端口與以|開頭的哈希形式#行與空行是注釋同名多行屬于規(guī)范允許的容錯。四、怎么自己核這一行4.1 三個動作查、刪、看指紋這本賬既然是自動寫的核對時就不該靠肉眼。手冊給了兩個自動編輯入口ssh-keygen -F在known_hosts里搜索指定主機名可帶端口列出找到的位置它對查找哈希主機名或地址尤其有用KH17ssh-keygen -R從known_hosts移除屬于指定主機名的全部密鑰手冊點明它適合刪除哈希主機KH18。第三件事是看指紋本身手冊在講指紋時就示范過ssh-keygen -l -f的用法KH03——把一個公鑰文件的指紋打印出來。三者用一句話記住-F 是查有沒有-R 是刪掉這一條-l -f 是把這把公鑰的指紋算出來看。手冊還給了一句實在提醒這些文件里每一行通常長達數百個字符所以你肯定不想手打主機密鑰正確姿勢是用腳本、ssh-keyscan或拿現成的.pub公鑰文件在前頭補主機名KH14。它同時說明ssh-keygen能做基礎自動編輯刪除匹配某主機名的條目、把所有主機名轉成哈希形式KH14。動作命令它做什么手冊給的適用點查ssh-keygen -F搜索主機名可帶端口列出找到的位置尤其適合查哈希主機名/地址刪ssh-keygen -R移除屬于該主機名的全部密鑰適合刪除哈希主機看ssh-keygen -l -f打印某公鑰文件的指紋講指紋時的官方示范用法4.2 本機實測這些命令的輸出長什么樣上面三條不是紙面推論。2026-10-09在一臺 macOSssh -V為OpenSSH_10.3p1上用臨時目錄與一行自造記錄做過一次實測KH19ssh-keygen -F hostname -f known_hosts輸出首行是一句在文件第幾行找到該主機式的注釋隨后是命中的那一行原文ssh-keygen -F address -l -f known_hosts除首行注釋外第二行是該主機的標識 算法名 SHA256 開頭的指紋 注釋——加了-l它把命中的公鑰換算成便于比對的指紋形式ssh-keygen -R hostname -f known_hosts輸出說明該文件完成更新并注明原內容被保留為known_hosts.old——被刪的那一行會寫進這個備份等于給你留了退路。本文只寫這些輸出的結構首行是什么、第二行由哪幾段拼成、會生成哪個備份文件不寫任何具體指紋值也不給出可直接照抄的完整文件樣例。# 2026-10-09 本機實測macOS / OpenSSH_10.3p1臨時目錄中執(zhí)行# 只展示命令與「輸出結構」不含任何具體指紋值ssh-keygen-Fhostname-fknown_hosts# - 首行說明在第幾行找到該主機隨后命中的該行原文ssh-keygen-Faddress-l-fknown_hosts# - 首行同上第二行主機標識 算法名 SHA256 指紋 注釋ssh-keygen-Rhostname-fknown_hosts# - 提示文件完成更新原內容保留為 known_hosts.old被刪行落在該備份里4.3 肉眼比對的官方補充以及它的局限除了用工具算手冊還提供一個不靠工具的官方辦法random art隨機圖案。手冊的解釋是光看指紋字符串很難比對所以還支持用 random art 目視比對主機密鑰把VisualHostKey設為yes后每次登錄都會顯示一小段 ASCII 圖案無論會話是否交互KH05。用法是認得某臺已知主機常出現的圖案一旦出現完全不同的圖案就能較快發(fā)現主機密鑰變了KH05。但手冊緊接著給這條辦法劃了邊界而且很謹慎這些圖案并非無歧義一張看起來相似的圖案只能說明主機密鑰相同的概率較高并不能作為保證性的證據KH05。換句話說random art 是輔助你起疑的不是替你下結論的。本章可以帶走的一句核這一行有三件事——ssh-keygen -F查、-R刪、-l -f看指紋三者都以自動編輯為前提、手冊也明說不要手打random art 能做肉眼比對但手冊自己講清它只能給出概率、給不了確鑿結論。五、什么時候真的該停下來5.1 身份變了會怎樣前面講的都是認下來、記下來。真正該警覺的是另一種情形本來認過的主機它的身份變了。手冊對此的說法是若某臺主機的身份發(fā)生變化SSH 會就此發(fā)出警告并禁用口令認證目的是防止服務器冒充與中間人攻擊KH02。兩點要拆開看。第一它做的是警告 關掉一種認證方式不是靜默換憑據繼續(xù)連。第二手冊給出的理由是防止……否則會被用來繞過加密KH02——身份對不上時加密本身并不足以保護你因為你可能正和另一臺機器在加密通信。這也是變了值得停下來看的原因。5.2 四個取值和一個容易記錯的默認控制這套行為的是StrictHostKeyChecking。手冊給了四個取值逐條照它的口徑KH15yes從不自動把主機密鑰加入~/.ssh/known_hosts并拒絕連接主機密鑰發(fā)生變化的主機accept-new會自動把新主機密鑰加入用戶的 known_hosts但不允許連接主機密鑰發(fā)生變化的主機no/off會自動加入新主機密鑰并允許連接主機密鑰發(fā)生變化的主機繼續(xù)受某些限制ask默認只有在用戶確認確實想要這樣之后新的主機密鑰才會被加入用戶的 known_hosts同時會拒絕連接主機密鑰發(fā)生變化的主機。請?zhí)貏e注意最后那個默認值默認是ask不是別的。這一步也順帶回答了第二章末尾留下的問題——默認情況下新主機密鑰并非無條件寫入而是要等你確認。手冊還給了這四檔一個共同的收尾句值得原樣記住“已知主機的主機密鑰在所有情況下都會被自動核驗”KH15。無論把那一檔調成什么已知主機這一類的核驗都照做——這句是本節(jié)最不該記岔的一處。取值新主機密鑰是否自動加入主機密鑰發(fā)生變化的主機yes從不拒絕連接accept-new自動加入拒絕連接no/off自動加入允許繼續(xù)受某些限制ask默認用戶確認后才加入拒絕連接??代碼待驗證# StrictHostKeyChecking 四檔照手冊口徑記本文不給任何繞過/關閉的做法# yes - 從不自動加入拒絕連接密鑰發(fā)生變化的主機# accept-new - 自動加入新密鑰仍拒絕連接密鑰發(fā)生變化的主機# no / off - 自動加入允許連接密鑰發(fā)生變化的主機繼續(xù)受某些限制# ask默認 - 用戶確認后才加入拒絕連接密鑰發(fā)生變化的主機# 手冊收尾句已知主機的主機密鑰在所有情況下都會被自動核驗。5.3 本文不給怎么讓它別再問的做法讀到默認是ask很容易順手想改掉它好讓那段確認不再出現。本文不做這件事也不推薦任何非默認取值如何關閉或跳過主機密鑰校驗屬于本文明確不寫的范圍這正是它作為安全機制存在的意義改檔位也不解決該不該認下這臺主機這個真問題。真正該帶走的是一條判斷順序遇到身份變了的提醒先當作需要查證的事而不是需要關掉的彈窗。怎么查第七章收成一張流程。本章可以帶走的一句主機身份一旦變化SSH 會警告并禁用口令認證用意是防冒充與中間人StrictHostKeyChecking四檔里默認是ask且手冊明確——已知主機的主機密鑰在所有情況下都會被自動核驗本文不給任何關閉或跳過的做法。完整版主機密鑰對照表這一章的四檔取值與默認值、手冊那句收尾話、身份變化的含義連同第二章的兩個文件位置、第三章的字段拆解一起收進資料包掃碼即可獲取六、三類常見誤解的對照表前幾章把是什么講完了這一章用它回答幾個最常見的說法只借前五章事實不作引申。6.1 “刪掉 known_hosts電腦就更安全或者更不安全”手冊給的定位是這本賬存放的是已知主機的公鑰是自動維護并檢查的身份庫KH01、KH06。刪掉它改變的是本機還記不記得這些身份而不是這臺機器本身的加密強度后果是下次連接這些主機會回到未知主機狀態(tài)KH06。6.2 “看到了指紋說明這次連接加密更強”由 1.2 可知指紋是對公鑰做的摘要用途是便于比對不是加密強度的一部分KH03、KH04。它出現與否說明的是要不要做身份確認而非通道有多強把指紋當成加密等級是把兩件事混成一件。6.3 “主機換個名字就能連上、也不再提醒了”known_hosts記的是主機的身份公鑰hostnames 那格只是這一行對應哪些名字支持逗號分隔、通配與!否定、[主機]:端口等形式KH07、KH09。名字與認下的身份有對應關系而主機身份本身變化時處理邏輯是警告并禁用口令認證KH02。至于同名多行手冊明確允許但不推薦且能從任一文件找到有效信息即接受認證KH13——它是容錯不是改名即可繞過。常見說法用哪條事實回答結論刪掉known_hosts就更安全/更不安全KH01、KH06它是自動維護的已知主機身份庫改變的是記不記得不是加密強度出現指紋 加密更強KH03、KH04指紋是公鑰摘要便于比對管的是要不要確認身份不是通道強度改主機名就能連上、不再提醒KH07、KH09、KH02、KH13名字與身份有對應身份變化照樣警告同名多行只是容錯本章可以帶走的一句known_hosts是身份記憶而非安全開關指紋管的是要不要確認身份而非通道有多強改名既不改變認下的身份、也不改變身份變化就警告這條規(guī)則——三條誤解其實都源于把主機身份和別的東西混在了一起。七、一張自查流程7.1 三個問題把前六章收成一條能用的流程只需在遇到相關提示時問自己三個問題第一這是第一次見還是以前見過、這次變了前者是首次呈現指紋KH03屬正常確認后者涉及身份變化手冊的處理是警告并禁用口令認證KH02——兩類要分開。第二我手里有沒有可比對的材料有工具時用ssh-keygen -F查、-l -f看指紋KH17、KH03想肉眼比對手冊提供 random art但它只給概率、不給保證KH05。沒有材料時該做的是去拿到材料而不是靠模糊印象點接受。第三我改的那個檔位是在解決問題還是關掉提醒手冊明確已知主機的主機密鑰在所有情況下都會被自動核驗KH15改檔位不改變該不該認下這臺主機這個判斷。關閉或跳過校驗的做法本文一律不寫。7.2 一張表收束情形該做什么依據第一次連一臺機器把它當首次確認身份處理KH03以前連過、這次提示身份不符停下來查證不要當作日常彈窗KH02想確認本機記沒記這臺主機用ssh-keygen -F查哈希也適用KH17想比對指紋ssh-keygen -l -f看指紋random art 僅作輔助KH03、KH05冒出改個檔位就不提醒了的念頭記住默認是ask、已知主機一律自動核驗本文不給關閉/跳過做法KH15??代碼待驗證# 自查流程只讀動作本文不給任何關閉/跳過校驗的做法# 1) 分辨首次確認 還是 身份變化# 2) 查本機記錄ssh-keygen -F hostname -f known_hosts# 3) 比對指紋ssh-keygen -l -f pubkeyrandom art 僅作輔助# 4) 記住默認檔位是 ask已知主機的主機密鑰在所有情況下都會被自動核驗7.3 回到最初那一行回到標題那個問題第一次連服務器時你回的那個 yesknown_hosts到底記了什么到這里可以有據地回答——它記的是那臺主機的身份公鑰以可選 marker hostnames keytype base64 密鑰 comment的字段形式落在本機賬本里KH07首次連接時你比對的往往是指紋KH03一旦這臺主機的身份變化處理邏輯是警告并禁用口令認證KH02而無論記在哪兒、檔位怎么設已知主機的主機密鑰在所有情況下都會被自動核驗KH15。至于怎么少問一次本文不寫——它從來不是這篇要解決的問題。本章可以帶走的一句遇到相關提示先分首次確認還是身份變化再用ssh-keygen -F/-l -f去查與比對認下身份靠的是可比對的材料而不是模糊印象改檔位不等于解決問題因為已知主機的主機密鑰在所有情況下都會被自動核驗。完整版主機密鑰對照表這一章的自查流程表 四步只讀動作加上第六章的三條誤解對照匯總進資料包掃碼即可獲取附表 A本文引用事實與官方出處對照表KH 編號事實陳述一手出處本文位置KH01SSH 自動維護并檢查一個記錄歷來所用主機身份的數據庫主機密鑰存于~/.ssh/known_hosts/etc/ssh/ssh_known_hosts會被自動檢查新主機會被自動加入用戶文件S2ssh(1)手冊第 1、2 章KH02若某主機身份發(fā)生變化ssh 會警告并禁用口令認證以防服務器冒充與中間人攻擊避免被用來繞過加密S2ssh(1)手冊第 5、6 章KH03首次連接服務器時會向用戶呈上其公鑰指紋除非該選項被禁用指紋可用ssh-keygen -l -f求得S2ssh(1)手冊第 1、4 章KH04指紋已知即可比對接受或拒絕若只有舊式 MD5 指紋可用ssh-keygen -E降低指紋算法以對齊S2ssh(1)手冊第 1、6 章KH05直接比對指紋字符串有難度故支持用 random art 目視比對設VisualHostKeyyes后每次登錄顯示 ASCII 圖案圖案非無歧義相似只給概率、非保證S2ssh(1)手冊第 4、7 章KH06兩份文件保存全部已知主機公鑰全局文件由管理員準備可選每用戶文件自動維護連到未知主機時其密鑰被加入用戶文件S2sshd(5)手冊第 2、3 章KH07每行字段marker可選、hostnames、keytype、base64 編碼密鑰、comment以空格分隔comment 延續(xù)至行尾且不被使用S2sshd(5)手冊第 3、6 章KH08marker 可選出現時只能是cert-authority或revoked一行只應使用一個S2sshd(5)手冊第 3 章KH09hostnames 為逗號分隔模式*?為通配可前置!表示否定主機名/地址可用[ ]括起后接:與非標準端口號S2sshd(5)手冊第 3、6 章KH10主機名可存為哈希形式以隱藏名稱與地址以|開頭一行只允許一個哈希主機名且不能使用否定/通配S2sshd(5)手冊第 3 章KH11以#開頭的行與空行按注釋忽略S2sshd(5)手冊第 3 章KH12可用revoked標記被吊銷密鑰此類密鑰不再被接受用于認證或作為認證機構遇到時產生警告S2sshd(5)手冊第 3 章KH13允許但不推薦為同一名字留多行或不同主機密鑰文件可能沖突能從任一文件找到有效信息即接受認證S2sshd(5)手冊第 3、6 章KH14這些行通常長達數百字符不應手打應由腳本、ssh-keyscan或取現成.pub在前補主機名生成ssh-keygen提供基礎自動編輯刪除匹配主機名、轉為哈希形式S2sshd(5)手冊第 4 章KH15StrictHostKeyChecking四檔——yes從不自動加入、拒絕連接密鑰發(fā)生變化的主機、accept-new自動加入新密鑰、仍拒絕連接密鑰發(fā)生變化的主機、no/off自動加入、允許密鑰發(fā)生變化的主機繼續(xù)受某些限制、ask默認用戶確認后加入、拒絕連接密鑰發(fā)生變化的主機收尾句已知主機的主機密鑰在所有情況下都會被自動核驗S2ssh_config(5)手冊第 5、7 章KH16UserKnownHostsFile指定一個或多個用戶主機密鑰數據庫文件以空白分隔none表示忽略任何用戶級 known_hosts默認是~/.ssh/known_hosts,~/.ssh/known_hosts2S2ssh_config(5)手冊第 2 章KH17ssh-keygen -F在 known_hosts 中搜索指定主機名可帶端口列出找到的出現位置適合查找哈希主機名或地址S2ssh-keygen(1)手冊第 4、7 章KH18ssh-keygen -R從 known_hosts 移除屬于指定主機名的全部密鑰適合刪除哈希主機S2ssh-keygen(1)手冊第 4 章KH19本機實測2026-10-09macOSOpenSSH_10.3p1-F首行為第幾行找到式注釋 命中行原文-F ... -l第二行為標識 算法名 SHA256 指紋 注釋-R提示文件完成更新、原內容保留為known_hosts.old本文實測第 4 章KH20本機實測環(huán)境ssh -V→OpenSSH_10.3p1, LibreSSL 3.3.6截至 2026-10-09本文實測第 1 章附表 B術語速查表術語一句話解釋known_hosts本機記錄已知主機身份公鑰的賬本默認在~/.ssh/known_hosts主機密鑰 / 主機公鑰服務器用來證明自身身份的身份材料指紋對公鑰做摘要得到的短標識便于人眼比對random art用 ASCII 圖案輔助目視比對主機密鑰手冊說它只給概率marker行首可選標記cert-authority或revokedhostnames該行對應的主機名/地址逗號分隔支持通配、!否定、[主機]:端口、哈希形式StrictHostKeyChecking控制新主機密鑰是否自動加入、以及是否連接密鑰發(fā)生變化的主機默認askssh-keygen -F/-R/-l -f查 / 刪 / 看指紋三個動作known_hosts.old-R刪除時保留原內容的備份文件代碼待驗證本文標記該命令未在本機實際運行過寫在最后這篇用到的資料寫這篇文章時我一直在想那個反差——第一次連服務器時隨手回的一個 yes背后其實是本機在和一臺機器對身份拆開才看清指紋只是標簽被記住的是公鑰。順手也整理了幾份配套的東西靶場環(huán)境對照表DVWA、upload-labs 在 Windows / macOS / Linux 三平臺的可行性與推薦路徑Web 安全學習路線圖從基礎打牢到安全管理四個階段各學什么常用靶場清單每個靶場練什么、適合哪個階段資料是我自己整理的放在下面這個碼上掃碼即可獲取添加時備注「靶場」優(yōu)先通過。拿到之后建議先看環(huán)境對照表那一份把本文講的known_hosts 記了什么、怎么用 ssh-keygen 去查對照著過一遍下次再看到那段確認就知道自己答應的是什么。