服务器禁用免密SSH登录的核心方法是修改SSH服务端配置文件，关闭公钥认证或清空授权密钥，然后重启ssh服务使配置生效。具体操作涉及/etc/ssh/sshd_config文件中的PubkeyAuthentication参数，以及~/.ssh/authorized_keys文件的管理，本文将从检测、配置到验证，拆解完整的禁用步骤。
服务器禁用免密SSH登录方法：先摸清你的认证现状
想彻底关掉免密登录,第一步得先搞清楚服务器当前是怎么认证的，登录服务器后，执行以下命令查看SSH服务端的生效配置：
sshd -T | grep -E 'pubkeyauthentication|passwordauthentication|authorizedkeysfile'
输出结果中，pubkeyauthentication yes表示当前允许密钥登录，passwordauthentication yes表示允许密码登录。 如果前者为yes且authorizedkeysfile指向了默认路径，那么任何持有对应私钥的人都能免密进入系统，这正是需要处理的风险点。
另一个常见场景是云服务器控制台里的“密钥对”功能，简米云、酷番云等平台在创建实例时若选择了密钥登录，默认会关闭密码登录，同时启用免密认证，这种情况下，仅修改系统内部配置文件还不够，还需要在控制台重置实例密码或调整登录方式，否则重启后配置可能被云平台的初始化脚本覆盖。
检测时还要留意~/.ssh/authorized_keys文件，执行：
cat ~/.ssh/authorized_keys
非空,说明至少有一位用户的公钥被信任。逐行检查每个条目，确认是否都是你认识的密钥。 凡是来历不明的公钥，一律删掉。
禁用SSH密钥认证的两种配置路径
修改SSH认证方式有两条路,全局配置和用户级配置，适用场景不同，建议按需选择。
全局关闭公钥认证：适用于多用户服务器
对于有多人使用的服务器,直接在/etc/ssh/sshd_config中修改是最稳妥的做法，编辑该文件，找到或新增以下参数：
PubkeyAuthentication no PasswordAuthentication yes
第一行关闭公钥认证,第二行明确开启密码认证，避免出现“两边都关了登不进去”的尴尬，保存后执行：
systemctl restart sshd # CentOS/RHEL系统 systemctl restart ssh # Debian/Ubuntu系统
重启后，所有用户都无法使用密钥登录，必须走密码验证。 这个方案很彻底，适用于对安全要求较高、且所有使用者都能记住密码的场景。
清理特定用户的授权密钥：适用于保留少数密钥的场景
如果你只是想让某几个用户不能免密登录,但其他人还需要密钥认证，那就别动全局配置，直接清空目标用户的authorized_keys文件：
> /home/用户名/.ssh/authorized_keys
注意>符号会把文件内容清空但不删除文件，执行后再确认一下SSH行为：
ssh -o PreferredAuthentications=publickey 用户名@服务器IP
如果服务器返回Permission denied (publickey)，说明该用户的密钥登录已被禁止，行业共识认为，在保留密钥认证的前提下清理单个用户授权，比全局关闭更灵活，适合有运维审计需求的团队。
SSH免密登录如何关闭：别漏掉这三处隐藏入口
实操中,很多人改了sshd_config却发现免密登录仍然生效，原因往往出在下面三个地方。
检查ssh客户端配置中的Host别名覆盖
本地电脑的~/.ssh/config文件里，可能给服务器设置了Host别名，并且在别名下强制指定了PreferredAuthentications publickey，这种客户端配置会绕过服务端的认证偏好协商，建议在该文件中调整或删除相关偏好设置，确保客户端允许交互式密码输入。
注意云平台的安全组和VNC入口
部分云平台的安全组规则会放行特定端口的SSH访问,但真正影响免密登录的是实例的登录管理配置，如果云控制台显示“密钥对已绑定”，那么即使系统内部关闭了公钥认证，云平台自带的VNC终端或者“一键登录”功能仍可能调用密钥对完成身份验证，此时需要到云平台控制台，解绑密钥对或重置登录密码，才算真正关掉免密通道。
处理SSH服务配置文件中的Match块
sshd_config中如果存在Match User或Match Group段落，这些条件块里的配置会覆盖全局设置，比如全局设了PubkeyAuthentication no，但Match块中写了PubkeyAuthentication yes，那么匹配到的用户仍然可以免密登录，检查配置时，务必同时查看条件块内容，或者用sshd -T查看最终生效值。
设置完免密关闭后，如何验证安全策略生效
配置改完不等于工作结束,验证这一步能帮你确认策略真的落地，推荐按以下顺序测试：
- 从本地发起带密钥的SSH连接，预期结果是提示输入密码或直接拒绝，若依旧免密进入，说明配置未生效。
- 检查系统日志，执行
journalctl -u sshd | tail -50，找找有没有Failed publickey或Connection closed by authenticating user之类的记录。 - 用密码登录测试，确保密码认证功能正常，避免把自己锁在门外。
- 审查SSH服务端口是否暴露在公网，若端口对外开放但密码强度偏弱，建议配合
fail2ban限制暴力破解。
据统计,相当一部分服务器入侵事件发生在SSH端口暴露、且未关闭密钥认证的情况下。关闭免密登录只是基础动作，搭配定期轮换密码和密钥，才能形成有效的访问控制闭环。
常见问题排查：改完SSH配置无法用密码登录
关闭密钥认证后,有时会碰到“密码怎么输都不对”的情况，届时应逐项核对sshd_config中的PermitRootLogin、PasswordAuthentication和ChallengeResponseAuthentication参数是否都允许了密码登录。确保重新加载服务后，通过sshd -T检查参数实际状态，因为/etc/ssh/sshd_config.d/目录下的分片配置文件可能改写了主配置。
另一种可能登录不上的原因是PAM模块限制,部分发行版的SSH依赖pam_unix.so完成密码验证，若/etc/pam.d/sshd被修改过，密码认证会异常，将sshd_config中的SELinux影响也纳入考虑，CentOS等系统上需要确认SELinux策略没有阻止sshd读取相关文件，如需调整，考虑：
setsebool -P sshd_use_pty=1
该命令能修复部分因SELinux导致的SSH密钥认证异常状况,若修改后SSH服务启动失败，可通过sshd -t检查配置语法，多数错误都能在输出信息中定位。
免密登录设置后的服务器安全配置建议
已经关闭了免密登录,顺手再加固一下其他安全设置效果更佳，业内专家指出，SSH安全配置遵循最小化原则时，服务器被攻破的概率会明显下降，除了禁用密钥认证，以下参数建议同步调整：
PermitRootLogin no MaxAuthTries 3 LoginGraceTime 30 ClientAliveInterval 300 ClientAliveCountMax 0
分别表示禁止root直接登录、限制密码尝试次数为3次、限制登录超时时间为30秒、每5分钟保活检查一次连接、超时后立即断开连接，这些参数能有效压缩暴力破解的时间和空间。
结合防火墙白名单，限制仅允许办公网段IP访问SSH端口（默认22），是性价比最高的防护手段，对于同时运行Web服务的服务器，务必区分SSH服务和管理后台的访问来源，避免因业务端口暴露而连带SSH面临攻击，若采购了国内主流云服务商的服务器，还可借助其自带的主机安全组件，比如云安全中心的基线检查功能，自动检测SSH配置中是否存在“允许免密登录”等风险项，达到联动治理的效果。
云服务器SSH免密登录相关问题解答
问：云服务器由密钥对创建的，能在系统内直接关闭免密登录吗？
可以,但需要同时处理控制台和系统两层配置，先在系统内设置PubkeyAuthentication no并重启服务，再登录云控制台，进入实例详情页的解绑密钥对或重置密码操作，确保控制台侧的登录方式也变更为密码认证。
问：关闭免密登录后，原本配置的密钥自动部署功能是否还能用？
如果关闭了全局公钥认证,依赖SSH密钥的自动化部署工具会立即失效，比如Ansible、rsync-over-SSH或Git部署钩子，它们默认走密钥通道，为不影响自动化流程，建议保留一条专用的部署专用密钥白名单路径，同时保证日常运维使用密码登录，这需要利用Match User语法为指定账号单独开启公钥认证，搭配防火墙限制其来源IP，将免密范围控制在特订管理通道内。
问：如何查看服务器是否支持免密SSH登录？
执行sshd -T | grep pubkeyauthentication，观察到输出为pubkeyauthentication yes时，意味着该服务器开启了公钥认证能力，但能否免密登录还需确认目标用户的authorized_keys里是否有对应公钥，若输出为no，则服务端已不允许任何形式的密钥登录，综合检查/etc/ssh/sshd_config及/etc/ssh/sshd_config.d/目录下的碎片化配置，确认没有其他覆盖项，才能准确判定服务器的真实认证状态。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/789263.html
