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=
w=
x= 

可能出现的问题，主机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 的互信，方法很简单：

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

这三步执行下来就能顺利 ssh localhost 免密码登录了，但是昨天刚建好的互信，今天下午突然不能用了，ssh localhost 需要密码，
第一反应是可能哪里设置和配置被改动了，看了下文件版本、配置修改时间都无变化，然而登录时的提示信息又过于简单，这个时候排查陷入僵局了。

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

work@test_zz_Master 192.168.187.213 :: ~ >

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

ssh -vvv localhost
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips  Feb
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv
debug1: Connecting to localhost [127.0.0.1] port .
debug1: Connection established.
debug1: identity file /home/work/.ssh/identity type -
debug1: identity file /home/work/.ssh/identity-cert type -
...
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  bytes for a total of
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-- ~]# /usr/sbin/sshd -d -p
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  clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /home/work
debug1: restore_uid: /
debug1: temporarily_use_uid: / (e=/)
debug1: trying public key file /home/work/.ssh/authorized_keys
debug1: fd  clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /home/work
debug1: restore_uid: /
Failed publickey for work from 127.0.0.1 port  ssh2

可以看到倒数第三行：Authentication refused: bad ownership or modes for directory /home/work，
正好与那第六条相对应，再检查一下 /home/work ，其权限是否是其他组可读写。
同时，咱们也能从 /var/log/secure 看到明细的 debug 日志：

[root(hostname)@bjdhj-- ~]# tail -f /var/log/secure
Sep   :: bjdhj-- sshd[]: Server listening on 0.0.0.0 port .
Sep   :: bjdhj-- sshd[]: Authentication refused: bad ownership or modes for directory /home/work
Sep   :: bjdhj-- sshd[]: Authentication refused: bad ownership or modes for directory /home/work
Sep   :: bjdhj-- sshd[]: Connection closed by 127.0.0.1

2、最终解决方案
ssh 为了保证通信安全，防止 key 被篡改或窃取，对目录和文件的权限要求相当严格，
咱们最终需要确保相关目录权限与下述一致：

chmod  ~               # 或 chmod g-w ~
chmod  ~/.ssh
chmod  ~/.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