Gitlab配置完免密SSH Key后依然需要输入密码的解决办法

Gitlab配置完ssh key后，用ssh方式连接，还是要输入密码：

[root@localhost ~]# git clone git@192.168.7.31:devops/test.git
Cloning into 'test'...
git@192.168.7.31's password:

网上的文章找了一大堆，比如git用户被lock，设置密码什么的，依然没解决问题，用SSH调试，发现不用22端口是可以的。最后突然灵光一闪，会不会是LINUX的安全策略引起的呢，禁用掉安全策略，重启后，果然问题解决。

解决步骤

如下：
把/etc/selinux/config里的SELINUX=disabled

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled 
# SELINUXTYPE= can take one of three values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

扩展知识：

1. SSH调试命令，试试不用22端口是否可以

• GITLAB所在服务器，防火墙开启8003端口，并启动调试

firewall-cmd --zone=public --add-port=8003/tcp --permanent
firewall-cmd --reload

/usr/sbin/sshd -d -p 8003

• 客户服务器，尝试连接

 ssh -vT git@192.168.7.31 -p 8003

测试过程中发现8003可以免密没问题，换成22端口后就需要密码。

2.SELINUX其它相关

SELinux检查方式是独立于传统的使用者的权限，用户必须同时符合使用者的权限和SELinux的权限才能顺利执行操作。SELinux需要一个好的Policy才能发挥最好的效果，策略太宽松会使SELinux毫无用处，太严格又会使系统管理处处麻烦，有些时候系统服务配置不成功，以为是配置文件写错了，却不知道是SELinux限制的问题，其实配置文件并没有写错。原来root可以任意重新启动某些服务，但是启用SELinux后，由于SELinux的控制而无法顺利进行。美国国家安全局将安全策略的制定交由Linux的发行商来做，Redhat自己订制了一套基本的策略。targeted策略是RHEL已经定义好的策略，它保护的系统服务一共是25个，包括ypbind,dhcpd,httpd,mysqld,named,nscd,ntpd,pegasus,portmap,postgresql,snmpd,squid,syslogd,winbind,use_nfs_home_dirs等。

参考文章：https://blog.csdn.net/skyhh/article/details/88992408