Permission denied (publickey,gssapi-keyex,gssapi-with-mic) 解决方法

正文:

出现Permission denied (publickey,gssapi-keyex,gssapi-with-mic)这个报错时我们也许可以庆幸下,这个报错说明我们的云平台上的防火墙和虚机的sshd服务都是好的。只不过是我们哪边的配置有些问题。
这个报错中publickey Permission denied的报错信息其实已经告诉我们问题了我们的公钥是错误的,一般情况下我们都可以理解这个问题,并快速解决问题,将公钥放到服务器的~/.ssh/authorized_keys文件中便可。后来实验了才知道这是因为PasswordAuthentication这个字段为"no"的缘故。
所以遇到这种问题便是修改

vim /etc/ssh/sshd_config
增加如下修改:
PasswordAuthentication yes

之后重启
systemctl restart sshd
注意:
如果你喜欢用root用户登入的话,要确保
vim /etc/ssh/sshd_config
PermitRootLogin yes

之后重启
systemctl restart sshd
<think>好的,我现在需要帮用户解决Hadoop集群中部分节点出现Permission denied的问题,即使SSH免密登录已经配置正常。首先,我得回忆一下用户提到的错误信息:“Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password)”,这通常和SSH连接有关,但用户说免密登录正常,所以问题可能不在基础的SSH配置上。 首先,我要确定可能的几个原因。用户提到的是部分节点有问题,所以可能这些节点的配置有差异。比如,权限问题。SSH对文件和目录的权限非常敏感,即使正确配置了密钥,如果.ssh目录或authorized_keys文件的权限不对,也会导致问题。比如,.ssh目录应该是700,authorized_keys是600。用户提供的引用[5]也提到了这一点,可能需要检查这些权限是否正确,特别是在出问题的节点上。 其次,SELinux可能没有关闭。CentOS系统默认启用SELinux,这可能会阻止SSH访问,即使配置正确。需要检查SELinux的状态,并考虑临时关闭或配置策略。引用[2]和[5]中提到过相关解决步骤,可能需要用户检查这部分。 另外,SSH配置文件的问题。比如,/etc/ssh/sshd_config中的配置是否允许公钥认证。需要确认PubkeyAuthentication是否为yes,AuthorizedKeysFile的路径是否正确。如果这些设置被修改过,或者节点之间的配置文件不一致,也会导致问题。特别是部分节点可能配置不同,所以需要逐一检查。 还有可能用户的主机名解析有问题。比如,在hosts文件中没有正确配置IP和主机名的映射,导致节点间无法正确识别对方,从而影响SSH连接。需要检查各节点的/etc/hosts文件是否一致,确保主机名和IP对应正确。 另外,Hadoop本身的配置文件是否有问题。比如,slaves文件中的主机名是否正确,或者hadoop-env.sh中的SSH参数是否被错误修改。需要确认这些配置是否正确指向了各个节点的主机名,并且没有拼写错误。 此外,防火墙设置可能也是一个原因。虽然SSH免密登录配置正确,但防火墙可能阻止了节点之间的通信。需要检查防火墙状态,是否开放了SSH端口(默认22),或者考虑暂时关闭防火墙进行测试。 用户已经排除了SSH免密登录的问题,所以可能需要更深入的检查。比如,是否使用了不同的用户进行SSH连接和Hadoop操作,权限问题可能导致访问被拒绝。例如,Hadoop服务可能以某个特定用户运行,而该用户没有正确的密钥配置。需要确保所有节点上的用户一致,并且密钥正确安装在该用户下。 还有可能需要查看详细的SSH日志,通过查看/var/log/secure日志文件,找出连接失败的具体原因。例如,是否在连接时尝试了错误的密钥,或者认证方式被拒绝。这可以帮助定位问题所在。 总结下来,可能的解决步骤包括:检查权限设置、关闭SELinux、检查SSH配置文件、验证主机名解析、检查Hadoop配置、关闭防火墙、确认用户一致性以及查看日志文件。需要逐步排查这些可能的原因,尤其是在出问题的节点上进行逐一验证。</think>### Hadoop集群SSH连接异常分析与解决方案 #### 一、现象定位与原因分析 当SSH免密登录正常但部分节点仍报错`Permission denied (publickey,gssapi-keyex,gssapi-with-mic)`时,需排查以下方向: 1. **SSH密钥权限问题** 即使密钥已生成,若`.ssh`目录或`authorized_keys`文件权限不当,SSH服务会拒绝连接。要求: - `~/.ssh`目录权限必须为`700`:`chmod 700 ~/.ssh` - `authorized_keys`文件权限必须为`600`:`chmod 600 ~/.ssh/authorized_keys`[^5] 2. **SELinux安全策略限制** CentOS系统默认启用SELinux,可能拦截SSH密钥认证。需执行: ```bash setenforce 0 # 临时关闭SELinux sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config # 永久关闭 ``` 3. **SSH服务配置差异** 检查问题节点的`/etc/ssh/sshd_config`配置是否包含: ```bash PubkeyAuthentication yes # 启用公钥认证 AuthorizedKeysFile .ssh/authorized_keys # 密钥文件路径 ``` 4. **主机名解析异常** Hadoop依赖主机名通信,需确保所有节点的`/etc/hosts`文件包含完整的集群IP与主机名映射,例如: ```bash 192.168.1.10 master 192.168.1.11 slave1 192.168.1.12 slave2 ``` #### 二、针对性解决方案 1. **权限修复操作** 在问题节点执行: ```bash chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys ``` 2. **SSH服务重启** 更新配置后重启SSH服务: ```bash systemctl restart sshd ``` 3. **Hadoop配置文件校验** - 检查`etc/hadoop/workers`文件是否包含所有工作节点主机名 - 确认`etc/hadoop/core-site.xml`中`fs.defaultFS`指向正确的主节点地址 4. **防火墙状态检查** 关闭防火墙或放行Hadoop端口: ```bash systemctl stop firewalld # 临时关闭 systemctl disable firewalld # 永久关闭 ``` #### 三、进阶验证方法 通过`ssh -vvv`命令输出调试信息,观察密钥加载过程: ```bash ssh -vvv slave1 # 替换为问题节点主机名 ``` 若日志显示`Offering public key: /home/user/.ssh/id_rsa`但未通过认证,需重新分发公钥: ```bash ssh-copy-id -i ~/.ssh/id_rsa.pub slave1 # 覆盖写入密钥 ``` #### 四、典型场景案例 某集群中`slave2`节点持续报错,最终发现其`authorized_keys`文件权限为`644`,修正为`600`后恢复正常[^4]。
评论 10
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值