部署k8s时ssh端口不是22导致创建ssh session failed问题

本文讲述了在部署Kubernetes时遇到SSH连接失败的问题,由于服务器端口被设置为222。文章详细分析了问题,提出通过SSH端口代理解决,包括检查SSH服务、确认端口设置,最终选择使用端口转发技术,如`ssh -p222 -L22:172.22.17.52:222`。并介绍了参数解释和解决方案实施过程。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

项目场景:部署k8s时ssh端口不是22导致创建ssh session failed问题 (SHH端口代理)

项目场景:部署k8s,日志显示错误不能创建ssh连接错误,由于主机服务器配置的ssh端口为222,通过变更端口为22不线上,因为主机做了很多安全策略,修改麻烦变动大。想着通过代理的方式来实现。


问题描述

错误内容如下:mount roots failed exec init.sh failed to create ssh session for 172.22.17.52: dial tcp 172.22.17.52:22: connnect refused
请添加图片描述

原因分析:

提示:信息表明ssh:22session创建失败,首先怀疑ssh:22是否开启,然后查看配置是不是用的22端口

第一步:查看ssh是否开启

ps -e | grep ssh
  438 ?        00:00:18 sshd
 1710 ?        00:00:02 sshd
 3604 ?        00:00:00 sshd
 5692 ?        00:00:00 sshd
24223 ?        00:00:00 sshd
29686 ?        00:00:00 sshd 

第二步:查看ssh启动端口

netstat -tunlp |grep ssh
tcp        0      0 0.0.0.0:222              0.0.0.0:*               LISTEN      1710/sshd           
tcp6       0      0 :::222                   :::*                    LISTEN      1710/sshd 

第三步:发现问题

提示错误日志提示ssh:22创建session错误,实际使用的是222端口,初步怀疑是和k8s用到的一些开源组件默认的保留了使用ssh:22端口,如果服务器ssh端口变更导致连接失败

tcp        0      0 0.0.0.0:222              0.0.0.0:*               LISTEN      1710/sshd           
tcp6       0      0 :::222                   :::*                    LISTEN      1710/sshd 

解决方案:

方案1、修改222端口为22
需要修改服务器安全策略以及一些列防御措施,成本大,不可控因素多,放弃

方案2、端口代理
端口代理成本小,对其他服务没有影响,选用

解决方式:

ssh -p 222 -NfR -L 22:172.22.17.52:222 172.22.17.52 

开始使用上面这种方式,发现端口转发必须的使用127.0.0.1作为ip才能访问转发端口,后面摸索找到了下面方法

ssh -p 222 -C -f -N -g -L 22:172.22.17.52:222 root@172.22.17.52

创建后访问22和访问222都可以生效

参数说明:
-N:指定这个SSH连接只进行端口消息转发,不执行任何SSH远程命令;
-L:指定本地监听的地址和端口;
-f: 这个SSH会话放入后台运行,不加这个参数的话,当退出当前SSH -L指定的终端时,端口转发进程就结束了,端口转发送也就结束了。所以务必要加上-f参数。
-g :在-L/-R/-D参数中,允许远程主机连接到建立的转发的端口,如果不加这个参数,只允许本地主机建立连接

<think>好的,我现在需要解决用户在使用sealos部署Kubernetes集群遇到的SSH认证失败问题。错误信息显示无法通过认证,尝试的方法包括none和password。首先,我应该根据用户提供的引用内容和常见的SSH配置问题来分析可能的原因。 用户提到的引用[1]中提到了生成.ssh目录以及配置SSH互信的步骤。可能用户没有正确生成密钥对,或者没有将公钥复制到目标主机。另外,引用[2]涉及到NAT环境下的连接问题,可能网络配置导致SSH无法正确连接。 首先,我需要检查SSH互信的配置是否正确。用户是否在部署机上生成了SSH密钥?如果tidb用户下没有.ssh目录,可能需要手动生成,这可以通过运行ssh-keygen命令来完成。然后,确保公钥被添加到目标主机的authorized_keys文件中。用户可能没有正确执行这些步骤,导致认证失败。 另外,SSH配置文件中可能设置了禁用密码登录,而用户可能尝试使用密码登录,但目标主机未启用密码认证。需要检查目标主机的/etc/ssh/sshd_config文件,确认PasswordAuthentication是否设置为yes,并且是否重启了SSH服务。 还有可能是防火墙或SELinux的问题,阻止了SSH连接。需要检查目标主机的防火墙规则,确保22端口开放。SELinux可能也需要临禁用或配置适当策略。 网络问题方面,如果目标主机位于NAT后面,可能需要检查端口转发或使用Hairpinning配置,如引用[2]所述。确保部署机能够正确路由到目标主机的SSH端口。 此外,sealos命令中的参数是否正确?用户可能没有正确指定目标IP或用户名,导致连接失败。需要确认命令格式是否正确,例如:sealos run ... --masters 172.22.2.122 -p tidb_password。 最后,权限问题也不能忽视。目标主机上的.ssh目录和authorized_keys文件的权限必须正确,通常目录是700,文件是600,否则SSH会拒绝使用。 总结可能的原因: 1. 未生成SSH密钥对,缺少.ssh目录或authorized_keys。 2. SSH服务未启用密码认证。 3. 防火墙或SELinux阻止连接。 4. 网络配置问题,如NAT导致路由不通。 5. sealos命令参数错误,如IP或密码不正确。 6. 文件权限问题导致SSH拒绝认证。 接下来,我需要按照这些可能性逐步排查,给出解决方案。确保用户能够按步骤检查和修正配置,解决认证失败的问题。</think>[系统级指令回答] ### 解决Sealos部署Kubernetes集群SSH认证失败的步骤 #### 1. 检查SSH互信配置 - **生成SSH密钥对**:在部署机上执行 `ssh-keygen -t rsa` 生成密钥(注意不要设置密码),这会自动创建 `$HOME/.ssh` 目录[^1] - **公钥分发**:使用 `ssh-copy-id tidb@目标主机IP` 将公钥复制到目标主机,或手动追加公钥到目标主机的 `~/.ssh/authorized_keys` 文件 #### 2. 验证SSH服务配置 - 在目标主机检查 `/etc/ssh/sshd_config`: ```bash PasswordAuthentication yes # 确保启用密码认证 PubkeyAuthentication yes # 确保启用密钥认证 ``` - 执行 `systemctl restart sshd` 重启服务 #### 3. 网络连通性检查 - 使用 `telnet 目标主机IP 22` 测试端口可达性 - 检查防火墙设置: ```bash firewall-cmd --permanent --add-service=ssh firewall-cmd --reload ``` #### 4. Sealos命令参数验证 确保命令格式正确: ```bash sealos run labring/kubernetes:v1.25.0 \ --masters 172.22.2.122 \ --passwd tidb_password ``` 需注意: - 目标IP必须可达且未被NAT错误映射[^2] - 密码包含特殊字符建议用单引号包裹 #### 5. 权限配置检查 在目标主机上确认: ```bash chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys ``` #### 6. 调试模式获取详细信息 通过添加 `-d` 参数启动调试: ```bash sealos run -d ...其他参数... ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值