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上发现能够了。成功了！成功解决问题。