看起来你已经在主配置文件里指定了禁用SHA1相关的密钥交换算法，但重启sshd后依然能看到SHA1算法出现在有效配置里，咱们一步步排查可能的问题：

• 先检查配置文件语法是否正确：运行sshd -t命令验证配置文件的语法，如果有语法错误（比如逗号遗漏、算法名称拼写错误），sshd会拒绝加载新配置，继续使用旧配置。如果命令没有输出，说明语法没问题；如果有报错，根据提示修复即可。

• 检查是否存在其他配置文件覆盖主设置：很多现代Linux发行版的sshd配置会通过Include指令加载额外的配置文件，比如你可以查看/etc/ssh/sshd_config开头或结尾是否有类似Include /etc/ssh/sshd_config.d/*.conf的行。如果有，进入对应的目录查看里面的.conf文件，说不定其中某个文件重新定义了KexAlgorithms，覆盖了你在主文件里的设置。

• 处理GSSAPI相关的SHA1算法：从你输出的gssapikexalgorithms结果来看，里面还包含带SHA1的项。如果你不需要GSSAPI认证，可以直接在配置文件里添加GSSAPIAuthentication no来完全禁用；如果需要保留GSSAPI，就单独设置GSSAPIKexAlgorithms参数，只保留SHA2相关的算法，比如：

  GSSAPIKexAlgorithms gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-
  

• 确认sshd服务确实重启成功：有时候看似执行了systemctl restart sshd，但服务可能因为配置错误没启动起来。你可以运行systemctl status sshd查看服务状态，确保显示active (running)，并且重启时间是你操作后的时间。如果重启失败，查看日志journalctl -u sshd找具体原因。

• 检查主配置的关键行是否被误注释：虽然你贴出来的配置里KexAlgorithms行没有注释，但要确认实际的/etc/ssh/sshd_config文件里这一行前面没有#符号，也没有被其他注释符号影响。

另外补充一点：不同版本的OpenSSH对配置的处理可能略有差异，如果你用的是较旧的版本，需要确保算法名称完全匹配（不过你配置里的算法都是主流SHA2类，应该不会有版本兼容问题）。

备注：内容来源于stack exchange，提问作者Tim Perkins