简介这份PDF文档面向Linux系统管理员、运维工程师及刚接触服务器安全配置的学习者聚焦SSH服务的安全加固与远程登录管理帮助读者解决默认配置下端口暴露、root账户可远程登录、空密码用户可登录等常见安全隐患。文档围绕sshd_config配置文件展开涵盖修改默认端口、禁止root远程登录、禁止空密码用户登录、启用RSA与公钥认证、生成并分发密钥对以及使用puttygen转换密钥配合putty连接等完整流程并补充了公钥认证原理与StrictModes权限检查等排错要点。资源包共1个PDF文件大小约288KB内容紧凑、步骤清晰适合作为日常运维查阅或安全加固的操作参考。目前已有156人学习下载可帮助读者快速掌握SSH安全配置的关键项与验证方法。1. 一台新装的 Linux 服务器为什么第一件事就是改 SSH 和 Root 登录刚拿到一台云主机或者装完一台 CentOS、Ubuntu很多人第一反应是装 Docker、配环境、拉代码。但真正在生产环境待过的人都知道新机器上线前有一件事必须先做把 SSH 配置和 Root 远程登录策略定下来。原因很直接——默认配置下22 端口对全网开放Root 账号允许密码登录等于把大门钥匙挂在门口。暴力破解脚本每天扫描几十万次弱密码机器撑不过几个小时。这份《Linux SSH配置和禁止Root远程登陆设置文档.pdf》解决的正是这个场景从 sshd_config 的核心参数讲起一步步教你禁用 Root 远程登录、改用普通用户加 sudo、配置密钥认证、限制登录来源最后给出验证和回滚方法。它适合刚接触 Linux 运维的新手照着做也适合有经验的人拿来当配置清单核对。下面我按文档里的思路把每一步拆开讲清楚包括参数含义、常见翻车点和排查方法。2. SSH 配置文件拆解sshd_config 里哪些参数真正决定安全边界2.1 先搞清楚 sshd_config 和 ssh_config 的区别很多人第一次改配置就翻车是因为改错了文件。Linux 里跟 SSH 相关的配置文件有两个名字只差一个字母作用完全不同文件路径作用对象典型用途/etc/ssh/sshd_config服务端控制谁能连进来、怎么认证/etc/ssh/ssh_config客户端控制本机作为客户端连出去时的行为你要禁止 Root 远程登录、改端口、开密钥认证改的全是sshd_config。改完必须重启 sshd 服务才生效。改ssh_config对别人连你没有任何影响这是新手最容易踩的第一个坑。常见做法是改之前先备份# 备份原始配置出问题能快速回滚 cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date %F) # 查看当前生效的配置注意sshd -T 输出的是最终生效值不是文件原文 sshd -T | grep -E permitrootlogin|passwordauthentication|portsshd -T这个命令很关键。它会把 Include 进来的子配置、默认值全部合并后输出最终结果。很多时候你改了主文件却没生效就是因为/etc/ssh/sshd_config.d/目录下有更高优先级的覆盖文件。先看sshd -T的真实值再决定改哪里能省掉大量玄学排查。2.2 决定安全边界的六个核心参数文档里重点讲了这几个参数我按重要程度排一下每个都说清楚改与不改的后果PermitRootLogin控制 Root 能否通过 SSH 登录。可选值有yes允许密码和密钥、no完全禁止、prohibit-password禁止密码允许密钥、forced-commands-only仅允许指定命令。生产环境建议直接设no。设成prohibit-password看似折中但只要密钥泄露Root 照样能被登。PasswordAuthentication是否允许密码认证。设成no后只能用密钥登录暴力破解直接失效。这是提升安全最有效的一步但前提是你已经配好密钥否则会把自己锁在门外。Port默认 22。改成非标准端口能减少扫描量但别把它当安全手段——端口扫描一样能找到。它的价值是降低日志噪音。ListenAddress限制监听的网卡。如果服务器有内网和外网两块网卡可以只监听内网地址外网通过跳板机访问。AllowUsers / DenyUsers白名单和黑名单。AllowUsers deploy admin表示只有这两个用户能登录其他一律拒绝。白名单比黑名单可靠因为黑名单永远列不全。MaxAuthTries单次连接允许的认证尝试次数。默认 6改成 3 能进一步压缩暴力破解空间。这几个参数之间有联动关系。比如你把PasswordAuthentication设成no但PermitRootLogin还是yes那 Root 用密钥仍然能登反过来PermitRootLogin no加上密码认证开着普通用户还是能被爆破。要组合起来看不能只改一个就以为万事大吉。2.3 改配置的标准流程和生效验证改sshd_config有个铁律永远不要断开当前连接去重启服务。正确做法是保留一个已登录的会话另开一个窗口测试新连接确认能登再关旧窗口。# 1. 编辑配置用你顺手的编辑器 vim /etc/ssh/sshd_config # 2. 改完先做语法检查这一步能拦住大部分低级错误 sshd -t # 如果没有输出说明语法没问题有输出就按提示改 # 3. 语法通过后再重启服务 systemctl restart sshd # CentOS 6 及更早版本用service sshd restart # 4. 另开一个终端测试新连接确认能登进来 ssh deployyour-server-ip -p 2222 # 5. 确认无误后再关闭旧会话sshd -t这个检查步骤很多人跳过结果配置写错一个单词重启后服务起不来SSH 全断只能去云控制台走 VNC 救急。血泪经验语法检查花三秒能省半小时。重启后用sshd -T再确认一遍生效值尤其是你改的那几项。如果发现没生效优先检查/etc/ssh/sshd_config.d/下有没有覆盖文件以及配置项是不是被写在了文件末尾的 Match 块里——Match 块内的配置只对匹配的用户或地址生效容易让人误以为全局没生效。3. 禁止 Root 远程登录的完整落地从建普通用户到密钥认证3.1 先建好替代账号再禁 Root禁止 Root 登录最大的风险是禁完之后发现自己没有别的账号能登直接锁死。所以顺序必须是先建普通用户、配好 sudo、验证能登最后才禁 Root。# 1. 创建运维用户以 deploy 为例 useradd -m -s /bin/bash deploy # 2. 设置密码如果走密钥认证这步可以设一个强随机密码备用 passwd deploy # 3. 加入 sudo 组不同发行版组名不同 # Debian/Ubuntu usermod -aG sudo deploy # CentOS/RHEL usermod -aG wheel deploy # 4. 验证 sudo 是否生效切换到 deploy 用户后执行 su - deploy sudo whoami # 期望输出rootuseradd -m的-m是创建家目录不加的话用户没有 home登录后一堆工具找不到配置。-s /bin/bash指定登录 shell有些系统默认给/sbin/nologin那样用户根本登不进来。这两个参数新手经常漏。sudo 组名要按发行版来。Ubuntu 是sudoCentOS 是wheel加错了sudo命令会提示不在 sudoers 文件里。验证sudo whoami输出 root 才算配好。3.2 配置密钥认证把密码登录彻底关掉密钥认证比密码安全得多也是禁用密码登录的前提。流程是本地生成密钥对把公钥传到服务器。# 本地机器上生成密钥对推荐 ed25519比 RSA 更短更安全 ssh-keygen -t ed25519 -C deployprod -f ~/.ssh/id_ed25519_deploy # 把公钥传到服务器ssh-copy-id 会自动处理权限 ssh-copy-id -i ~/.ssh/id_ed25519_deploy.pub deployyour-server-ip # 测试密钥登录应该不再提示输入密码 ssh -i ~/.ssh/id_ed25519_deploy deployyour-server-ipssh-keygen的-t指定算法-C是注释一般写用途和机器方便管理多把密钥-f指定私钥保存路径。不指定-f会默认覆盖~/.ssh/id_rsa如果你已经有一把在用就会把旧的覆盖掉这是很常见的翻车点。ssh-copy-id会自动把公钥追加到服务器的~/.ssh/authorized_keys并设好权限。如果手动传权限必须对.ssh目录 700authorized_keys文件 600属主是用户自己。权限不对 SSH 会静默拒绝密钥日志里只写一句Authentication refused: bad ownership or modes不仔细看根本找不到原因。密钥登录验证通过后再改服务端配置关掉密码认证# 编辑 /etc/ssh/sshd_config确认以下三项 PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes # 语法检查 重启 sshd -t systemctl restart sshd改完同样保留旧会话另开窗口测试。这次测试要确认两件事普通用户能用密钥登进来Root 用任何方式都登不进来。3.3 用 Match 块做精细化控制一刀切禁 Root 有时候不够灵活。比如你需要允许某个内网 IP 的 Root 登录做自动化其他来源一律禁止。这时候用 Match 块# 在 sshd_config 末尾添加 # 全局默认禁止 Root、禁止密码 PermitRootLogin no PasswordAuthentication no # 对特定来源放开Match 块必须放在文件末尾 Match Address 10.0.0.0/24 PermitRootLogin prohibit-passwordMatch 块的规则是块内配置覆盖全局配置只对匹配的连接生效。注意 Match 块必须写在文件最后写在中间的话它后面的全局配置会被误纳入块内导致意料之外的行为。改完一样用sshd -T配合-C参数验证特定连接的生效值# 模拟从 10.0.0.5 连接时permitrootlogin 的生效值 sshd -T -C addr10.0.0.5,userroot | grep permitrootlogin这个-C参数是排查 Match 块问题的利器能直接告诉你某个来源、某个用户实际会命中什么配置不用真的去连。4. 避坑与排查SSH 改配置后连不上的五种典型情况4.1 改完重启新连接直接被拒绝现象改完sshd_config重启服务当前会话还在但新开终端连不上提示Connection refused。原因sshd 服务根本没起来。多半是配置语法错误或者端口被改成已被占用的值。systemctl restart sshd在某些系统上即使失败也不报错服务处于 failed 状态。解决先看服务状态和日志。systemctl status sshd看是否 activejournalctl -u sshd -n 50看最近日志。如果是语法错误sshd -t会直接指出行号。修好后重启。如果当前会话还在别关修完再测。4.2 密钥登录一直提示输入密码现象公钥传了PubkeyAuthentication yes也开了但登录还是让输密码输对了能进说明密钥没被采用。原因权限问题占九成。家目录、.ssh目录、authorized_keys三者权限或属主不对sshd 会拒绝使用密钥。剩下的一成是 SELinux 上下文不对或者家目录被加密。解决按顺序修权限。chmod 700 /home/deploy/.ssh chmod 600 /home/deploy/.ssh/authorized_keys chown -R deploy:deploy /home/deploy/.ssh # 如果开了 SELinux恢复上下文 restorecon -Rv /home/deploy/.ssh改完看/var/log/secureCentOS或/var/log/auth.logUbuntu里面会明确写拒绝原因。4.3 禁了 Root 之后发现自己没别的账号现象PermitRootLogin no生效后发现普通用户密码忘了或者 sudo 没配好彻底进不去。原因操作顺序错了先禁 Root 再建替代账号。解决只能走云厂商控制台的 VNC 或者救援模式。进去后临时把PermitRootLogin改回yes重启登进去把普通用户配好再改回来。这个坑没有后悔药只能靠顺序避免——永远是先建号、验证、再禁 Root。4.4 改了端口但防火墙没放行现象Port从 22 改成 2222sshd -t通过服务也重启了但连 2222 超时。原因防火墙或安全组没放行新端口。本机 firewalld/ufw 和云平台安全组是两层都要放。解决# firewalld firewall-cmd --permanent --add-port2222/tcp firewall-cmd --reload # ufw ufw allow 2222/tcp云平台的安全组规则要去控制台单独加命令行改不了。两层都放行后再测。4.5 配置写在 Match 块后面导致不生效现象明明写了PermitRootLogin no但 Root 还是能登。原因这行配置被写在了某个 Match 块之后被归入了块内只对匹配的连接生效全局没生效。解决用sshd -T看全局生效值用sshd -T -C addr实际来源IP,userroot看具体连接的生效值。如果全局值不对把配置挪到所有 Match 块之前。养成习惯全局配置放文件前部Match 块统一放末尾。5. 进阶技巧用 sshd -T 和日志把 SSH 配置变成可验证的闭环配置改完不是终点能验证、能回滚、能审计才算闭环。我一般会固定做三件事。第一件把sshd -T的输出存成基线。每次改配置前跑一遍存下来改完再跑一遍对比diff 一下就知道到底改动了哪些生效值避免以为改了其实没改。# 改前存基线 sshd -T /tmp/sshd_before.txt # 改完再存 sshd -T /tmp/sshd_after.txt # 对比差异 diff /tmp/sshd_before.txt /tmp/sshd_after.txt第二件用sshd -T -C模拟不同来源和用户的组合验证 Match 块逻辑。这个命令不用真的发起连接就能看到某个 IP、某个用户实际会命中什么配置排查 Match 问题时比反复试连高效得多。第三件盯日志。SSH 的认证失败、密钥拒绝、来源限制全都会写进日志。CentOS 系看/var/log/secureDebian 系看/var/log/auth.log。用grep过滤关键事件# 看最近的认证失败 grep Failed password /var/log/secure | tail -20 # 看密钥被拒绝的原因 grep Authentication refused /var/log/secure | tail -20 # 统计暴力破解来源 IP按次数排序 grep Failed password /var/log/secure | awk {print $(NF-3)} | sort | uniq -c | sort -rn | head最后这条统计很有用能直接看出哪些 IP 在爆破你。如果某个 IP 尝试次数特别高可以在防火墙层直接封掉比改 SSH 配置更立竿见影。还有一个容易被忽略的点配置改完后把最终版sshd_config纳入版本管理。用 Git 存一份每次改动写清楚原因。服务器多了以后哪台机器是什么配置、什么时候改的、为什么改全靠这个记录。我见过太多团队因为没人记得某台机器的 SSH 配置为什么跟别的不一样排查问题时绕一大圈。从那以后我每次动 SSH 配置都强制走一遍备份 → 改 →sshd -t→ 保留旧会话 → 新窗口验证 → 存基线这个流程一次都没再把自己锁在门外。希望帮到你。本文还有配套的精品资源点击获取
