ubuntu22.04 ssh连接失败 userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms

最新推荐文章于 2024-08-07 00:18:47 发布

qq_42362810

最新推荐文章于 2024-08-07 00:18:47 发布

阅读量1.3k

点赞数 8

文章标签： ssh 运维

本文链接：https://blog.csdn.net/qq_42362810/article/details/133787473

版权

本文讲述了OpenSSH8.7版本后不再默认支持ssh-rsa签名的问题，提供了解决方案：修改sshd_config中的配置项，接受ssh-rsa，重启sshd服务，以及在~/.ssh/config中添加配置和生成ed25519密钥以适应新版本要求。

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

错误详情

userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
sshd[14785]: error: Received disconnect from xxxx port 45190:3: com.jcraft.jsch.JSchException: Auth fail [preauth]

OpenSSH从8.7以后版本开始默认不支持ssh-rsa签名的方式，需要手动设置

$ ssh -V
OpenSSH_8.9p1 Ubuntu-3ubuntu0.1, OpenSSL 3.0.2 15 Mar 2022

解决办法:
1.在/etc/ssh/sshd_config里面新增如下配置项
PubkeyAcceptedKeyTypes=+ssh-rsa

重启sshd

sudo systemctl restart sshd.service

2.在~/.ssh/config里面新增如下配置项

Host */or example.com

PubkeyAcceptedAlgorithms +ssh-rsa

3.重新生成密钥支持格式的密钥

ssh-keygen -t ed25519

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

qq_42362810

关注关注

8
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

ubuntu20.04升级ubuntu22.04后ssh免密连接失败

dj_wang的博客

09-03

2398

ubuntu20.04升级ubuntu22.04后ssh免密连接远程服务器失败

【ubuntu22.04~mysql-MHA-mycat】

qq_44637753的博客

06-06

1116

#三台服务器之间相互免密。

参与评论您还未登录，请先登录后发表或查看评论

远程连接ubuntu服务器报错：userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms

Sablier的博客

03-14

2153

userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth] 记录一次通过堡垒机连接机器失败问题

weixin_54851134的博客

12-20

2884

userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth] 记录一次通过堡垒机连接机器失败问题

userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms

04-07

2297

userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]@TOC升级openssh为9版本后，配置互信失败了，查看/var/log/messages里面查看报错：userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]解决办法：到升级的openssh配置目录，升级之前是默认的是

Ubuntu22.04安装，SSH无法连接

Anakki的博客

10-23

4368

3.重新打开ssh客户端并连接，如果使用修改配置前就已经打开的ssh客户端，无法使用新的ssh配置。Ubuntu初始化安装后，系统默认不允许root通过ssh连接，因此需要完成三个设置。将PermitRootLogin注释打开，并将值改为yes。，ubuntu默认不以root登录。1.修改ssh配置文件。

ubuntu22.04 ssh 连不上

huangruifeng的博客

11-01

3726

ubuntu22.04 ssh 登录

第四章 Ubuntu 22.04.1 LTS版配置局域网内部网络源

yjun89的博客

06-24

2257

如果软件仓库要为内网其他ubuntu服务器提供服务，就需要安装能提供网络服务的软件包，这样的软件有很多种，如ftp，nginx、apache等，这里使用apache2软件包来提供网络应用服务，下面进行apache2软件的安装。因为apache网站默认根路径为/var/www/html/，为了不修改apache的配置文件，这里就直接在/var/www/html/目录下创建本地仓库的存储目录。（2）、这里需要在内网其他主机上导入服务器中导出的公钥，需要把服务器导出的公钥复制到内网其他主机，然后导入公钥。

SSH常见问题及其解决方法

vincent_van12345的博客

11-02

1万+

SSH是Linux中的基础服务，作为IT从业者，基本上每天都要SSH连接到服务器中，从事各种各样的工作。作为这样基础的不能再基础的服务，一旦出现问题，影响也是巨大的，连不上就无法对服务器进行配置和更改，所有的事情也就无从谈起。在这篇文章中，我们会对SSH服务进行介绍，并对一些常见的问题进行分析，进而提供相应的解决方法。话不多说，我们进入主题。一、SSH服务简介 SSH采用的是C/S架构，...

【WSL2笔记2】搭建深度学习开发环境踩坑笔记 Ubuntu+CUDA+cuDNN+PyTorch+Tensorflow+ONNX

老富的博客

04-06

3749

错误的结果就是配置的所有虚拟环境都以base的python版本运行，无法配置每个虚拟环境使用不同python版本，失去了虚拟环境意义。至此，适用PyTorch、Tensorflow、cuDNN框架的深度学习开发环境搭建完成。WSL 上的 CUDA 用户指南。安装protobuf 3.2版本。Anaconda官网版本档案。下载Anaconda安装包。创建Python虚拟环境。设置Anaconda路径。需要注册账号登录下载。通过SSH传送WSL。

strongswan Ubuntu 服务端修改 IKEv2 协议握手端口号

天苍野茫

08-07

1695

在 Ubuntu 22.04 搭建 strongSwan 服务端，并且修改 IKEv2 协议的握手端口 4500

SSH 密钥登录：not in PubkeyAcceptedKeyTypes

卡农的魔笛

11-20

1万+

由于每次登录服务器都要输入密码比较麻烦，今天信手拈来： fanshengshuai >>> ssh-keygen -t dsa 18-11-20 9:48 Generating public/private dsa key pair. Enter file in which to save the key (/home/...

【虚拟机ubuntu设置ssh】ssh连不上问题解决方法

weixin_42981687的博客

06-22

7205

【虚拟机ubuntu设置ssh】ssh连不上问题解决方法转载自博客园:https:www.cnblogs.com/chenxiaomeng/，仅供自用学习记录。首先，确保server端的ssh服务是开的（service shhd start）然后在client端输入： ssh 【usrname】@【serverip】（远程登录） scp 【filename】【usrname】@【serverip】：/URL (远程传输) 常出现的问题： 1.端口失效 ssh 192.168.*. ssh: con

guacamole ssh ubuntu 22.04 连不上

05-17

308

guacamole ssh ubuntu 22.04 连不上。/etc/sshd/sshd_config 最后面加两行。/etc/sshd/ssh_config 注释去掉。

ubuntu22.04 服务器 SSH 密钥登录失败

ljz0929的博客

03-24

8105

SSH密钥登录，是将SSH公钥写入服务端的文件中。今天装了ubuntu22.04的系统，按照以往操作，在服务端配置了SSH公钥之后，发现竟然无法登录。

Ubuntu 20.04 root ssh登录配置

最新发布

03-20

<think>嗯，用户运行了一个ssh命令，连接时被重置了，需要分析原因。首先，用户的命令是ssh -vvv climb@183.60.226.115 -p 15567，这里用了三个-v参数，说明开启了最详细的调试信息。输出显示到了连接建立之后，但在密钥交换阶段被对方重置了。接下来看输出内容。OpenSSH版本是8.2p1，系统是Ubuntu，可能对应的OpenSSL版本是1.1.1f。在连接过程中，客户端尝试了各种身份验证文件，比如id_rsa、id_dsa等，但都没有找到，所以使用的是默认的或者没有密钥的情况。然后本地版本字符串发送后，对方回复了一个连接重置，导致kex_exchange_identification失败。可能的原因有几个方面。首先是端口问题，用户指定了非默认的15567端口，可能服务器没在这个端口上监听，或者防火墙阻止了。然后是SSH服务配置问题，比如服务器端的SSH配置可能限制了IP、用户，或者使用了不兼容的协议版本。还有可能客户端的SSH版本与服务器不兼容，比如服务器只支持旧版的SSH协议，而客户端用了新版本。另外，也有可能是服务器应用层直接拒绝了连接，比如端口被占用，或者服务未运行。需要用户检查的步骤包括确认端口是否正确，使用telnet或nc测试端口连通性；检查服务器端SSH服务是否在指定端口运行，配置是否正确；查看服务器日志，如/var/log/auth.log，获取更多拒绝信息；尝试降低SSH协议版本，比如使用-o选项指定协议2或1；以及检查防火墙设置，是否有入站规则限制。如果这些都没问题，可能需要联系服务器管理员确认配置。另外，用户可能不太熟悉网络调试工具，可能需要指导他们如何用telnet或nc，或者如何查看服务器日志。还有可能用户没有权限访问服务器日志，这时候只能建议他们联系管理员。也有可能用户输入了错误的端口号，或者服务器临时不可用，需要再次确认。</think>以下是对该SSH连接过程的逐层分析及问题排查建议： --- ### 一、命令解析执行的命令是： ```bash ssh -vvv climb@183.60.226.115 -p 15567 ``` - **参数说明**： - `-vvv`：启用最高级别的调试模式（输出详细连接日志） - `climb@183.60.226.115`：尝试以用户`climb`登录IP为`183.60.226.115`的主机 - `-p 15567`：指定非默认SSH端口`15567` --- ### 二、关键日志分析 #### 1. 客户端初始化阶段 ```log OpenSSH_8.2p1 Ubuntu-4ubuntu0.5, OpenSSL 1.1.1f 31 Mar 2020 debug1: Reading configuration data /etc/ssh/ssh_config ``` - **客户端版本**：OpenSSH 8.2（较新版本） - **加密库**：OpenSSL 1.1.1f（支持TLS 1.3） #### 2. 密钥认证尝试 ```log debug1: identity file /home/jingle/.ssh/id_rsa type -1 ... debug1: identity file /home/jingle/.ssh/id_xmss type -1 ``` - **问题**：客户端尝试加载所有默认私钥文件（如`id_rsa`, `id_ed25519`等），但均未找到（`type -1`表示文件不存在） - **影响**：若服务端要求密钥认证，连接会失败（但当前错误与此无关） #### 3. 连接建立与中断 ```log debug1: Connection established. kex_exchange_identification: read: Connection reset by peer ``` - **关键错误**：TCP连接已建立，但密钥交换阶段被服务端强制关闭 - **错误码解读**：`Connection reset by peer`表示服务端主动拒绝或终止了连接 --- ### 三、可能原因及排查步骤 #### 1. 端口或防火墙问题 - **检查端口状态**： ```bash telnet 183.60.226.115 15567 # 或使用 nc -zv 183.60.226.115 15567 ``` - 若无法连通：说明端口未开放或被防火墙拦截 - 若显示`SSH-2.0-xxx`：端口正常但协议不兼容 #### 2. 服务端配置问题 - **常见配置限制**： - `sshd_config`中`AllowUsers`未包含`climb` - `Port 15567`未在服务端配置 - 协议版本不匹配（如服务端仅支持SSHv1） - **强制使用SSHv2**： ```bash ssh -o Protocol=2 climb@183.60.226.115 -p 15567 ``` #### 3. 服务端日志检查 - **登录服务端**（需权限）查看日志： ```bash tail -f /var/log/auth.log # Ubuntu/Debian系统 ``` #### 4. 服务端进程状态 - **确认SSH服务运行**： ```bash sudo netstat -tulpn | grep 15567 ``` --- ### 四、典型解决方案 1. **验证端口开放**： - 联系服务器管理员确认端口`15567`已开放 - 检查本地防火墙规则（如`ufw`或`iptables`） 2. **协议兼容性测试**： ```bash ssh -1 climb@183.60.226.115 -p 15567 # 强制使用SSHv1（不建议） ``` 3. **简化连接命令**： ```bash ssh -o PreferredAuthentications=password climb@183.60.226.115 -p 15567 ``` --- ### 五、流程图总结 $$ \begin{CD} \text{客户端发起连接} @>>> \text{TCP三次握手} @>>> \text{SSH协议协商} \\ @. @. @VVV \\ @. @. \text{服务端拒绝（RESET）} \\ \end{CD} $$ 建议按上述步骤逐步排查，优先验证端口可达性和服务端配置。