SSH是每一臺Linux電腦的標準配置。
隨着Linux設備從電腦逐漸擴展到手機、外設和家用電器，SSH的使用範圍也越來越廣。不僅程序員離不開它，很多普通用戶也每天使用。
SSH具備多種功能，可以用於很多場合。有些事情，沒有它就是辦不成。本文是我的學習筆記，總結和解釋了SSH的常見用法，希望對大家有用。
雖然本文內容只涉及初級應用，較爲簡單，但是需要讀者具備最基本的"Shell知識"和了解"公鑰加密"的概念。如果你對它們不熟悉，我推薦先閱讀《UNIX / Linux 初學者教程》和《數字簽名是什麼？》。
=======================================
SSH原理與運用
作者：阮一峯
一、什麼是SSH？
簡單說，SSH是一種網絡協議，用於計算機之間的加密登錄。
如果一個用戶從本地計算機，使用SSH協議登錄另一臺遠程計算機，我們就可以認爲，這種登錄是安全的，即使被中途截獲，密碼也不會泄露。
最早的時候，互聯網通信都是明文通信，一旦被截獲，內容就暴露無疑。1995年，芬蘭學者Tatu Ylonen設計了SSH協議，將登錄信息全部加密，成爲互聯網安全的一個基本解決方案，迅速在全世界獲得推廣，目前已經成爲Linux系統的標準配置。
需要指出的是，SSH只是一種協議，存在多種實現，既有商業實現，也有開源實現。本文針對的實現是OpenSSH，它是自由軟件，應用非常廣泛。
此外，本文只討論SSH在Linux Shell中的用法。如果要在Windows系統中使用SSH，會用到另一種軟件PuTTY，這需要另文介紹。
二、最基本的用法
SSH主要用於遠程登錄。假定你要以用戶名user，登錄遠程主機host，只要一條簡單命令就可以了。
$ ssh user@host
如果本地用戶名與遠程用戶名一致，登錄時可以省略用戶名。
$ ssh host
SSH的默認端口是22，也就是說，你的登錄請求會送進遠程主機的22端口。使用p參數，可以修改這個端口。
$ ssh -p 2222 user@host
上面這條命令表示，ssh直接連接遠程主機的2222端口。
三、中間人攻擊
SSH之所以能夠保證安全，原因在於它採用了公鑰加密。
整個過程是這樣的：（1）遠程主機收到用戶的登錄請求，把自己的公鑰發給用戶。（2）用戶使用這個公鑰，將登錄密碼加密後，發送回來。（3）遠程主機用自己的私鑰，解密登錄密碼，如果密碼正確，就同意用戶登錄。
這個過程本身是安全的，但是實施的時候存在一個風險：如果有人截獲了登錄請求，然後冒充遠程主機，將僞造的公鑰發給用戶，那麼用戶很難辨別真僞。因爲不像https協議，SSH協議的公鑰是沒有證書中心（CA）公證的，也就是說，都是自己簽發的。
可以設想，如果攻擊者插在用戶與遠程主機之間（比如在公共的wifi區域），用僞造的公鑰，獲取用戶的登錄密碼。再用這個密碼登錄遠程主機，那麼SSH的安全機制就蕩然無存了。這種風險就是著名的"中間人攻擊"（Man-in-the-middle attack）。
SSH協議是如何應對的呢？
四、口令登錄
如果你是第一次登錄對方主機，系統會出現下面的提示：
$ ssh user@host
The authenticity of host 'host (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)?
這段話的意思是，無法確認host主機的真實性，只知道它的公鑰指紋，問你還想繼續連接嗎？
所謂"公鑰指紋"，是指公鑰長度較長（這裏採用RSA算法，長達1024位），很難比對，所以對其進行MD5計算，將它變成一個128位的指紋。上例中是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)? yes
系統會出現一句提示，表示host主機已經得到認可。
Warning: Permanently added 'host,12.18.429.21' (RSA) to the list of known hosts.
然後，會要求輸入密碼。
Password: (enter password)
如果密碼正確，就可以登錄了。
當遠程主機的公鑰被接受以後，它就會被保存在文件$HOME/.ssh/known_hosts之中。下次再連接這臺主機，系統就會認出它的公鑰已經保存在本地了，從而跳過警告部分，直接提示輸入密碼。
每個SSH用戶都有自己的known_hosts文件，此外系統也有一個這樣的文件，通常是/etc/ssh/ssh_known_hosts，保存一些對所有用戶都可信賴的遠程主機的公鑰。
五、公鑰登錄
使用密碼登錄，每次都必須輸入密碼，非常麻煩。好在SSH還提供了公鑰登錄，可以省去輸入密碼的步驟。
所謂"公鑰登錄"，原理很簡單，就是用戶將自己的公鑰儲存在遠程主機上。登錄的時候，遠程主機會向用戶發送一段隨機字符串，用戶用自己的私鑰加密後，再發回來。遠程主機用事先儲存的公鑰進行解密，如果成功，就證明用戶是可信的，直接允許登錄shell，不再要求密碼。
這種方法要求用戶必須提供自己的公鑰。如果沒有現成的，可以直接用ssh-keygen生成一個：
$ ssh-keygen
運行上面的命令以後，系統會出現一系列提示，可以一路回車。其中有一個問題是，要不要對私鑰設置口令（passphrase），如果擔心私鑰的安全，這裏可以設置一個。
運行結束以後，在$HOME/.ssh/目錄下，會新生成兩個文件：id_rsa.pub和id_rsa。前者是你的公鑰，後者是你的私鑰。
這時再輸入下面的命令，將公鑰傳送到遠程主機host上面：
$ ssh-copy-id user@host
好了，從此你再登錄，就不需要輸入密碼了。
如果還是不行，就打開遠程主機的/etc/ssh/sshd_config這個文件，檢查下面幾行前面"#"註釋是否取掉。
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
然後，重啓遠程主機的ssh服務。
// ubuntu系統
service ssh restart// debian系統
/etc/init.d/ssh restart
六、authorized_keys文件
遠程主機將用戶的公鑰，保存在登錄後的用戶主目錄的$HOME/.ssh/authorized_keys文件中。公鑰就是一段字符串，只要把它追加在authorized_keys文件的末尾就行了。
這裏不使用上面的ssh-copy-id命令，改用下面的命令，解釋公鑰的保存過程：
$ ssh user@host 'mkdir -p .ssh && cat >> .ssh/authorized_keys' < ~/.ssh/id_rsa.pub
這條命令由多個語句組成，依次分解開來看：（1）"$ ssh user@host"，表示登錄遠程主機；（2）單引號中的mkdir .ssh && cat >> .ssh/authorized_keys，表示登錄後在遠程shell上執行的命令：（3）"$ mkdir -p .ssh"的作用是，如果用戶主目錄中的.ssh目錄不存在，就創建一個；（4）'cat >> .ssh/authorized_keys' < ~/.ssh/id_rsa.pub的作用是，將本地的公鑰文件~/.ssh/id_rsa.pub，重定向追加到遠程文件authorized_keys的末尾。
寫入authorized_keys文件後，公鑰登錄的設置就完成了。
七、遠程操作
SSH不僅可以用於遠程主機登錄，還可以直接在遠程主機上執行操作。
上一節的操作，就是一個例子：
$ ssh user@host 'mkdir -p .ssh && cat >> .ssh/authorized_keys' < ~/.ssh/id_rsa.pub
單引號中間的部分，表示在遠程主機上執行的操作；後面的輸入重定向，表示數據通過SSH傳向遠程主機。
這就是說，SSH可以在用戶和遠程主機之間，建立命令和數據的傳輸通道，因此很多事情都可以通過SSH來完成。
下面看幾個例子。
【例1】
將$HOME/src/目錄下面的所有文件，複製到遠程主機的$HOME/src/目錄。
$ cd && tar czv src | ssh user@host 'tar xz'
【例2】
將遠程主機$HOME/src/目錄下面的所有文件，複製到用戶的當前目錄。
$ ssh user@host 'tar cz src' | tar xzv
【例3】
查看遠程主機是否運行進程httpd。
$ ssh user@host 'ps ax | grep [h]ttpd'
八、綁定本地端口
既然SSH可以傳送數據，那麼我們可以讓那些不加密的網絡連接，全部改走SSH連接，從而提高安全性。
假定我們要讓8080端口的數據，都通過SSH傳向遠程主機，命令就這樣寫：
$ ssh -D 8080 user@host
SSH會建立一個socket，去監聽本地的8080端口。一旦有數據傳向那個端口，就自動把它轉移到SSH連接上面，發往遠程主機。可以想象，如果8080端口原來是一個不加密端口，現在將變成一個加密端口。
九、本地端口轉發
有時，綁定本地端口還不夠，還必須指定數據傳送的目標主機，從而形成點對點的"端口轉發"。爲了區別後文的"遠程端口轉發"，我們把這種情況稱爲"本地端口轉發"（Local forwarding）。
假定host1是本地主機，host2是遠程主機。由於種種原因，這兩臺主機之間無法連通。但是，另外還有一臺host3，可以同時連通前面兩臺主機。因此，很自然的想法就是，通過host3，將host1連上host2。
我們在host1執行下面的命令：
$ ssh -L 2121:host2:21 host3
命令中的L參數一共接受三個值，分別是"本地端口:目標主機:目標主機端口"，它們之間用冒號分隔。這條命令的意思，就是指定SSH綁定本地端口2121，然後指定host3將所有的數據，轉發到目標主機host2的21端口（假定host2運行FTP，默認端口爲21）。
這樣一來，我們只要連接host1的2121端口，就等於連上了host2的21端口。
$ ftp localhost:2121
"本地端口轉發"使得host1和host3之間彷彿形成一個數據傳輸的祕密隧道，因此又被稱爲"SSH隧道"。
下面是一個比較有趣的例子。
$ ssh -L 5900:localhost:5900 host3
它表示將本機的5900端口綁定host3的5900端口（這裏的localhost指的是host3，因爲目標主機是相對host3而言的）。
另一個例子是通過host3的端口轉發，ssh登錄host2。
$ ssh -L 9001:host2:22 host3
這時，只要ssh登錄本機的9001端口，就相當於登錄host2了。
$ ssh -p 9001 localhost
上面的-p參數表示指定登錄端口。
十、遠程端口轉發
既然"本地端口轉發"是指綁定本地端口的轉發，那麼"遠程端口轉發"（remote forwarding）當然是指綁定遠程端口的轉發。
還是接着看上面那個例子，host1與host2之間無法連通，必須藉助host3轉發。但是，特殊情況出現了，host3是一臺內網機器，它可以連接外網的host1，但是反過來就不行，外網的host1連不上內網的host3。這時，"本地端口轉發"就不能用了，怎麼辦？
解決辦法是，既然host3可以連host1，那麼就從host3上建立與host1的SSH連接，然後在host1上使用這條連接就可以了。
我們在host3執行下面的命令：
$ ssh -R 2121:host2:21 host1
R參數也是接受三個值，分別是"遠程主機端口:目標主機:目標主機端口"。這條命令的意思，就是讓host1監聽它自己的2121端口，然後將所有數據經由host3，轉發到host2的21端口。由於對於host3來說，host1是遠程主機，所以這種情況就被稱爲"遠程端口綁定"。
綁定之後，我們在host1就可以連接host2了：
$ ftp localhost:2121
這裏必須指出，"遠程端口轉發"的前提條件是，host1和host3兩臺主機都有sshD和ssh客戶端。
十一、SSH的其他參數
SSH還有一些別的參數，也值得介紹。
N參數，表示只連接遠程主機，不打開遠程shell；T參數，表示不爲這個連接分配TTY。這個兩個參數可以放在一起用，代表這個SSH連接只用來傳數據，不執行遠程操作。
$ ssh -NT -D 8080 host
f參數，表示SSH連接成功後，轉入後臺運行。這樣一來，你就可以在不中斷SSH連接的情況下，在本地shell中執行其他操作。
$ ssh -f -D 8080 host
要關閉這個後臺連接，就只有用kill命令去殺掉進程。
十二、參考文獻
* SSH, The Secure Shell: The Definitive Guide: 2.4. Authentication by Cryptographic Key, O'reilly
* SSH, The Secure Shell: The Definitive Guide: 9.2. Port Forwarding, O'reilly
* Shebang: Tips for Remote Unix Work (SSH, screen, and VNC)
* brihatch: SSH Host Key Protection
* brihatch: SSH User Identities
* IBM developerWorks: 實戰 SSH 端口轉發
* Jianing YANG：ssh隧道技術簡介
* WikiBooks: Internet Technologies/SSH
* Buddhika Chamith: SSH Tunneling Explained