1. 初見SSH

SSH是一種協(xié)議標(biāo)準(zhǔn)，其目的是實(shí)現(xiàn)安全遠(yuǎn)程登錄以及其它安全網(wǎng)絡(luò)服務(wù)。

SSH僅僅是一協(xié)議標(biāo)準(zhǔn)，其具體的實(shí)現(xiàn)有很多，既有開源實(shí)現(xiàn)的OpenSSH，也有商業(yè)實(shí)現(xiàn)方案。使用范圍最廣泛的當(dāng)然是開源實(shí)現(xiàn)OpenSSH。

2. SSH工作原理

在討論SSH的原理和使用前，我們需要分析一個(gè)問題：為什么需要SSH？

從1.1節(jié)SSH的定義中可以看出，SSH和telnet、ftp等協(xié)議主要的區(qū)別在于安全性。這就引出下一個(gè)問題：如何實(shí)現(xiàn)數(shù)據(jù)的安全呢？首先想到的實(shí)現(xiàn)方案肯定是對(duì)數(shù)據(jù)進(jìn)行加密。加密的方式主要有兩種：

對(duì)稱加密（也稱為秘鑰加密）

非對(duì)稱加密（也稱公鑰加密）

所謂對(duì)稱加密，指加密解密使用同一套秘鑰。如下圖所示：
Client:

Server:

對(duì)稱加密的加密強(qiáng)度高，很難破解。但是在實(shí)際應(yīng)用過程中不得不面臨一個(gè)棘手的問題：如何安全的保存密鑰呢？尤其是考慮到數(shù)量龐大的Client端，很難保證密鑰不被泄露。一旦一個(gè)Client端的密鑰被竊據(jù)，那么整個(gè)系統(tǒng)的安全性也就不復(fù)存在。為了解決這個(gè)問題，非對(duì)稱加密應(yīng)運(yùn)而生。非對(duì)稱加密有兩個(gè)密鑰：“公鑰”和“私鑰”。

兩個(gè)密鑰的特性：公鑰加密后的密文，只能通過對(duì)應(yīng)的私鑰進(jìn)行解密。而通過公鑰推理出私鑰的可能性微乎其微。

下面看下使用非對(duì)稱加密方案的登錄流程：

1.遠(yuǎn)程Server收到Client端用戶TopGun的登錄請(qǐng)求，Server把自己的公鑰發(fā)給用戶。

2.Client使用這個(gè)公鑰，將密碼進(jìn)行加密。

3.Client將加密的密碼發(fā)送給Server端。

4.遠(yuǎn)程Server用自己的私鑰，解密登錄密碼，然后驗(yàn)證其合法性。

5.若驗(yàn)證結(jié)果，給Client相應(yīng)的響應(yīng)。

私鑰是Server端獨(dú)有，這就保證了Client的登錄信息即使在網(wǎng)絡(luò)傳輸過程中被竊據(jù)，也沒有私鑰進(jìn)行解密，保證了數(shù)據(jù)的安全性，這充分利用了非對(duì)稱加密的特性。

這樣就一定安全了嗎？

上述流程會(huì)有一個(gè)問題：Client端如何保證接受到的公鑰就是目標(biāo)Server端的？，如果一個(gè)攻擊者中途攔截Client的登錄請(qǐng)求，向其發(fā)送自己的公鑰，Client端用攻擊者的公鑰進(jìn)行數(shù)據(jù)加密。攻擊者接收到加密信息后再用自己的私鑰進(jìn)行解密，不就竊取了Client的登錄信息了嗎？這就是所謂的中間人攻擊

SSH中是如何解決這個(gè)問題的？

1. 基于口令的認(rèn)證

從上面的描述可以看出，問題就在于如何對(duì)Server的公鑰進(jìn)行認(rèn)證？在https中可以通過CA來進(jìn)行公證，可是SSH的publish key和private key都是自己生成的，沒法公證。只能通過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 98d7deac28423758:4d.
Are you sure you want to continue connecting (yes/no)?

上面的信息說的是：無法確認(rèn)主機(jī)ssh-server.example.com（12.18.429.21）的真實(shí)性，不過知道它的公鑰指紋，是否繼續(xù)連接？

之所以用fingerprint代替key，主要是key過于長（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)D1-3進(jìn)行。

2.基于公鑰認(rèn)證

在上面介紹的登錄流程中可以發(fā)現(xiàn)，每次登錄都需要輸入密碼，很麻煩。SSH提供了另外一種可以免去輸入密碼過程的登錄方式：公鑰登錄。流程如下：

1.Client將自己的公鑰存放在Server上，追加在文件authorized_keys中。

2.Server端接收到Client的連接請(qǐng)求后，會(huì)在authorized_keys中匹配到Client的公鑰pubKey，并生成隨機(jī)數(shù)R，用Client的公鑰對(duì)該隨機(jī)數(shù)進(jìn)行加密得到pubKey(R)
，然后將加密后信息發(fā)送給Client。

3.Client端通過私鑰進(jìn)行解密得到隨機(jī)數(shù)R，然后對(duì)隨機(jī)數(shù)R和本次會(huì)話的SessionKey利用MD5生成摘要Digest1，發(fā)送給Server端。

4.Server端會(huì)也會(huì)對(duì)R和SessionKey利用同樣摘要算法生成Digest2。

5.Server端會(huì)最后比較Digest1和Digest2是否相同，完成認(rèn)證過程。

在步驟1中，Client將自己的公鑰存放在Server上。需要用戶手動(dòng)將公鑰copy到server上。這就是在配置ssh的時(shí)候進(jìn)程進(jìn)行的操作。下圖是GitHub上SSH keys設(shè)置視圖：

3. SSH實(shí)踐

生成密鑰操作

經(jīng)過上面的原理分析，下面三行命令的含義應(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è)文件：

1.id_rsa：保存私鑰

2.id_rsa.pub：保存公鑰

3.authorized_keys：保存已授權(quán)的客戶端公鑰

4.known_hosts：保存已認(rèn)證的遠(yuǎn)程主機(jī)ID（關(guān)于known_hosts詳情，見文末更新內(nèi)容）

四個(gè)角色的關(guān)系如下圖所示：

需要注意的是：一臺(tái)主機(jī)可能既是Client，也是Server。所以會(huì)同時(shí)擁有authorized_keys和known_hosts。

登錄操作

# 以用戶名user，登錄遠(yuǎn)程主機(jī)host
$ ssh user@host

# 本地用戶和遠(yuǎn)程用戶相同，則用戶名可省去
$ ssh host

# SSH默認(rèn)端口22，可以用參數(shù)p修改端口
$ ssh -p 2017 user@host

4 總結(jié)

本文以圖文方式對(duì)SSH原理進(jìn)行解析（主要指遠(yuǎn)程登錄，沒有涉及端口轉(zhuǎn)發(fā)等功能）。同時(shí)分析了非對(duì)稱加密的特性，以及在實(shí)踐過程中如何對(duì)加密操作進(jìn)行改進(jìn)。

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。

2. host key何時(shí)加入known_hosts的？

當(dāng)我們第一次通過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。。。

3. 為什么需要known_hosts？

最后探討下為什么需要known_hosts，這個(gè)文件主要是通過Client和Server的雙向認(rèn)證，從而避免中間人（man-in-the-middle attack）攻擊，每次Client向Server發(fā)起連接的時(shí)候，不僅僅Server要驗(yàn)證Client的合法性，Client同樣也需要驗(yàn)證Server的身份，SSH client就是通過known_hosts中的host key來驗(yàn)證Server的身份的。

這中方案足夠安全嗎？當(dāng)然不，比如第一次連接一個(gè)未知Server的時(shí)候，known_hosts還沒有該Server的host key，這不也可能遭到中間人攻擊嗎？這可能只是安全性和可操作性之間的折中吧。

鏈接：https://www.cnblogs.com/diffx/p/9553587.html