1. 初見(jiàn) SSH
SSH是一種協(xié)議標(biāo)準(zhǔn)，用于在網(wǎng)絡(luò)主機(jī)之間進(jìn)行加密的一種協(xié)議，其目的是實(shí)現(xiàn)安全遠(yuǎn)程登錄以及其它安全網(wǎng)絡(luò)服務(wù)。
SSH 僅僅是一協(xié)議標(biāo)準(zhǔn)，其具體的實(shí)現(xiàn)有很多，既有開(kāi)源實(shí)現(xiàn)的 OpenSSH，也有商業(yè)實(shí)現(xiàn)方案。使用范圍最廣泛的當(dāng)然是開(kāi)源實(shí)現(xiàn) OpenSSH。
為什么要搞這么個(gè)協(xié)議呢？其實(shí)，很久很久以前，互聯(lián)網(wǎng)通信都是明文的，一旦在中間環(huán)節(jié)被某些中間商截獲了，我們的通信內(nèi)容就暴漏無(wú)疑。
所以芬蘭就有這么一位叫做 Tatu Ylonen 的人設(shè)計(jì)了 SSH 協(xié)議，將信息加密，這樣就像上面說(shuō)的，即使我們的登陸信息在中間被人截獲了，我們的密碼也不會(huì)被泄露。
目前 SSH 協(xié)議已經(jīng)在全世界廣泛被使用，且已經(jīng)在成為各個(gè) linux 發(fā)行版的標(biāo)配。
2. SSH 工作原理
在討論 SSH 的原理和使用前，我們需要分析一個(gè)問(wèn)題：為什么需要 SSH？
從 1.1 節(jié) SSH 的定義中可以看出，SSH 和 Telnet、FTP 等協(xié)議主要的區(qū)別在于安全性。這就引出下一個(gè)問(wèn)題：如何實(shí)現(xiàn)數(shù)據(jù)的安全呢？首先想到的實(shí)現(xiàn)方案肯定是對(duì)數(shù)據(jù)進(jìn)行加密。加密的方式主要有兩種：
- 對(duì)稱加密（也稱為秘鑰加密）
- 非對(duì)稱加密（也稱公鑰加密）
所謂對(duì)稱加密，指加密解密使用同一套秘鑰。如下圖所示：
圖1-1：對(duì)稱加密-Client端
圖1-2：對(duì)稱加密-Server端
對(duì)稱加密的加密強(qiáng)度高，很難破解。但是在實(shí)際應(yīng)用過(guò)程中不得不面臨一個(gè)棘手的問(wèn)題：如何安全的保存密鑰呢？
尤其是考慮到數(shù)量龐大的 Client 端，很難保證密鑰不被泄露。一旦一個(gè) Client端的密鑰被竊取，那么整個(gè)系統(tǒng)的安全性也就不復(fù)存在。為了解決這個(gè)問(wèn)題，非對(duì)稱加密應(yīng)運(yùn)而生。非對(duì)稱加密有兩個(gè)密鑰：“公鑰”和“私鑰”。
兩個(gè)密鑰的特性：公鑰加密后的密文，只能通過(guò)對(duì)應(yīng)的私鑰進(jìn)行解密。而通過(guò)公鑰推理出私鑰的可能性微乎其微。
下面看下使用非對(duì)稱加密方案的登錄流程：
圖1-3：非對(duì)稱加密登錄流程
- 遠(yuǎn)程 Server 收到 Client 端用戶 TopGun 的登錄請(qǐng)求，Server 把自己的公鑰發(fā)給用戶。
- Client 使用這個(gè)公鑰，將密碼進(jìn)行加密。
- Client 將加密的密碼發(fā)送給 Server端。
- 遠(yuǎn)程 Server 用自己的私鑰，解密登錄密碼，然后驗(yàn)證其合法性。
- 若驗(yàn)證結(jié)果，給 Client 相應(yīng)的響應(yīng)。
私鑰是 Server 端獨(dú)有，這就保證了 Client 的登錄信息即使在網(wǎng)絡(luò)傳輸過(guò)程中被竊據(jù)，也沒(méi)有私鑰進(jìn)行解密，保證了數(shù)據(jù)的安全性，這充分利用了非對(duì)稱加密的特性。
這樣就一定安全了嗎？
上述流程會(huì)有一個(gè)問(wèn)題：Client 端如何保證接受到的公鑰就是目標(biāo) Server 端的？
如果一個(gè)攻擊者中途攔截 Client 的登錄請(qǐng)求，向其發(fā)送自己的公鑰，Client 端用攻擊者的公鑰進(jìn)行數(shù)據(jù)加密。攻擊者接收到加密信息后再用自己的私鑰進(jìn)行解密，不就竊取了 Client 的登錄信息了嗎？這就是所謂的中間人攻擊。
圖1-4：中間人攻擊
2.1 SSH 中是如何解決這個(gè)問(wèn)題的？
2.1.1 基于口令的認(rèn)證
從上面的描述可以看出，問(wèn)題就在于如何對(duì) Server 的公鑰進(jìn)行認(rèn)證？在 https中可以通過(guò) CA 來(lái)進(jìn)行公證，可是 SSH 的 Publish key和 Private key 都是自己生成的，沒(méi)法公證。
只能通過(guò) Client 端自己對(duì)公鑰進(jìn)行確認(rèn)。通常在第一次登錄的時(shí)候，系統(tǒng)會(huì)出現(xiàn)下面提示信息：
The authenticity of host 'ssh-server.example.com (12.18.429.21)' can't be established.
RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
Are you sure you want to continue connecting (yes/no)?
上面的信息說(shuō)的是：無(wú)法確認(rèn)主機(jī) ssh-server.example.com（12.18.429.21）的真實(shí)性，不過(guò)知道它的公鑰指紋，是否繼續(xù)連接？
之所以用 fingerprint 代替 key，主要是 key 過(guò)于長(zhǎng)（RSA 算法生成的公鑰有1024 位），很難直接比較。所以，對(duì)公鑰進(jìn)行 Hash 生成一個(gè) 128 位的指紋，這樣就方便比較了。
如果輸入 yes 后，會(huì)出現(xiàn)下面信息：
Warning: Permanently added 'ssh-server.example.com,12.18.429.21' (RSA) to the list of known hosts.
Password: (enter password)
該 host 已被確認(rèn)，并被追加到文件 known_hosts 中，然后就需要輸入密碼，之后的流程就按照?qǐng)D 1-3 進(jìn)行。
2.1.2 基于公鑰認(rèn)證
在上面介紹的登錄流程中可以發(fā)現(xiàn)，每次登錄都需要輸入密碼，很麻煩。SSH 提供了另外一種可以免去輸入密碼過(guò)程的登錄方式：公鑰登錄。流程如下：
圖1-5：公鑰認(rèn)證流程
- Client 將自己的公鑰存放在 Server 上，追加在文件 authorized_keys 中。注意：Client 端的 Public key 是 Client 手動(dòng) Copy 到 Server端的，SSH 建立連接過(guò)程中沒(méi)有公鑰的交換操作。
- Server 端接收到 Client 的連接請(qǐng)求后，會(huì)在 authorized_keys 中匹配到 Client 的公鑰 pubKey，并生成隨機(jī)數(shù) R，用 Client 的公鑰對(duì)該隨機(jī)數(shù)進(jìn)行加密得到 pubKey(R)，然后將加密后信息發(fā)送給 Client。
- Client 端通過(guò)私鑰進(jìn)行解密得到隨機(jī)數(shù) R，然后對(duì)隨機(jī)數(shù) R 和本次會(huì)話的 SessionKey 利用 MD5 生成摘要 Digest1，發(fā)送給 Server 端。
- Server 端會(huì)也會(huì)對(duì) R 和 SessionKey 利用同樣摘要算法生成 Digest2。
- Server 端會(huì)最后比較 Digest1 和 Digest2 是否相同，完成認(rèn)證過(guò)程。
注意：在步驟1中，Client 將自己的公鑰存放在 Server 上。需要用戶手動(dòng)將公鑰 Copy 到 Server 上。這就是在配置 SSH 的時(shí)候進(jìn)程進(jìn)行的操作。下圖是 GitHub 上 SSH keys 設(shè)置視圖：
GitHub 中 SSH keys 設(shè)置
在步驟 2 中，Server 端根據(jù)什么信息在 authorized_keys 中進(jìn)行查找的呢？主要是根據(jù) Client 在認(rèn)證的開(kāi)始會(huì)發(fā)送一個(gè) KeyID 給 Server，這個(gè) KeyID 會(huì)唯一對(duì)應(yīng)該 Client 的一個(gè) PublicKey，Server 就是通過(guò)該 KeyID 在 authorized_keys 進(jìn)行查找對(duì)應(yīng)的 PublicKey。
3. SSH 實(shí)踐
3.1 生成密鑰操作
經(jīng)過(guò)上面的原理分析，下面三行命令的含義應(yīng)該很容易理解了：
$ ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa $ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys $ chmod 0600 ~/.ssh/authorized_keys
ssh-keygen 是用于生產(chǎn)密鑰的工具。
- -t：指定生成密鑰類型（rsa、dsa、ecdsa 等）
- -P：指定 passphrase，用于確保私鑰的安全
- -f：指定存放密鑰的文件（公鑰文件默認(rèn)和私鑰同目錄下，不同的是存放公鑰的文件名需要加上后綴 .pub）
首先看下面 ~/.ssh 中的四個(gè)文件：
SSH 涉及文件
- id_rsa：保存私鑰
- id_rsa.pub：保存公鑰
- authorized_keys：保存已授權(quán)的客戶端公鑰
- known_hosts：保存已認(rèn)證的遠(yuǎn)程主機(jī) ID（關(guān)于 known_hosts 詳情，見(jiàn)文末更新內(nèi)容）
四個(gè)角色的關(guān)系如下圖所示：
SSH 結(jié)構(gòu)簡(jiǎn)圖
需要注意的是：一臺(tái)主機(jī)可能既是 Client，也是 Server。所以會(huì)同時(shí)擁有authorized_keys 和 known_hosts。
3.2 登錄操作
# 以用戶名user，登錄遠(yuǎn)程主機(jī)host $ ssh user@host ? # 本地用戶和遠(yuǎn)程用戶相同，則用戶名可省去 $ ssh host ? # SSH默認(rèn)端口22，可以用參數(shù)p修改端口 $ ssh -p 2017 user@host
4. 其它一些補(bǔ)充
下面關(guān)于 SSH 的 known_hosts 機(jī)制的一些補(bǔ)充。
4.1 known_hosts 中存儲(chǔ)的內(nèi)容是什么？
known_hosts 中存儲(chǔ)是已認(rèn)證的遠(yuǎn)程主機(jī) host key，每個(gè) SSH Server 都有一個(gè) secret, unique ID, called a host key。
4.2 host key 何時(shí)加入 known_hosts 的？
當(dāng)我們第一次通過(guò) SSH 登錄遠(yuǎn)程主機(jī)的時(shí)候，Client 端會(huì)有如下提示：
Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)?
此時(shí)，如果我們選擇 yes，那么該 host key 就會(huì)被加入到 Client 的known_hosts 中，格式如下：
# domain name+encryption algorithm+host key
example.hostname.com ssh-rsa AAAAB4NzaC1yc2EAAAABIwAAAQEA...
4.3 為什么需要 known_hosts？
最后探討下為什么需要 known_hosts，這個(gè)文件主要是通過(guò) Client 和 Server的雙向認(rèn)證，從而避免中間人（man-in-the-middle attack）攻擊，每次Client 向 Server 發(fā)起連接的時(shí)候，不僅僅 Server 要驗(yàn)證 Client 的合法性，Client 同樣也需要驗(yàn)證 Server 的身份，SSH Client 就是通過(guò) known_hosts 中的 host key 來(lái)驗(yàn)證 Server 的身份的。
這種方案足夠安全嗎？當(dāng)然不，比如第一次連接一個(gè)未知 Server 的時(shí)候，known_hosts 還沒(méi)有該 Server 的 host key，這不也可能遭到中間人攻擊嗎？這可能只是安全性和可操作性之間的折中吧。
5. 總結(jié)
本文以圖文方式對(duì) SSH 原理進(jìn)行解析（主要指遠(yuǎn)程登錄，沒(méi)有涉及端口轉(zhuǎn)發(fā)等功能）。同時(shí)分析了非對(duì)稱加密的特性，以及在實(shí)踐過(guò)程中如何對(duì)加密操作進(jìn)行改進(jìn)。
