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

1.原理簡介

爲了便於理解，假設須要在hadoop148這臺機器上能夠經過無密碼登陸的方式鏈接到hadoop107上。

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

而後當 hadoop148通 過 SSH 鏈接hadoop107機器時， hadoop107機器 就會生成一個隨機數並用 hadoop148的公 鑰對隨機數進行加密，併發送給 hadoop148。

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

2 .配置

具體步驟

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 yes
 
PubkeyAuthentication yes
 
AuthorizedKeysFile      .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

3.常見問題

問題現象：

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 /root

Jan  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.2cto.com/os/201503/383435.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:s0
restorecon reset /home/lost+found context system_u:object_r:file_t:s0->system_u:object_r:lost_found_t:s0
restorecon reset /home/sw/.pki context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:home_cert_t:s0
restorecon 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，認證成功，問題解決。

-----------------------------下面是個人centos系統遇到也是不能從106無密碼登陸到104上的解決辦法-----------

個人安裝上面的第一步作了，發現仍是鏈接不上，而後我就按照第二步，去查看/root/.ssh的context，果真一看就不是ssh_home_t ，內容以下：

而後我恢復了/root/.ssh的上下文

而後在查看一下/root/.ssh的上下文

而後從106無密碼登陸到104上發現能夠了。成功了！成功解決問題。