CentOS SSH无密码登录原理，配置以及常见问题


原理简介

为了便于理解，假设需要在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 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

常见问题

问题现象：

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.Bkjia.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，认证成功，问题解决。

 


相关内容