1问题背景描述：k8s节点之间建立互信（包括与自身互信）后，发现登录不是免密。互信建立操作如下#ssh-keygen-trsa#ssh-copy-id-i.ssh/id_rsa.pubroot@为了描述方便：这里设置为A和B互信操作，A机器sshB不需要密码，而机器B上sshA需要密码2查这里百度参考大神的调试步骤，然后再次验证2.1调试日志首先需要得到详细的debuglog看卡在哪里。linux中很多命令都有调试功能，ssh自带调试功能：在机器B上连接A（调试时把localhost改成A的IP）#ssh-vvvlocalhostOpenSSH_5.3p1,OpenSSL1.0.1e-fips11Feb2013debug1:读取配置数据/etc/ssh/ssh_configdebug1：为*debug2应用选项：ssh_connect：needpriv0debug1：连接到本地主机[127.0.0.1]端口22.debug1：已建立连接。debug1：身份文件/home/work/.ssh/identitytype-1debug1:identityfile/home/work/.ssh/identity-certtype-1...debug3:remainingpreferred:keyboard-interactive,password//启用公钥登录debug3:authmethod_is_enabledpublickeydebug1:Nextauthenticationmethod:publickeydebug1:尝试私钥：/home/work/.ssh/identitydebug3:nosuchidentity:/home/work/.ssh/identitydebug1:Offeringpublickey:/home/work/.ssh/id_rsadebug3:send_pubkey_test//发送公钥包，waitforserverauthenticationresponsedebug2:wesentapublickeypacket,waitforreplydebug3:Wrote368bytesforatotalof1741debug1:Authenticationsthatcancontinue:publickey,gssapi-keyex,gssapi-with-mi调试1：可以继续的认证：publickey,gssapi-keyex,gssapi-with-mic、passworddebug1:Tryingprivatekey:/home/work/.ssh/id_dsadebug3:nosuchidentity:/home/work/.ssh/id_dsadebug1:Tryingprivatekey:/home/work/.ssh/id_ecdsadebug3:nosuchidentity:/home/work/.ssh/id_ecdsa//验证失败，禁用此验证方法debug2:我们没有发送数据包，禁用methoddebug3:authmethod_lookuppassworddebug3:remainingpreferred:,passworddebug3:authmethod_is_enabledpassword//下一个验证方法：启用密码登录debug1:nextauthenticationmethod:passwordwork@localhost'spassword:可以看到，确实认证失败了，但是光说没有发包，还是看不出失败的深层次原因，disable方法，那么我们再对比一下正常的认证流程应该是怎样的：2.2检查配置打开服务器A的/etc/ssh/sshd_config确认如下几行：配置没问题，2.3DebuggingSSHpublickey从上面的对比过程可以看出，正常互信后，“wesentapublickeypacket,waitforreply”后面应该是“debug1:Serveracceptskey:pkalgssh-rsablen277”，由此可见互信失败的原因：A的sshd不识别publickey。至于为什么没有通过，参考了大神的笔记，在google上搜索关键词“sshpublickeyignoredebugdiagnostic”，这里查看了第二篇：https://unix.stackexchange.co。..大概是指A机器上相关文件或目录的权限不正确~~/.ssh~/.ssh/authorized_keys,调试方法：如果你有root权限访问服务器，解决此类问题的简单方法是在调试模式下运行sshd，通过在服务器上发出类似/usr/sbin/sshd-d-p2222的命令（需要sshd可执行文件的完整路径，sshd可以提供帮助），然后使用ssh-p2222用户从客户端连接@主持人。这将强制SSH守护进程留在前台并显示有关每个连接的调试信息。寻找类似debug1的东西：尝试公钥文件/path/to/home/.ssh/authorized_keys...身份验证被拒绝：目录/path/to/home/的所有权或模式不正确/如果无法使用备用端口，您可以暂时停止SSH守护进程并将其替换为处于调试模式的守护进程。停止SSH守护进程不会终止现有连接，因此可以这样做通过远程终端，但有点冒险-如果在调试替换未运行时连接确实以某种方式断开，则您将被锁定在机器之外，直到您可以重新启动它。所需命令：servicesshstop/usr/sbin/sshd-d#...debugoutput...servicesshstart（取决于您的Linux发行版，第一行/最后一行可能是systemctlstopsshd.service/systemctlstartsshd.serviceinstead.)在机器A上执行/usr/sbin/sshd-d-p2222(在端口2222上启动一个带有调试输出的sshd，端口2222可以被任何端口替换)然后执行ssh-vvlocalhost-p2222on机器B，您可以在A上看到debug1：尝试公钥文件/path/to/home/.ssh/authorized_keys...Authenticationrefused:badownershipormodesfordirectory/path/to/home/也就是说，是因为你的/path/to/home/目录权限有问题导致的（其实没必要设置这个目录，比如我遇到根目录权限问题的时候，这些调试信息也可以在里面查看/var/日志/安全。3最终解决方案您的主目录~、您的~/.ssh目录和远程机器上的~/.ssh/authorized_keys文件必须只能由您写入检查您的主目录、.ssh目录和authorized_keys文件的权限：如果您的ssh服务器在“StrictModeson”的情况下运行，它将拒绝在~/.ssh/authorized_keys文件中使用您的公钥。你的home目录应该只有你自己可写，~/.ssh应该是700，authorized_keys应该是600.ssh为了保证通信安全，防止密钥被篡改或窃取，目录和文件的权限也很严格.也就是说，当你的/etc/ssh/sshd_config中的StrictModes为yes(默认为yes)时，要求~/.ssh~/.ssh/authorized_keys权限只能由所有者写入，否则sshd将拒绝使用~/.ssh/authorized_key中的公钥。具体命令这里就不贴了，只要拥有者有Write权限就可以了。Refer：参考原文出处：https://my.oschina.net/leejun...
