一：理論
從客戶端來看，ssh提供兩種級別的安全驗證:
第一種級別（基於口令的安全驗證）
只要你知道自己帳號和口令，就可以登入到遠端主機。所有傳輸的資料都會被加密，但是不能保證你正在連線的伺服器就是你想連線的伺服器。
第二種級別（基於密匙的安全驗證）
需要依靠
金鑰，也就是你必須為自己建立一對密匙，並把公用密匙放在需要訪問的伺服器上。如果你要連線到ssh伺服器上，客戶端軟體就會向伺服器發出請求，請求用你的密匙進行安全驗證。伺服器收到請求之後，先在該伺服器上你的主目錄下尋找你的公用密匙，然後把它和你傳送過來的公用密匙進行比較。如果兩個密匙一致，伺服器就用公用密匙加密「質詢」（challenge）並把它傳送給客戶端軟體。客戶端軟體收到「質詢」之後就可以用你的私人密匙解密再把它傳送給伺服器。這種級別的驗證不需要再網路上傳送口令。
二：基本用法
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）。
造成該問題的原因：
客戶端不知道收到的公鑰到底是不是由真正的目的伺服器發來的。
目的伺服器得事先公布自己的公鑰。當客戶端收到遠端伺服器的公鑰時，與目的伺服器自己事先公布的公鑰對比.
the authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.
ecdsa key fingerprint is 50:76:f4:8e:eb:38:c6:e9:d5:5b:c7:49:77:a9:4c:b4.
are you sure you want to continue connecting (yes/no)?
這段話的意思是，無法確認host主機的真實性，只知道它的公鑰指紋，問你還想繼續連線嗎？
所謂"公鑰指紋"，是指公鑰長度較長（這裡採用rsa演算法，長達1024位），很難比對，所以對其進行md5計算，將它變成乙個128位的指紋。上例中是50:76:f4:8e:eb:38:c6:e9:d5:5b:c7:49:77:a9:4c:b4，再進行比較，就容易多了。
很自然的乙個問題就是，使用者怎麼知道遠端主機的公鑰指紋應該是多少？回答是沒有好辦法，遠端主機必須在自己的**上貼出公鑰指紋，以便使用者自行核對。
假定經過風險衡量以後，使用者決定接受這個遠端主機的公鑰。
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)如果密碼正確，就可以登入了。
當遠端主機的公鑰被接受以後，它就會被儲存在客戶端本身的 ～/.ssh/目錄下會生成：know_hosts。下次再連線這台主機，系統就會認出它的公鑰已經儲存在本地了，從而跳過警告部分，直接提示輸入密碼。
每個ssh使用者都有自己的known_hosts檔案，此外系統也有乙個這樣的檔案，通常是/etc/ssh/ssh_known_hosts，儲存一些對所有使用者都可信賴的遠端主機的公鑰。
四：公鑰登入
使用密碼登入，每次都必須輸入密碼，非常麻煩。好在ssh還提供了公鑰登入，可以省去輸入密碼的步驟。
ssh公鑰登陸同樣遵循私鑰加密、公鑰解密;linux客戶端先生成ssh公鑰傳送給遠端主機更名為authorized_keys，
①linux客戶端向遠端主機傳送連線,遠端主機隨意發給linux客戶端一串字串
②linux客戶端用私鑰加密字串返還給遠端主機
③遠端主機用事先儲存的公鑰進行解密,如果和事先傳送的字串一致則允許登陸。
這種方法要求使用者必須提供自己的公鑰：
$ ssh-keygen
執行上面的命令以後，系統會出現一系列提示，可以一路回車。其中有乙個問題是，要不要對私鑰設定口令（passphrase），如果擔心私鑰的安全，這裡可以設定乙個。
執行結束以後，在～/.ssh/目錄下，會新生成兩個檔案：id_rsa.pub和id_rsa。前者是公鑰，後者是私鑰。
$ ssh-copy-id user@host 直接將公鑰儲存在遠端主機的~/.ssh/authorized_keys檔案中注意:確保遠端主機/etc/ssh/sshd_config這個檔案中，下面三行沒有注釋；否則可能無法實現無密碼登入。
rsaauthentication yes
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys
五：authorized_keys檔案
authorized_keys檔案
遠端主機將使用者的公鑰，儲存在登入後的使用者主目錄的～/.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 -p .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檔案後，公鑰登入的設定就完成了。
ps:
ssh 的客戶端和伺服器都會擁有乙個公鑰和對應的私鑰。用公鑰對一段資料進行加密，有且僅有對應的私鑰能對該段資料解密，反之亦然。公鑰會在網路上傳播，但私鑰不會在網路上傳輸。
登入方式1：基於遠端主機的使用者和密碼登入
客戶端通過ssh命令請求登入遠端伺服器
伺服器收到請求後，將自己的公鑰傳送給客戶端
客戶端利用收到的服務端的公鑰對登入密碼進行加密，將加密後的密碼傳送給伺服器。
伺服器利用自己的私鑰對收到的密碼進行解密，並且驗證其密碼，如果密碼正確，允許該客戶端登入。
客戶端登入成功。 用 exit 命令退出登入。 登入超時 時間取決於伺服器的配置。
登入方式2：基於客戶端公鑰的登入 ／／必須對伺服器進行配置，並且使配置生效。
客戶端將自己的公鑰事先儲存在伺服器中，一般為～／.ssh/authorized_keys中。
客戶端通過ssh命令請求登入遠端伺服器時，伺服器將一段隨機碼發回給客戶端。客戶端用自己私鑰對該隨機串加密後傳送到伺服器。伺服器利用該客戶端的公鑰解密之後即可完成認證。
ssh學習筆記
一直對shh很感興趣，也一直有用shh開發東西，但是學習地並不深入。1.ssh開發最好用myeclipse,這個ide真的非常好用，框架搭建基本不用花太大的力氣。2.當用hibernate去鏈結oracle的時候經常會出現sid識別不了的情況，這時候就要去修改一下oracle的配置檔案裡。3.ora...
SSH學習筆記 一
昨天在使用hibernate運算元據庫是出現了兩個異常，弄了很久才把問題解決，現在想把解決過程記錄下來，希望能給遇到跟我一樣問題的朋友一些幫助，o o 1.ora 01843 not a valid month 異常解決辦法。由於我裝的作業系統是英文版的，預設的日期格式為dd mm yyyy，而or...
學習ssh服務筆記
1.ssh服務是應用層服務，工作在tcp的22號埠。2.ssh服務是c s架構的。3.ssh協議有v1 和v2，2個版本，因為v1協議無法抵禦中間人 所以目前主流的用的都是v2協議。4.ssh與telent遠端登入服務的區別是 使用ssh服務的ssh客戶端與服務端使用者認證和資料傳輸都是以加密方式傳...