[Exceptions]SSH连接时出现Host key verification failed的

这篇博客介绍了如何解决SSH连接时遇到的Hostkey Verification Failed错误。作者怀疑是由于操作失误导致,通过删除~/.ssh/known_hosts文件中对应IP的RSA信息解决了问题。此外,还提供了一个可能有用的解决方案链接,但未进行翻译或验证。

参考

因为这个报错太久远,没截图,没问题描述了,参考文档又写得明白,所以先放文档。解决问题时,参考了SSH连接时出现Host key verification failed的解决

解决

因为这个很可能是我操作失误,所以简单删除了known_hosts的相关信息。更多原理和配置(关于ssh_config)可以看上面的链接。

vi ~/.ssh/known_hosts

删除对应ip的相关rsa信息

补充

https://www.howtouselinux.com/post/fix-host-key-verification-failed
这个文章可能那挺好的,但我现在没精神翻译,也没验证

### 解决方案 当遇到 `SSL peer verification failed` 错误,通常是因为客户端无法验证服务器证书的有效性。以下是可能的原因以及解决方案: #### 1. **检查代理设置** 如果系统配置了 HTTP 或 HTTPS 代理,则可能导致 SSL 验证失败。可以通过修改 `/etc/apt/apt.conf` 文件中的代理设置来解决问题[^3]。 ```bash Acquire::http::proxy "http://<proxy-server>:<port>/"; Acquire::https::proxy "http://<proxy-server>:<port>/"; ``` 确保代理地址和端口正确无误,并测试连接是否正常工作。 --- #### 2. **更新 CA 证书库** 错误可能是由于本地系统的 CA 证书过期或不完整引起的。可以尝试安装最新的根证书包以修复此问题。 对于基于 Debian 的系统: ```bash sudo apt-get update sudo apt-get install --reinstall ca-certificates ``` 对于基于 RedHat 的系统: ```bash sudo yum reinstall ca-certificates update-ca-trust force-enable ``` 这一步有助于解决因缺少有效 CA 密钥而导致的 `BAD_CERTIFICATE` 问题[^1]。 --- #### 3. **禁用 SSL 验证(仅用于调试)** 虽然建议始终启用 SSL 验证以保障安全性,但在某些情况下可临关闭验证以便排查问题。注意:这种方法不应在生产环境中使用[^2]。 针对 Python 脚本: ```python import requests from requests.packages.urllib3.exceptions import InsecureRequestWarning requests.packages.urllib3.disable_warnings(InsecureRequestWarning) response = requests.get('https://example.com', verify=False) print(response.text) ``` 或者,在命令行工具中忽略 SSL 验证警告: ```bash curl -k https://example.com ``` 再次强调,这种做法仅适用于开发环境下的快速诊断。 --- #### 4. **自定义信任存储** 如果目标服务使用的是一张未被广泛认可的自签名证书,可以选择将其导入到受信证书列表中。 Linux 平台操作方法如下: 1. 将 `.crt` 文件复制至 `/usr/local/share/ca-certificates/` 目录下; 2. 执行以下命令刷新证书缓存: ```bash sudo cp your-certificate.crt /usr/local/share/ca-certificates/ sudo update-ca-certificates ``` 完成上述步骤后重新运行程序即可。 --- #### 5. **确认间同步状态** 有主机的间不同步也会引发类似的认证异常现象。因此有必要核查当前设备上的日期与钟准确性并及校正。 执行 NTP 同步指令: ```bash sudo ntpdate pool.ntp.org ``` 随后再发起请求看是否会恢复正常行为模式。 --- ### 总结 通过调整网络代理参数、升级操作系统自带的信任链文件版本号、有条件地绕开安全机制或是扩展默认可信机构范围等方式均能有效地应对该类难题。务必优先考虑维护通信过程的安全属性而不是轻易妥协于便捷性的需求之上。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值