publickey,gssapi-with-mic,Unspecified GSS failure

        最近的MHA配置时碰到了Permission denied (publickey,gssapi-with-mic,password)这个错误提示,同时在使用ssh -v时,出现了Unspecified GSS failure错误。这个主要是使用了GSSAPI 的认证功能导致的。客官,如果你碰到了在使用scp很慢的情况下,也是这个原因。不妨继续往下看。

 

1、故障现象
# masterha_check_ssh --conf=/etc/app1.cnf
Wed Apr  8 14:33:26 2015 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
           ...............
Permission denied (publickey,gssapi-with-mic,password).
Wed Apr  8 14:33:26 2015 - [error][/usr/lib/perl5/site_perl/5.8.8/MHA/SSHCheck.pm, ln86] SSH connection from
   root@vdbsrv1(192.168.1.6:22) to root@vdbsrv2(192.168.1.7:22) failed!

### ssh到另一主机时,花费20s左右
# time ssh 192.168.1.7 date
Wed Apr 15 21:33:53 CST 2015

real   0m20.245s
user   0m0.013s
sys 0m0.007s

### 使用-v参数ssh连接
# ssh -v 192.168.1.7
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.7 [192.168.1.7] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.1.7' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Last login: Wed Apr 15 16:56:12 2015 from 192.168.1.124

 

2、故障解决
###查看目标端的GSSAPI options
[root@vdbsrv2 ~]# grep GSSAPI /etc/ssh/sshd_config
# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes      ###此时为开启GSSAPI认证
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes

### Author : Leshami
### Blog   : http://blog.csdn.net/leshami

[root@vdbsrv2 ~]# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bk
[root@vdbsrv2 ~]# vi /etc/ssh/sshd_config           ###关闭该认证方式
[root@vdbsrv2 ~]# grep GSSAPI /etc/ssh/sshd_config  ###查看关闭后的结果
# GSSAPI options
GSSAPIAuthentication no
#GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes

###重启sshd服务
[root@vdbsrv2 ~]# service sshd restart
Stopping sshd: [  OK  ]
Starting sshd: [  OK  ]

###再次测试,仅仅0.191s,ssh -v时也无异常报错
[root@vdbsrv1 ~]# time ssh 192.168.1.7 date
Wed Apr 15 21:48:10 CST 2015

real   0m0.191s
user   0m0.014s
sys 0m0.003s

ssh连接过慢的另外一种情形(补充@20160629):

基于sshd_config修改以下配置项,

UseDNS=no

UseDNS  Specifies whether sshd(8) should look up the remote host name and check that the resolved host name for the remote IP
             address maps back to the very same IP address.  The default is “yes”.

该选项指定当客户端试图登录OpenSSH服务器时,服务器是否需要根据客户端的IP地址进行DNS PTR反向查询,查询出客户端的host name,然后根据查询出的客户端host name进行NS 正向A记录查询,验证与其原始IP地址是否一致,这是防止客户端欺骗的一种手段。如果该值为Yes,则修改服务器端hosts文件,添加对应记录也可以达到加快的目的。

时间: 2024-10-27 01:37:22

publickey,gssapi-with-mic,Unspecified GSS failure的相关文章

caffe 训练时,出现错误:Check failed: error == cudaSuccess (4 vs. 0) unspecified launch failure

I0415 15:03:37.603461 27311 solver.cpp:42] Solver scaffolding done.I0415 15:03:37.603549 27311 solver.cpp:247] Solving AlexNetI0415 15:03:37.603559 27311 solver.cpp:248] Learning Rate Policy: stepI0415 15:03:37.749981 27311 solver.cpp:214] Iteration

Linux SSH登录慢案例分析

手头有台Linux服务器ssh登录时超级慢,需要几十秒.其它服务器均没有这个问题.平时登录操作都默默忍了.今天终于忍不住想搞清楚到底什么原因.搜索了一下发现了很多关于ssh登录慢的资料,于是自己也学着来分析.印证一下ssh登录慢的原因. 出现ssh登录慢一般有两个原因:DNS反向解析的问题和ssh的gssapi认证   1:ssh的gssapi认证问题 GSSAPI ( Generic Security Services Application Programming Interface) 是一

linux中ssh登录很慢问题解决办法

使用ssh客户端(如:putty)连接Linux服务器,可能会等待10-30秒才有提示输入密码.严重影响工作效率.登录很慢,登录上去后速度正常,这种情况主要有两种可能的原因: 1. DNS反向解析问题 OpenSSH在用户登录的时候会验证IP,它根据用户的IP使用反向DNS找到主机名,再使用DNS找到IP地址,最后匹配一下登录的IP是否合法.如果客户机的IP没有域名,或者DNS服务器很慢或不通,那么登录就会很花时间. 解决办法: 在目标服务器上修改sshd服务器端配置,并重启sshd vi /e

诊断并解决 SSH 连接慢的方法诊断并解决 SSH 连接慢的方法

每次PuTTY使用SSH登录到远程的Linux进行管理的时候,远程登录的过程都非常慢--输入完用户名之后,非要等到30秒左右才会出来输入密码的提示.在实际处理问题的时候,特别需要快速响应的时候,这种状况着实让人难以忍受. 但后来具体测试了一下,发现这又并非是每种系统的通病,出现问题的机器主要集中的CentOS上,同样的Debian系统,在远程连接的过程就是健步如飞,丝毫没有卡顿犹豫的感觉.这难道是CentOS的问题? 出于好奇,查看了下两个系统在SSH时的差别 CentOS: ssh -v ss

Hadoop配置LDAP集成Kerberos

本文主要记录 cdh hadoop 集群集成 ldap 的过程,这里 ldap 安装的是 OpenLDAP .LDAP 用来做账号管理,Kerberos作为认证.授权一般来说是由应用来决定的,通过在 LDAP 数据库中配置一些属性可以让应用程序来进行授权判断. 关于 Kerberos 的安装和 HDFS 配置 kerberos 认证,请参考 HDFS配置kerberos认证. 1. 环境说明 系统环境: 操作系统:CentOs 6.6 Hadoop版本:CDH5.4 JDK版本:1.7.0_71

ssh下常用操作汇总(good)

1. 安装git,从程序目录打开 "Git Bash"  2. 键入命令:ssh-keygen -t rsa -C "email@email.com"   "email@email.com"是github账号 3. 提醒你输入key的名称,输入如id_rsa //如果只输入文件名,则文件会生成在当前目录下. 2,3两步可以合成一个命令 ssh-keygen -t rsa -C "email@email.com" -f gith

ssh连接linux服务器速度慢解决办法

ssh 登录远程服务器,速度非常慢,通过网上查询,发现有一个参数 -v 可以输出显示连接的具体消息.于是连接加上这个参数连接 [feng@fsc ~]$ ssh -v foo.path8.net OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting t

ssh建立连接速度缓慢怎么解决

ssh/scp是很常用的命令,发现对有些主机, ssh建立连接速度特别慢,连接建立之后执行操作速度却很正常. 用 ssh -v 来查看详细的连接建立过程: debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor cod

【Linux学习 】Linux使用Script命令来记录并回放终端会话

[TOC] 一.背景 在之前的博客 [Git学习-->如何通过Shell脚本实现 监控Gitlab备份整个过程并且通过邮件通知得到备份结果?] 里面,我已经详细记录了每天的自动备份与清理过期备份文件的工作. 1.每天凌晨2点在Gitlab服务器上执行Gitlab备份功能. 2.每天凌晨3点在Gitlab服务器上执行scp命令将最新的Gitlab备份文件复制到远程的文件备份服务器. 3.每天凌晨4点在远程的文件备份服务器上检测备份文件的时间,自动删除超过7天的备份文件. 这个脚本从8月18日开始运