SSH學習筆記

登陸的基本原理

非對稱加密

SSH是基於非對稱加密實現的。

非對稱加密的特色

• 祕鑰由公鑰跟私鑰組成
• 公鑰會分發到須要發起通訊的多個網絡節點。圖中的TopGun既是這樣的節點
• 私鑰會存儲在Server端，不會處處分發
• 使用公鑰加密的內容，只有私鑰才能解密
• TopGun發起通訊時，使用公鑰加密。即使被中間人截獲，也沒法解密內容，由於他沒有私鑰
• Server使用私鑰對密文進行解密，得到通訊內容

SSH流程

1. 第一次登錄時，remote server會將本身的公鑰下發給client端。同時提示client以下信息

   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)?

   客戶端選yes後，會將遠程主機的host, ip,公鑰放置到本身的.ssh/known_hosts文件中，這使得後續登陸，能夠省去第一步。一個典型的know_hosts文件樣例

   ldn01.jamieweb.net,139.162.222.67 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC4bVleGrAZFttdMBen/ExLWbUUr5UaaX3Wd8U4nwH6LEaOMxuYu2cyrBuwIVZ9gjSoI0fEWhe345HeQJbdNzE/rd5ojebtS9bQiAB9+GVNKHxemBP01M0OaZJVA/GJnSzjdoEfrCGG8SWIDPQjY02yTQwgQHW5zYlr12Hq3FjKzofJ1Q2PSWbCy3crsA/R4vPHRVLPd8RDj+EXWVwvFgTHriuQWnt9Q/djy1LOPrqNgHn1n17cIED1M0zgXpImoLNC+Z44DmopVdmtwRW57IkedktWQdpCNRYTyOj/as/xn5YStXIWwxila16NYeq6O7zqoedWPiad6qnFloobOcft
   nyc01.jamieweb.net,157.230.83.95 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC8Gh3exdEvvWqZHdbBogN3kbfutx3af0oO9dof1L+4vFsA8xmMOURjdB/BF9uF44i+1yosOhxh+k0Kjgeo0JAjPWy8e94SpEn2oUFJ3/9y1QzpWR81aAi/B9gSX9KR6uDys1yIhjjBKE0omP6vvSSVndY7BkxXnxBsmvWqeCWP59tFFDVFADG4FLRQW6IPUlD3mJLXxzsbsBUP4x67TAFeHynL/ZyImSlHXWBow3hWopwPouqQpkcIcUZxdt8zR9xmAiEwk8wUDWQg5aMoYp2a8zy7fuUL6PXyomRpoVWKHyZposl1cmST88NXjK+J14oWPHzKAd7zcY29XOXSbKnR

2. 客戶端基於該公鑰，加密本身的登陸密碼，發送給remote server 。 remote server基於本身的私鑰，解密消息，得到client發送的密碼，完成認證。因爲私鑰只有server端有，因此即使中間人攻擊，拿刀消息，也沒法解密獲取client發送的密碼

安全風險

在第一次登陸時，server下發本身的公鑰，client須要信任並存儲該公鑰，這一步若是被中間人攻擊，中間人下發了本身的公鑰。從而可以獲取到client的登陸密碼， 中間人再做爲client去跟remote server完成登陸

公鑰免密登陸

前面SSH登陸中，每次都要輸入本身的密碼，很繁瑣。能夠繼續利用非對稱加密的原理。client本身也生成一組密鑰對。將公鑰上傳至remote server。這樣client和server雙方，彼此都有一組公私密鑰對，整個登陸過程，均可以加密進行，而不須要密碼。具體步驟。

配置步驟

client使用ssh-keygen命令，生成一組公私密鑰對。生成後通常在.ssh文件夾下，其中id_rsa爲私鑰，id_rsa.pub爲公鑰，將公鑰上傳至remote server 。這一步僅需作一次。

client的公鑰上傳後，通常存在server 端的/.ssh/authorized_keys文件中。

將公鑰上傳至server 的authorized_keys文件的方法有幾種

• 方式1，直接將公鑰內容，拷貝到server的.ssh/authorized_keys文件中去。拷貝可使用命令ssh user@host 'mkdir -p .ssh && cat >> .ssh/authorized_keys' < ~/.ssh/id_rsa.pub，也能夠直接登陸到server,而後手動編輯authorized_keys文件。
• 方式2，使用命令ssh-copy-id user@host

登陸認證步驟

1. Client將本身的公鑰存放在Server上，追加在文件authorized_keys中。
2. Server端接收到Client的鏈接請求後，會在authorized_keys中匹配到Client的公鑰pubKey，並生成隨機數R，用Client的公鑰對該隨機數進行加密獲得pubKey(R)
   ，而後將加密後信息發送給Client。
3. Client端經過私鑰進行解密獲得隨機數R，而後對隨機數R和本次會話的SessionKey利用MD5生成摘要Digest1，發送給Server端。
4. Server端會也會對R和SessionKey利用一樣摘要算法生成Digest2。
5. Server端會最後比較Digest1和Digest2是否相同，完成認證過程。

ssh服務的管理

.ssh目錄結構

.ssh 文件像user的.profile同樣，是跟用戶相關的。也即root和ops這兩個用戶，其.ssh的路徑和其下的內容是不同的。.ssh文件的目錄結構

• id_rsa 私鑰
• id_rsa.pub 公鑰
• known_hosts 存儲了本機作爲client，與多個server通訊時，多個server的公鑰
• authorized_keys 存儲了本機做爲server時，多個client的公鑰，以使得client能免密登陸

centos中ssh守護進程的管理

查詢守護進程的狀態service sshd status
重啓service sshd restarts
啓動service sshd start
中止service sshd stop

通常更改了/etc/ssh/sshd_config文件，則須要重啓sshd服務

一些遠程登陸的配置異常

錯誤1

Authentication refused: bad ownership or modes for file /somepath/.ssh/authorized_keys

這個錯誤的緣由是，SSH server會在有登陸訪問請求時，檢查authorized_keys文件的權限是否配置正確，具體來講，就是不能開放給除當前用戶意外的其它用戶寫權限。因此解決辦法很簡單。確認下authorized_keys文件的group和Others是否寫權限，有的話，直接去掉

chmod g-w authorized_keys

之因此有這個限制緣由是，一個.ssh文件應該只跟對應的用戶相關，至關於用戶的profile，該文件的編輯權限，應該只有當前用戶，和root能夠去編輯。而不能容許其它用戶去編輯，不然其它用戶能夠很容易的添加一些不惡意的client的公鑰到該文件，使得惡意的client能夠登陸到該server。

固然，你能夠不改authorized_keys的權限，而是把/etc/ssh/sshd_config配置文件中的StrictModes 設爲no ，從而使得sshd不對文件的權限作校驗，但很是不建議這麼作。

參考連接

https://www.jianshu.com/p/33461b619d53
https://www.ruanyifeng.com/blog/2011/12/ssh_remote_login.html
https://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/
https://tldp.meulie.net/en/solrhe/chap15sec122.html