搜索到
88
篇与
的结果
-
API网关之apisix介绍 Apache APISIX 是 Apache 软件基金会下的顶级项目，由 API7.ai 开发并捐赠。它是一个具有 动态、实时、高性能 等特点的云原生 API 网关。你可以使用 APISIX 网关作为所有业务的流量入口，它提供了动态路由、动态上游、动态证书、A/B 测试、灰度发布（金丝雀发布）、蓝绿部署、限速、防攻击、收集指标、监控报警、可观测、服务治理等功能。项目地址： apisix.apache.org 中文帮助文档： 点击查看 容器化安装：APISIX 可以借助 quickstart 脚本快速安装并启动：curl -sL https://run.api7.ai/apisix/quickstart | sh说明：为了提供更好的体验，管理 API 默认无需授权，请在生产环境中打开授权开关。nginx作为网关使用的一些痛点：业务要加个新域名？改 nginx.conf。后端服务扩容了，IP 变了？改 upstream。要做个黑白名单防刷？改配置，加 Lua 脚本。改完之后呢？nginx -t 测试一下，然后 nginx -s reload。但是当upstream 有几千个的时候，或者一天要变更几百次配置的时候，这个 reload 就是个定时炸弹。比如Nginx 在高并发下 reload，新的 worker 进程起来了，旧的 worker 还在处理长连接，这时候系统负载会瞬间飙升，甚至导致这一瞬间的请求处理延迟极高，客户端直接超时。而且，它是静态的。哪怕你只是想改一个限流的参数，从每秒 100 改成 200，你都得重载进程。而APISIX是一个不需要reload，就能随意 控制流量、随意插拔插件 的超级 Nginx。它底子还是 Nginx（确切地说是 OpenResty），所以性能上你完全不用担心，Nginx 能扛多少，它基本就能扛多少。甚至在某些场景下，因为它的路由算法优化得好，性能比原生的 Nginx 配置还要猛。APISIX 放弃了传统的数据库，转而拥抱了 etcd。快：etcd 是基于 Raft 协议的，数据一致性强，而且对这种 KV 类型的配置读取速度极快。推送机制：这是重点！Nginx 读取配置是启动时读文件的，而 APISIX 是通过 etcd 的 watch 机制。一旦你在 etcd 里改了配置（或者通过 APISIX 的 Admin API 改了配置），etcd 会瞬间把变更推送到所有的 APISIX 节点。整个过程中，长连接不会断，业务没有任何感知，配置就生效了。路由（Route）——比 Nginx 灵活太多了在 Nginx 里，我们写 location，正则匹配有时候写得头皮发麻。APISIX 的路由匹配算法用的是 Radix Tree（基数树）。这玩意儿不仅快，而且支持各种花式匹配。你可以根据 HTTP Header、Query 参数、甚至 Cookie 来进行路由分发。举个真实例子，咱们做灰度发布（金丝雀发布）。以前在 Nginx 里，你可能得写一大堆 if 或者用 split_clients 模块，配置看着就晕。在 APISIX 里，你只需要调一下 API，发个 JSON 过去：“嘿，把 Header 里带着 version: v2 的请求，或者 ID 尾号是 1 的用户，转到这个新服务去。”这就完事了。想停？再发个 API，立马切回来。插件（Plugin）——这才是核心生产力APISIX 之所以叫“全生命周期管理”，靠的就是插件。它自带了几十上百个插件，咱们日常运维需要的，基本都有。限流限速：limit-req，limit-count。不怕被刷爆了。身份认证：Key-auth，JWT，Basic-auth。以前这些逻辑可能要写在业务代码里，现在全扔给网关，业务服务只管处理逻辑，多爽。可观测性：这个我太喜欢了。一键开启 Prometheus 插件，Metrics 直接暴露出来，Grafana 面板都不用自己画，官方给你现成的。还有 SkyWalking、Zipkin 这种链路追踪，配置一下 IP 端口就能连上。安全：IP 黑白名单、CORS、URI 阻断，甚至还有 WAF（Web应用防火墙）功能的插件。而且，它的插件架构设计得很“散装”。什么意思呢？就是你可以给每一个路由单独配插件。比如 A 接口重要，我给它配个鉴权 + 链路追踪；B 接口是公共查询，我给它配个限流 + 缓存。互不干扰。多语言支持虽然 OpenResty 是 Lua 也就是 LuaJIT 的天下，但说实话，Lua 这语言，写点小脚本还行，逻辑复杂了维护起来真得掉头发。APISIX 这点做得特别鸡贼（褒义）。它支持 Plugin Runner。你是写 Java 的？写 Go 的？写 Python 的？没事，你可以用你熟悉的语言写插件，然后通过 RPC 的方式跟 APISIX 通信。最近它还支持了 Wasm (WebAssembly)。这就更猛了，把插件编译成 Wasm 跑在网关里，既安全又快，还不用受语言限制。为什么说它适合云原生？现在大家都在搞 K8s，搞微服务。传统的 Nginx 在 K8s 里用也就是做个 Ingress Controller。APISIX 也有 APISIX Ingress Controller。但它比官方那个 Nginx Ingress Controller 强在哪？官方那个 Nginx Ingress，每次你改个 Ingress 资源，它其实是在后台偷偷改 nginx.conf 然后 reload。如果你集群大，Ingress 经常变，那 Nginx 就不停地 reload，性能抖动很明显。APISIX 的 Ingress Controller 是全动态的。你改了 K8s 的资源，它直接转化成 APISIX 的配置通过 etcd 下发，全程无 reload。这就是为什么大厂上了 K8s 之后，很多都把网关换成了 APISIX。 -
sudo提权的门道 sudo全称是"substitute user do"或者"super user do"，简单说就是让普通用户能够以其他用户（通常是root）的身份执行命令。这个设计理念其实挺巧妙的，既保证了系统安全，又给了用户必要的权限。sudo的出现让我们可以用普通用户登录，需要管理员权限的时候再临时提升，这样既安全又灵活。安全加固建议最小权限原则：只给用户必需的权限，不要图省事给ALL权限定期审查：定期检查sudoers配置，清理不需要的权限日志监控：开启详细日志并定期分析禁用危险命令：避免给用户编辑器、解释器等可以执行任意命令的工具的sudo权限使用别名：通过别名简化配置，提高可读性环境变量控制：严格控制sudo执行时的环境变量会话超时：设置合理的credential cache超时时间sudoers文件的配置门道sudo的核心配置文件是/etc/sudoers，这个文件的语法说复杂不复杂，说简单也不简单。最重要的一点是，千万不要直接用vim或者nano去编辑这个文件！为什么呢？因为如果你语法写错了，sudo就废了，到时候你想改都改不了。正确的做法是用visudo命令，它会在保存前检查语法，发现错误会提示你。sudo visudosudoers文件的基本语法是这样的：{callout color="#f0ad4e"}用户 主机=(运行身份) 命令{/callout}比如最常见的配置：{callout color="#f0ad4e"}john ALL=(ALL:ALL) ALL{/callout}这行配置的意思是：用户john在所有主机上都可以以任何用户和组的身份执行任何命令。不过实际工作中，我们很少会给用户这么大的权限。更多时候是根据需要进行精细化配置。实际场景中的配置技巧 场景一：让用户只能重启特定服务 比如我们有个web开发人员，经常需要重启nginx，但又不想给他太多权限：webdev ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx, /usr/bin/systemctl status nginx这里用了NOPASSWD，意思是执行这些命令时不需要输入密码。但要注意，命令路径必须写完整路径，不然会有安全风险。 场景二：数据库管理员权限 数据库管理员需要管理MySQL服务，但不需要其他系统管理权限：dbadmin ALL=(root) /usr/bin/systemctl * mysql, /usr/bin/mysql, /usr/bin/mysqldump这里的*是通配符，表示可以对mysql服务执行任何systemctl操作。 场景三：用户组权限管理 有时候我们需要给一整个组配置权限，比如运维组：%ops ALL=(ALL) ALL前面的%表示这是一个组，不是用户。常见问题分享 问题一：路径问题 假如配置了这样的权限：user1 ALL=(root) NOPASSWD: systemctl restart httpd结果用户执行的时候总是提示没权限。后来才发现，systemctl的完整路径是/usr/bin/systemctl，而用户的PATH环境变量里可能没有包含这个路径，或者sudo执行时使用的是受限的PATH。正确的做法是写完整路径：user1 ALL=(root) NOPASSWD: /usr/bin/systemctl restart httpd 问题二：通配符的安全隐患 user2 ALL=(root) NOPASSWD: /bin/* 看起来没问题，但实际上这给了用户执行/bin/目录下所有命令的权限，包括/bin/bash。用户可以通过sudo /bin/bash直接获得root shell，这就等于给了完整的root权限。 问题三：编辑器陷阱 给用户配置了vim的sudo权限，想让他能编辑某些配置文件：user3 ALL=(root) NOPASSWD: /usr/bin/vim /etc/nginx/nginx.conf但是vim这种编辑器可以执行shell命令，用户在vim中输入:!bash就能获得root shell。类似的还有less、more等命令。高级配置技巧 别名定义 # 定义命令别名 Cmnd_Alias WEBSERVICES = /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx, /usr/bin/systemctl restart apache2 # 定义用户别名 User_Alias WEBADMINS = john, jane, bob # 使用别名 WEBADMINS ALL=(root) NOPASSWD: WEBSERVICES 时间限制 有时候希望用户的sudo权限有时间限制，可以这样配置：Defaults timestamp_timeout=5这表示用户输入一次密码后，5分钟内再次使用sudo不需要重新输入密码。 日志记录 为了安全审计，建议开启详细的sudo日志：Defaults logfile=/var/log/sudo.log Defaults log_input, log_output这样所有的sudo操作都会被记录下来，包括输入和输出。安全注意事项首先，永远不要给用户这样的权限：user ALL=(ALL) NOPASSWD: ALL这等于直接给了root权限，sudo就失去了意义。其次，要特别小心那些可以执行其他程序的命令，比如：编辑器（vim, nano, emacs）分页器（less, more）解释器（python, perl, ruby）文件传输工具（scp, rsync）这些程序往往都有执行shell命令的功能，给了sudo权限就等于给了root权限。还有一个容易忽略的点是环境变量。默认情况下，sudo会重置大部分环境变量，但有些变量会保留。如果需要更严格的控制，可以这样配置：Defaults env_reset Defaults env_keep="LANG LC_* HOME"故障排查技巧使用sudo时难免会遇到各种问题，我总结了一些常见的排查方法。 权限被拒绝 当用户执行sudo命令被拒绝时，首先检查：用户是否在sudoers文件中有相应配置命令路径是否正确语法是否有误可以用这个命令查看用户的sudo权限：sudo -l -U username 密码问题 如果用户输入密码后仍然被拒绝，可能是：输入的是用户密码而不是root密码（这是常见误区，sudo要求输入的是当前用户的密码）用户密码已过期配置中没有NOPASSWD但用户以为不需要密码 环境变量问题 有时候命令在普通用户下能执行，但sudo后就不行了，通常是环境变量的问题。可以这样调试：sudo env小技巧sudo -i vs sudo su 很多人搞不清楚这两个命令的区别。sudo -i会启动一个login shell，加载完整的环境变量；而sudo su是先执行sudo，再执行su命令。从安全角度来说，sudo -i更好一些，因为它的行为更可预测。sudo -s 如果只是想临时获得root shell而不想加载完整环境，可以用sudo -s。sudo -u 这个参数可以指定以哪个用户身份执行命令，不一定是root：sudo -u nginx cat /var/log/nginx/access.logsudo -g 类似地，-g参数可以指定用户组：sudo -g www-data ls /var/www/案例假设公司有这样的需求：开发人员需要重启web服务数据库管理员需要管理数据库服务监控人员需要查看系统状态所有人都需要查看日志文件配置可能是这样的：# 定义别名 Cmnd_Alias WEBSERVICES = /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx, /usr/bin/systemctl status nginx Cmnd_Alias DBSERVICES = /usr/bin/systemctl * mysql, /usr/bin/systemctl * postgresql Cmnd_Alias MONITORING = /usr/bin/top, /usr/bin/htop, /usr/bin/iotop, /usr/bin/netstat Cmnd_Alias LOGVIEW = /usr/bin/tail /var/log/nginx/*, /usr/bin/tail /var/log/mysql/*, /usr/bin/less /var/log/syslog User_Alias DEVELOPERS = dev1, dev2, dev3 User_Alias DBADMINS = dba1, dba2 User_Alias MONITORS = monitor1, monitor2 # 权限分配 DEVELOPERS ALL=(root) NOPASSWD: WEBSERVICES DBADMINS ALL=(root) NOPASSWD: DBSERVICES MONITORS ALL=(root) NOPASSWD: MONITORING ALL ALL=(root) NOPASSWD: LOGVIEW # 安全设置 Defaults logfile=/var/log/sudo.log Defaults timestamp_timeout=10 Defaults requiretty
-
基于OpenResty的版本灰度发布方案 OpenResty是Nginx加上Lua脚本引擎，可以实现很多复杂的逻辑。OpenResty学习曲线可能有点陡，但学会了之后真的很香。可以用Lua实现各种复杂的灰度策略，甚至可以对接公司的配置中心、监控系统等。案例：结合Lua实现动态灰度单纯使用nginx，会遇到一个问题，就是每次调整灰度比例都要修改配置文件，然后reload Nginx。这在生产环境其实挺麻烦的，万一配置写错了，reload失败，那就尴尬了。推荐方案是结合OpenResty（Nginx + Lua），把灰度规则存在Redis里，这样就可以动态调整了。upstream backend_v1 { server 192.168.1.10:8080; } upstream backend_v2 { server 192.168.1.11:8080; } server { listen 80; server_name api.example.com; location / { set $backend "backend_v1"; access_by_lua_block { local redis = require "resty.redis" local red = redis:new() red:set_timeout(1000) local ok, err = red:connect("127.0.0.1", 6379) if not ok then ngx.log(ngx.ERR, "failed to connect redis: ", err) return end -- 从Redis获取灰度比例 local canary_percent, err = red:get("canary:percent") if not canary_percent or canary_percent == ngx.null then canary_percent = 0 end -- 生成随机数判断是否走新版本 math.randomseed(ngx.now()) local rand = math.random(100) if rand <= tonumber(canary_percent) then ngx.var.backend = "backend_v2" end red:close() } proxy_pass http://$backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } 这样的话，我们只需要在Redis里修改canary:percent的值，就可以实时调整灰度比例了，不需要reload Nginx。 设置灰度比例为10%redis-cli set canary:percent 10逐步放量redis-cli set canary:percent 30redis-cli set canary:percent 50redis-cli set canary:percent 100紧急回滚redis-cli set canary:percent 0
-
使用nginx进行灰度发布的几种方式介绍 通常一个新功能开发完，测试环境可能跑得好好的，但生产环境因为数据量、并发量、网络环境完全不一样，可能会产生各种意料之外的错误。等发现问题的时候，可能已经造成了不小的影响。因此，新功能的发布推荐使用灰度发布的方式，先给少量用户试用新版本，确认无问题后再逐渐放量到全部用户。先给少量（如5%）的用户试用新版本，观察一段时间如果没问题，再逐步放量到20%、50%、100%一旦发现问题，立刻切回旧版本整个过程用户基本无感知值得注意的是，进行灰度发布时，监控和告警特别重要 。推荐做法：在Nginx日志里加上版本标记，然后用ELK收集日志，实时对比新旧版本的各项指标。这样在Kibana里就能看到每个版本的请求量、错误率、响应时间等指标，一目了然。此外还应配置告警规则，如果新版本的错误率比旧版本高出10%，或者响应时间慢了50%，就会自动发送告警，甚至可以自动回滚。log_format canary '$remote_addr - $remote_user [$time_local]' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' 'backend=$backend rt=$request_time'; access_log /var/log/nginx/access.log canary;优化建议灰度策略要灵活 不要一上来就5%、10%、50%、100%这样机械地放量。要根据实际情况灵活调整。比如一个小功能，可能5%观察半小时没问题，就直接100%了。但如果是核心功能的大改动，可能要5%观察一天，10%观察一天，慢慢来。最好是先在内部员工里测试，没问题后再给1%的真实用户，然后5%、10%、30%、50%、100%，每个阶段都要观察一段时间。做好回滚预案 灰度发布虽然降低了风险，但不代表没有风险。一定要做好回滚预案。推荐做法是，每次发布前都要演练一遍回滚流程，确保出问题的时候能在5分钟内回滚。而且回滚不能只是把流量切回去，还要考虑数据一致性、缓存清理等问题。用户体验要考虑 虽然灰度发布对用户来说应该是无感知的，但有些细节还是要注意。比如不要在用户操作的过程中切换版本，这样可能导致数据丢失或者页面错乱。我们的做法是，用Cookie做用户粘性，保证同一个用户在一段时间内（比如24小时）始终访问同一个版本。还有就是，如果新旧版本的UI差异比较大，最好在客户端做个平滑过渡，不要让用户觉得突兀。{lamp/}使用nginx可以通过多种 不同的方式来进行灰度发布，分别介绍如下：基于权重的流量分配这是最简单的一种方式，原理就是通过upstream的权重参数，把流量按比例分配到不同版本的服务器上。下面这个配置的意思是，100个请求里面，95个会打到旧版本服务器，5个会打到新版本。不过这种方式有个问题，就是同一个用户的请求可能一会儿打到旧版本，一会儿打到新版本，体验不太好。因此最好设置一个ip_hash。{callout color="#f0ad4e"}一、ip_hash 的作用ip_hash 是 Nginx 负载均衡的一种策略，主要提供会话保持（Session Persistence）功能：会话粘性：确保来自同一客户端 IP 的请求总是被转发到同一台后端服务器解决状态问题：当后端应用服务器没有共享会话状态时，避免用户会话丢失提升缓存效率：同一客户端的请求路由到同一服务器，可提高本地缓存命中率简化架构：避免部署复杂的分布式会话存储系统{/callout}upstream backend { ip_hash; server 192.168.1.10:8080 weight=95; # 旧版本 server 192.168.1.11:8080 weight=5; # 新版本 } server { listen 80; server_name api.example.com; location / { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }基于Cookie的灰度发布一个用户第一次访问的时候，我们给他打个标记，后续的请求都根据这个标记来决定走哪个版本。实现方式：用户第一次访问的时候，随机决定他是不是可以访问新版本，然后种个Cookie。后续请求都会带着这个Cookie，保证同一个用户始终访问同一个版本。但是这个方案还是有点粗糙，因为Nginx原生不支持生成随机数，我们需要借助一些技巧或者第三方模块。upstream backend_v1 { server 192.168.1.10:8080; } upstream backend_v2 { server 192.168.1.11:8080; } server { listen 80; server_name api.example.com; location / { set $backend "backend_v1"; # 如果Cookie中有canary标记，走新版本 if ($http_cookie ~* "canary=true") { set $backend "backend_v2"; } # 随机给5%的新用户打上canary标记 set $random_canary ""; if ($http_cookie !~* "canary") { set $random_canary "${random_canary}A"; } # 生成1-100的随机数 set $rand_num $request_id; if ($random_canary = "A") { # 这里简化处理，实际可以用Lua脚本 add_header Set-Cookie "canary=false; Path=/; Max-Age=86400"; } proxy_pass http://$backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }基于Header的灰度发布可以更精确地控制哪些用户走新版本，比如内部员工、测试账号、特定地区的用户等等。这时候可以用Header来做判断。这种方式特别适合做内部测试。使用方式：在客户端（比如App或者前端页面）加个开关，员工登录后自动在请求头里加上特定标记，这样就能体验新版本了。upstream backend_v1 { server 192.168.1.10:8080; } upstream backend_v2 { server 192.168.1.11:8080; } server { listen 80; server_name api.example.com; location / { set $backend "backend_v1"; # 如果请求头中有特定标记，走新版本 if ($http_x_canary_version = "v2") { set $backend "backend_v2"; } # 内部员工走新版本 if ($http_x_employee_id != "") { set $backend "backend_v2"; } proxy_pass http://$backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }基于IP地址的灰度发布还有一种场景，比如计划先在某个地区试点新功能，或者只给公司内网用户开放新版本。这时候可以用IP地址来做判断。geo模块是一个Nginx内置核心模块，用于根据客户端 IP 地址创建变量，实现基于地理位置或 IP 段的条件处理。它允许服务器对不同来源的请求执行不同的操作，无需额外安装，随 Nginx 一起编译。geo $canary_user { default 0; 10.0.0.0/8 1; # 公司内网 192.168.1.0/24 1; # 特定网段 123.45.67.89 1; # 特定IP } upstream backend_v1 { server 192.168.1.10:8080; } upstream backend_v2 { server 192.168.1.11:8080; } server { listen 80; server_name api.example.com; location / { set $backend "backend_v1"; if ($canary_user = 1) { set $backend "backend_v2"; } proxy_pass http://$backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }灰度发布中的一些常见问题Session一致性问题 如果Session存在服务器本地，用户的请求可能一会儿打到v1，一会儿打到v2，那么就会造成Session的丢失。于是就会造成用户登录状态老是丢失的问题。解决办法有两个：把Session存到Redis这种共享存储里用Cookie或者Header做用户粘性，保证同一个用户的请求打到同一个版本数据库兼容性问题 比如新版本改了数据库表结构，结果灰度发布的时候，新旧版本同时在跑，旧版本写入的数据新版本读不了，新版本写入的数据旧版本也读不了，整个系统乱套了。解决方案先发布一个兼容版本，既能处理旧数据格式，也能处理新数据格式等兼容版本全量发布后，再发布纯新版本这样虽然麻烦点，但安全多了。
-
ssh常见故障排查及解决措施 关键排查方法客户端调试: 使用 ssh -v 参数查看详细连接过程服务器日志: 检查 /var/log/secure 或 journalctl -u sshd 获取服务器端错误权限验证: 系统性检查文件和目录权限密钥验证: 使用 ssh-keygen -y 验证密钥对匹配性预防措施定期备份密钥: 避免密钥丢失导致无法访问使用现代密钥算法: 推荐使用 ED25519 而非 RSA保持权限正确: 使用自动化脚本定期检查关键文件权限启用多种认证方式: 配置密码认证作为备用方案监控 SSH 日志: 及时发现异常登录尝试常见 SSH 认证失败原因问题类型错误信息解决方法私钥权限过开放UNPROTECTED PRIVATE KEY FILEchmod 400 私钥文件主目录权限错误bad ownership or modeschmod 755 ~ + chown user:user ~.ssh 目录权限错误Authentication refusedchmod 700 ~/.sshauthorized_keys 权限错误认证失败无明确提示chmod 600 ~/.ssh/authorized_keys密钥算法不支持key type not in PubkeyAcceptedAlgorithms修改 sshd_config 启用算法密钥不匹配认证失败验证并更换正确的密钥对私钥文件权限问题错误信息: WARNING: UNPROTECTED PRIVATE KEY FILE! Permissions 0644 for 'xxxxx.pem' are too open. 问题分析:私钥文件权限为 0644（所有用户可读）SSH 安全机制要求私钥文件仅所有者可访问解决措施: chmod 400 /home/test/xxxx.pem密钥匹配性验证排查步骤:确认正确的私钥文件路径验证私钥与服务器公钥是否匹配验证命令:# 本地生成公钥指纹 ssh-keygen -y -f /home/test/xxxx.pem # 服务器端查看授权公钥 cat /home/ec2-user/.ssh/authorized_keys服务器端配置问题定位查看服务器 SSH 日志 (/var/log/secure)，可以发现的两个关键错误：目录权限错误: Authentication refused: bad ownership or modes for directory /home/ec2-user 密钥算法不支持: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]原因1：用户主目录权限配置错误 问题详情:/home/ec2-user 目录的所有权或权限不符合 SSH 安全要求。SSH 要求用户主目录及 .ssh 目录必须有严格的权限控制。SSH 权限要求:用户主目录: 755 权限，所有者为用户本人.ssh 目录: 700 权限，所有者为用户本人authorized_keys 文件: 600 权限，所有者为用户本人原因2：SSH 服务器禁用了 RSA 算法 问题详情:服务器 SSH 配置中未包含 ssh-rsa 算法客户端使用的是 RSA 类型的密钥版本 OpenSSH (8.8+) 默认禁用了 SHA-1 相关的 RSA 算法解决方案#在服务器端以 root 用户执行： # 1. 修复 ec2-user 主目录权限 chown ec2-user:ec2-user /home/ec2-user chmod 755 /home/ec2-user # 2. 修复 .ssh 目录权限 chmod 700 /home/ec2-user/.ssh chmod 600 /home/ec2-user/.ssh/authorized_keys chown -R ec2-user:ec2-user /home/ec2-user/.ssh # 3. 启用 ssh-rsa 算法支持 echo "PubkeyAcceptedAlgorithms +ssh-rsa" >> /etc/ssh/sshd_config # 4. 重启 SSH 服务 systemctl restart sshd
