Linux ssh密鑰自動登錄 專題

在開發中，經常需要從一台主機ssh登陸到另一台主機去，每次都需要輸一次login/Password，很繁瑣。
使用密鑰登陸就可以不用輸入用戶名和密碼了

實現從主機A免密碼登陸到主機B(即把主機A的pub密鑰--公鑰，添加到主機B的~/.ssh/authorized_keys文件中即可)，需要以下幾個步驟：
1. 在主機A“~/.ssh/”目錄下執行命令“ssh-keygen -t rsa”（生成過程中，一路回車）,生成兩個文件id_rsa和id_rsa_pub，這兩個文件實際上是一個密鑰對，id_rsa是私鑰，id_rsa_pub是公鑰；
2. 將文件id_rsa_pub從主機A拷貝（可以使用scp命令）到主機B“~/.ssh/”目錄下；

scp local_file remote_username@remote_ip:remote_folder

3. 登陸到主機B上， 進入“~/.ssh/”目錄，將從主機拷貝來的id_rsa_pub文件添加到文件“authorized_keys”尾部（cat id_rsa_pub>>authorized_keys）,若文件“authorized_keys”不存在，則創建；確保“~/.ssh/authorized_keys”的權限至少為600；

4. 從主機A登陸主機B，第一次登陸時主機B要自動設置known_hosts文件，所以需要輸入yes，以后就不需要了；

P.S.當然你登陸主機A和主機B用的是同一個用戶名

配置用戶的公鑰登陸時，配置完authorized_keys居然一直不生效，於是google之，發現原來是因為.ssh目錄和下面文件的權限問題導致的，因為目錄的權限已經超過了sshd的要求權限。

如果希望ssh公鑰生效需滿足至少下面兩個條件：
1) .ssh目錄的權限必須是700 
2) .ssh/authorized_keys文件權限必須是600

r=4
w=2
x=1 

 

可能出現的問題，主機A登陸主機B時，自動登陸會失效：“Agent admitted failure to sign using the key.”

在主機A使用 ssh-add 指令將私鑰 加進來 （根據個人的密匙命名不同更改 id_rsa）

ssh-add   ~/.ssh/id_rsa 

如果報“Could not open a connection to your authentication agent.”
則執行命令：

ssh-agent bash --login -i

錦上添花：
假設你的用戶名為user,已經設置好了密鑰登陸主機B。那么你可以在shell的配置文件（比如.bashrc）里定義一個alias
alias b='ssh user@B'
以后每次你啟動shell終端后，輸入b，回車，直接就ssh登陸到主機B上。

 

ssh連接失敗，排錯經驗 http://www.cnblogs.com/softidea/p/4710513.html

記一次詭異的 ssh 互信免密碼登錄失敗【劇透一下，是 .ssh目錄和 .ssh/authorized_keys的權限沒有設置好 造成的】
下面是排查過程：

0、背景
因為 hadoop 環境需要 master 能免密碼 ssh localhost，所以我們需要建立與本機 localhost 的互信，方法很簡單：

1. ssh-keygen -t rsa
   #Press enter for each line 
2. cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
3. chmod og-wx ~/.ssh/authorized_keys

這三步執行下來就能順利 ssh localhost 免密碼登錄了，但是昨天剛建好的互信，今天下午突然不能用了，ssh localhost 需要密碼，
第一反應是可能哪里設置和配置被改動了，看了下文件版本、配置修改時間都無變化，然而登錄時的提示信息又過於簡單，這個時候排查陷入僵局了。

work@test_zz_Master 192.168.187.213 18:45:18 ~ >
ssh localhost            
work@localhost's password: 
 
work@test_zz_Master 192.168.187.213 18:45:24 ~ >

1、怎么排查？
1.1 debug 日志
首先還是要拿到明細 debug 日志，看看卡在哪里了。
linux 下的不少命令都自帶調試功能，比如 ssh 就自帶 debug 功能：

ssh -vvv localhost
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/work/.ssh/identity type -1
debug1: identity file /home/work/.ssh/identity-cert type -1
...
debug3: remaining preferred: keyboard-interactive,password
// 啟用公鑰登錄
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/work/.ssh/identity
debug3: no such identity: /home/work/.ssh/identity
debug1: Offering public key: /home/work/.ssh/id_rsa
debug3: send_pubkey_test
// 發送公鑰包，等待服務器認證響應
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 368 bytes for a total of 1741
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/work/.ssh/id_dsa
debug3: no such identity: /home/work/.ssh/id_dsa
debug1: Trying private key: /home/work/.ssh/id_ecdsa
debug3: no such identity: /home/work/.ssh/id_ecdsa
// 沒通過認證，禁用該認證方法
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
// 下一個認證方法：啟用密碼登錄
debug1: Next authentication method: password
work@localhost's password:

可以看到，確實是認證失敗了，但是僅憑一句 we did not send a packet, disable method，咱們還是無法看到失敗的深層次原因，那咱們再對比下正常的認證流程應該是怎樣的：


可以看到右邊正常的會接受公鑰，左邊的則沒有得到響應，繼續走別的認證方式。

1.2 檢查配置
打開服務器的 /etc/ssh/sshd_config
確認下面幾行是這樣的:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
 
#GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes

配置沒問題，此路還是不通。
1.3 Debugging SSH public key
在B機器上，we sent a public key packet, wait for reply 之后則是緊跟着”debug1: Server accepts key: pkalg ssh-rsa blen 277″。由此可以看出，是A機器的sshd不認可publickey。

至於為什么不認可，在google上查了許多，毫無頭緒，直到使用類似“ssh publickey ignore debug diagnose”這樣的關鍵詞，發現這個頁面，其中的第二條和第六條給出了解答：

2. Debugging on the remote host by running sshd in debug mode: Run ‘/usr/sbin/sshd -d -p 2222′ on the remote host and connect to it.
 ’2222′ here is the port number of the sshd process you started on the remote host.

6. Check the permissions on your home directory, .ssh directory, 
and the authorized_keys file: If your ssh server is running with ‘StrictModes on’, it will refuse to use your public keys in the ~/.ssh/authorized_keys file. 
Your home directory should be writable only by you, ~/.ssh should be 700, and authorized_keys should be 600.

通過執行 /usr/sbin/sshd -d -p 2222 （在2222端口啟動一個帶debug輸出的sshd） ，
然后 ssh -vv localhost -p 2222 ，可以看到 sshd 的輸出：

[root(hostname)@bjdhj-187-213 ~]# /usr/sbin/sshd -d -p 2222
debug1: sshd version OpenSSH_5.3p1
debug1: read PEM private key done: type RSA
...
debug1: trying public key file /home/work/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /home/work
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 500/500 (e=0/0)
debug1: trying public key file /home/work/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /home/work
debug1: restore_uid: 0/0
Failed publickey for work from 127.0.0.1 port 45548 ssh2

可以看到倒數第三行：Authentication refused: bad ownership or modes for directory /home/work，
正好與那第六條相對應，再檢查一下 /home/work ，其權限是否是其他組可讀寫。
同時，咱們也能從 /var/log/secure 看到明細的 debug 日志：

[root(hostname)@bjdhj-187-213 ~]# tail -f /var/log/secure
Sep  1 18:52:20 bjdhj-187-213 sshd[30936]: Server listening on 0.0.0.0 port 22.
Sep  1 18:52:23 bjdhj-187-213 sshd[30944]: Authentication refused: bad ownership or modes for directory /home/work
Sep  1 18:52:23 bjdhj-187-213 sshd[30944]: Authentication refused: bad ownership or modes for directory /home/work
Sep  1 18:52:25 bjdhj-187-213 sshd[30948]: Connection closed by 127.0.0.1

2、最終解決方案
ssh 為了保證通信安全，防止 key 被篡改或竊取，對目錄和文件的權限要求相當嚴格，
咱們最終需要確保相關目錄權限與下述一致：

chmod 0755 ~               # 或 chmod g-w ~   
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
sudo service sshd restart

后記：
當然了，這篇文章所反映的問題雖然很小，最后的答案也很簡單，但是其展現的排查思路和方法卻很獨特，值得借鑒，畢竟很多時候咱們不能像平時一樣，直接 debug 源碼。

Refer：
[1] 記一次sshd異常：無法通過建立信任關系登錄 https://www.felix021.com/blog/read.php?2085
[2] ssh公鑰登錄無效 https://my.oschina.net/sukai/blog/686981
[3] Debugging SSH public key authentication problems https://blog.codefront.net/2007/02/28/debugging-ssh-public-key-authentication-problems/

http://www.importnew.com/27372.html