我完全理解你的疑惑——这么多年来都是通过修改SSH主配置文件禁用密码登录，突然被一个子目录里的配置覆盖，确实打破了惯性操作，甚至会让人担心安全问题。

先给你理清这个问题的来龙去脉：

• 首先你有个小误区：你修改的/etc/ssh/ssh_config是SSH客户端的配置文件，用来控制本地发起SSH连接的行为；真正控制SSH服务端是否允许密码登录的是/etc/ssh/sshd_config。不过哪怕你改对了主服务端配置，依然会被sshd_config.d目录下的文件覆盖，这是设计使然。
• 这个/etc/ssh/sshd_config.d/50-cloud-init.conf是cloud-init工具生成的配置。cloud-init是Ubuntu面向云环境（或者预装该工具的镜像）的系统初始化工具，它会根据云平台的默认需求自动配置SSH，比如保持密码认证开启，方便用户首次登录系统。
• 这种将配置拆分到*.d目录的方式，是近些年来Linux发行版的一个趋势——不同组件的配置独立管理，不用直接修改主配置文件，避免不同工具的配置相互冲突。SSH服务端启动时，会先加载主sshd_config，再加载sshd_config.d目录下所有.conf后缀的文件，后面加载的配置会覆盖前面的，所以cloud-init的配置优先级更高。

这并非Ubuntu 22.04.3 LTS的bug，而是适配云环境的设计调整，但确实会让习惯传统操作的用户踩坑。给你几个解决办法：

• 修改cloud-init的SSH配置：直接编辑/etc/ssh/sshd_config.d/50-cloud-init.conf，把PasswordAuthentication yes改成no，然后重启服务：sudo systemctl restart sshd
• 添加自定义高优先级配置：在/etc/ssh/sshd_config.d目录下创建一个命名为99-custom-ssh.conf的文件（数字越大加载越晚，优先级越高），在里面写入PasswordAuthentication no，这样即使cloud-init后续更新了50开头的配置，你的自定义设置也会覆盖它
• 禁用cloud-init的SSH配置模块：如果你不需要cloud-init管理SSH，可以编辑cloud-init的配置文件（比如/etc/cloud/cloud.cfg），移除或注释掉ssh相关的模块，但这个方法适合熟悉cloud-init的用户

另外要注意：如果后续系统更新时cloud-init重新生成了50-cloud-init.conf，可能会重置你的修改，所以用自定义高优先级配置的方法更稳妥。

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