CentOS SSH無密碼登入原理，配置以及常見問題，centosssh

CentOS SSH無密碼登入原理，配置以及常見問題，centosssh
原理簡介 

為了便於理解，假設需要在hadoop148這台機器上可以通過無密碼登入的方式串連到hadoop107上。

首先在 hadoop148上產生一個密 鑰對，包括一個公開金鑰和一個私密金鑰，並將公開金鑰複製到hadoop107上。

然後當 hadoop148通 過 SSH 串連hadoop107機器時， hadoop107機器 就會產生一個隨機數並用 hadoop148的公 鑰對隨機數進行加密，並發送給 hadoop148。

最後 hadoop148收到加密數之後再用私 鑰解密，並將解密數回傳給hadoop107， hadoop107確認解密數無誤之後就允許 hadoop148不 輸入密碼進行串連了

配置

具體步驟

1 、 登入hadoop148,執行命令 ssh-keygen -t rsa 之後一路回 車，查看剛產生的無密碼鑰對： cd .ssh 後 執行 ll

2 、把 id_rsa.pub 追加到授權的 key 裡面去。 執行命令 cat ~/.ssh/id_rsa.pub >>~/.ssh/authorized_keys

3 、修改許可權： 執行 chmod 600 ~/.ssh/authorized_keys

4 、確保 cat /etc/ssh/sshd_config 中存在如下內容

RSAAuthentication yesPubkeyAuthentication yesAuthorizedKeysFile      .ssh/authorized_keys

如需修改， 則在修改後執行重啟 SSH 服 務命令使其生效 :service sshd restart

5 、將公 鑰複製到所有其他機器上 :scp ~/.ssh/id_rsa.pub root@hadoop107:~/    然後 輸入 yes ，最後 輸入 hadoop107機器的密 碼

6 、在 hadoop107 機器上 建立 .ssh 檔案夾 :

        mkdir ~/.ssh 

        然後 執行 chmod 700 ~/.ssh （若檔案夾以存在 則不需要建立）

7 、追加到授權檔案 authorized_keys 執行命令 :

        cat ~/id_rsa.pub >> ~/.ssh/authorized_keys 

        然後 執行 chmod 600 ~/.ssh/authorized_keys

8 、重複第 4 步

9 、 驗證命令 : 在 hadoop148機器上 執行 ssh hadoop107發現主機名稱由 hadoop148變成 hadoop107即成功，最後 刪除 id_rsa.pub 檔案 :rm -r id_rsa.pub

常見問題 問題現象：

hadoop148機器已經生產rsa密鑰

且已經將public key添加到serverB機器/root/.ssh/authorized_keys

但是ssh root@hadoop107機器時仍然需要輸入密碼，即無密碼認證失敗，

分析與處理：

第一步：查看許可權

用ssh -v debug訪問，日誌如下，但是從日誌看不到失敗原因，只知道在用publickey認證時，對端沒有reply;

再查看/var/log/secure日誌

通過查看hadoop107機器/var/log/secure，發現報錯如下

Jan  8 13:31:34 wng-141 sshd[32366]: Authentication refused: bad ownership or modes for directory /rootJan  8 13:31:34 wng-141 sshd[32367]: Connection closed by 135.251.218.231

由此日誌，可能是/root目錄的許可權不對，"Authentication refused: bad ownership or modes for directory /root"

發現所有使用者的HOME目錄應該是700許可權，否則會引起很多問題，這個問題同樣是由於這個原因

最終，執行chmod 700 root後解決

關於許可權問題總結如下：

1) .ssh目錄的許可權必須是700

2) 使用者目錄的許可權必須是700，比如我是用root使用者操作的，則/root的許可權必須是700
3) .ssh/authorized_keys檔案許可權必須是600

第二部：查看安全上下文

如果通過改變許可權還不能解決問題，可以嘗試如下方法：

首先用ls -laZ檢查了一下.ssh目錄，果然不是ssh_home_t，則需要使用restorecon命令對.ssh目錄的context進行恢複。命令是：restorecon -r -vv /root/.ssh

第三部：分析/var/log/audit/audit.log日誌

如果還是不行，查看hadoop107的audit.log檔案，裡面或許有錯誤的相關資訊
處理方法引用：http://www.cnblogs.com/qcly/archive/2013/07/27/3219535.html 文章裡的處理方式：

我如獲救命稻草，馬上用ls -laZ檢查了一下我的.ssh目錄，果然不是ssh_home_t，心中竊喜，立刻使用restorecon對.ssh目錄的context進行了恢複。 再次嘗試進行串連，結果還是不行，現象和出錯資訊與之前一樣。於是我查看了其它機器上的.ssh目錄的context，都沒有標為 ssh_home_t，但是那些機器上的SSH服務都是正常的。我又仔細看了一下網上那個案例的描述和錯誤資訊，我還是懷疑是SELinux導致的。於是 我想把SELinux暫時關了試試，使用setenforce 0把SELinux關閉，重新嘗試串連，publickey認證正常了。 確認了是SELinux引發的問題，接下來我查看了/var/log/audit/audit.log，發現有如下日誌：

type=AVC msg=audit(1362560807.992:320): avc:  denied  { search } for  pid=1595 comm="sshd" name="/" dev=sda3 ino=2 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir

這條日誌與網上案例唯一不同的地方在於案例中是sshd對分區dm-0中的authorized_keys檔案沒有read許可權，而我的機器上是sshd對分區sda3的根沒有search許可權。 確認了問題所在，我仔細回憶了系統的安裝過程與其它機器有什麼不同之處。日誌中提到的sda3是系統的/home分區，當時裝系統的時候由於操 作失誤/home分區只有200M，裝完系統以後發現了這個問題，於是我把sda3分區刪除重建，然後掛載到/home。這麼一折騰，/home目錄上的 context就不對了。 之後我對/home目錄的context進行恢複：

[root@data ~]# restorecon -r -vv /home/restorecon reset /home context system_u:object_r:file_t:s0->system_u:object_r:home_root_t:s0restorecon reset /home/lost+found context system_u:object_r:file_t:s0->system_u:object_r:lost_found_t:s0restorecon reset /home/sw/.pki context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:home_cert_t:s0restorecon reset /home/sw/.pki/nssdb context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:home_cert_t:s0

然後setenforce 1開啟SELinux，重新串連SSH，認證成功，問題解決。