Linux服务器登录怎么加固才不被爆破？SSH密钥、禁root、sudo与fail2ban实战

一台刚开机、绑上公网IP的云服务器，用不了几分钟，SSH的22端口就会被全球的扫描器盯上，日志里成千上万条试密码的记录哗哗往里灌。这不是针对你，而是整个互联网每时每刻都在自动扫弱口令——你只要用了默认密码登录、用了简单口令，被攻进去只是时间问题。

偏偏很多自管VPS的独立站主，把全部精力放在网站和业务上，服务器登录这道最外层的门却几乎没设防：root直接用密码登、口令还很简单、没装任何防爆破。保哥这篇不讲怎么装系统，只把服务器登录这道门怎么焊死讲透：为什么必须用密钥登录而不是密码、密钥怎么配又怎么安全关掉密码登录、要不要禁root和改端口、怎么用普通用户加sudo最小权限告别root裸奔、fail2ban怎么挡暴破、还有哪些登录面要一起收紧、怎么发现有人正在爆破，最后给落地顺序和最容易踩的坑。

登录加固是性价比最高的安全投入——花一两个小时，挡掉九成九的自动化攻击。

为什么说SSH登录是自管服务器最先挨打的一道门？

保哥每次帮人接手一台新的云服务器，第一件事就是翻它的登录日志。哪怕是一台刚开机几个小时、还没对外公布过任何信息的机器，日志里往往已经躺着成百上千条来自世界各地的登录尝试——清一色冲着root账户、试着各种常见弱口令。很多第一次自管服务器的站长看到这个会吓一跳：我这服务器谁都不知道，怎么就被盯上了？

真相是，这跟你知名不知名、站大站小毫无关系。互联网上有数不清的自动化扫描器，全天候不间断地扫遍整个公网IP段，挨个IP去试SSH端口、试管理员账户加弱口令字典，纯粹是机器在批量碰运气。你的服务器只要绑了公网IP，就自动进了它们的扫描范围，被持续敲门只是分分钟的事。

而SSH登录，恰恰是这些攻击的头号目标，因为它是进入服务器的总闸门。一旦被人撞开SSH，拿到一个能登录的账户，尤其是root，那这台机器就彻底沦陷了——网站、数据库、客户数据，全在人家掌控之下，还可能被植入挖矿程序、被当成攻击别人的跳板。相比之下，应用层那些漏洞的危害都还隔了一层，SSH这道门一破，就是直接交钥匙。

偏偏这道最该焊死的门，是最多自管VPS的独立站主忽视的地方。大家的精力都在网站、在业务、在流量上，服务器拿到手用默认配置就开跑：root直接用密码登、口令图省事设得很简单、什么防爆破都没装。这篇文章只聚焦一件事——怎么把服务器登录这道门焊到攻击者撬不动。保哥不讲装系统、不讲应用层安全，只把SSH密钥、禁root、sudo最小权限、fail2ban、登录审计这几件登录加固的核心，一段段拆开讲透。它是性价比最高的安全投入：花一两个小时，能挡掉九成九的自动化攻击。

密码登录到底有多危险，为什么必须换成密钥登录？

登录加固的第一刀，砍在登录方式上：从密码登录换成密钥登录。这是收益最大的一步，值得先把道理讲透。

密码登录的命门，是它可以被在线无限次地猜。攻击者对着你的SSH端口，用字典一个接一个地试密码，一秒钟能试很多次，全自动跑着。再复杂的密码理论上都能被慢慢撞开，更别说现实里大多数人的密码远没自己以为的那么强。只要还开着密码这条路，暴破的大门就一直敞着，剩下的只是攻击者愿不愿意花时间。

密钥登录则换了一套完全不同的逻辑。它用一对非对称密钥：公钥放在服务器上，私钥留在你自己电脑里。登录时，靠密码学的方式验证你确实持有那把私钥，全程不传输任何可以被猜的口令。攻击者手里没有你的私钥文件，就根本无从下手——他面对的不再是猜一个字符串，而是要伪造一个在数学上几乎不可能伪造的密钥。一个标准的SSH密钥，其强度是任何人类能记住的密码都望尘莫及的。

所以密钥登录加上关闭密码登录，等于直接把暴力破解这条路从原理上堵死了——攻击者再怎么扫、怎么猜，都撞在一堵没有门的墙上。这就是为什么所有正经的服务器安全指南，都把改用密钥登录、关闭密码认证列为头等大事。它不是锦上添花，而是登录安全的地基。

关于密钥，有两个实操细节值得先交代。一是私钥的保管——私钥就是你的身份本身，必须严密保管在自己的设备上，绝不能随便拷来拷去、更不能传到聊天工具或不可信的电脑里；一旦怀疑私钥泄漏，就立刻把服务器上对应的公钥删掉、换一对新的。二是多设备的处理——如果你有好几台电脑要登同一台服务器，规范做法是每台设备各自生成一对密钥，把它们的公钥都加进服务器的授权列表，而不是把同一个私钥到处拷贝。这样哪台设备丢了或不用了，只需在服务器上删掉它那把公钥，其余设备照常登录，互不影响。

SSH密钥登录怎么配，配好后如何安全地关掉密码登录？

道理认了，怎么落地？密钥登录的配置不复杂，但有个顺序绝对不能错，否则真会把自己锁在门外。

大致流程是这样：先在你自己的本地电脑上生成一对密钥（用ssh-keygen，推荐ed25519类型），私钥严密保管在本地、绝不外传，公钥则上传到服务器上你那个登录用户的授权列表里（也就是用户家目录下的 .ssh/authorized_keys文件）。配好之后，你的电脑用私钥就能免密码登录这台服务器了。私钥本身还可以再加一道密码短语保护，这样即便私钥文件被偷，没有那个短语也用不了。

公钥、私钥就位、密钥能正常登录之后，才轮到关闭密码登录这一步。这要改SSH服务端的配置文件sshd_config，把密码认证关掉、把密钥认证打开。几个核心配置项长这样：

# /etc/ssh/sshd_config 登录加固关键项
PermitRootLogin no            # 禁止 root 直接登录
PasswordAuthentication no     # 关闭密码登录，只允许密钥
PubkeyAuthentication yes      # 启用公钥认证
MaxAuthTries 3                # 单次连接最多尝试 3 次认证

改完保存，重载SSH服务让配置生效。这里有一条保哥反复叮嘱的铁律：关闭密码登录前，必须先用密钥实际成功登录一次。正确操作是——改完配置、重载服务后，千万别退出当前这个还连着的会话，而是另开一个新的终端窗口，用密钥去登录试试，确认能进，再回到原会话彻底放心。万一新窗口连不上，你当前这个会话还活着，可以马上把配置改回去。绝不能配完没验证就急着断开，那是把自己往门外锁的典型操作。

就算真出了意外被锁在外面，也还有后路：几乎所有云服务器厂商都提供网页版控制台或者VNC救援登录入口，它不走SSH，能直接进系统改回配置。提前知道自己服务商的这个入口在哪，心里就有底。sshd_config里每个配置项的确切含义和可选值，OpenSSH官方手册讲得最权威OpenSSH官方手册 — sshd_config(5)（SSH服务端配置，含PermitRootLogin、PasswordAuthentication），改配置前对着它逐项确认，别照抄网上来路不明的配置。

要不要禁掉root直接登录，改SSH端口到底有没有用？

这两个是登录加固里最常被讨论、也最容易被误解的措施，得把各自的作用和分量说清楚，别高估也别忽略。

先说禁用root直接登录，这是实打实的加固，值得做。root是每台Linux都有、人人都知道名字的超级管理员账户，正因为名字是公开的、权限又最大，它成了暴力破解的头号靶子——扫描器试的几乎全是root。禁掉root直接登录后，攻击者就得先猜中你自定义的那个普通用户名，再过密钥这关，难度陡然上升。日常运维改成用普通用户登录、需要管理员权限时再临时提权，这也符合下一节要讲的最小权限原则。

再说改SSH端口，这个的分量要摆正。把默认的22端口换成一个不常见的高位端口，确实能让你的日志清净一大截，因为绝大多数无脑扫描器只盯着默认端口扫，换了端口它们就扑空了。但要清醒认识到：这是隐藏，不是加固。真正认真盯上你的攻击者，扫一遍全端口照样能找到你的SSH。所以改端口可以做，作为减少噪音的辅助手段，但绝不能把它当成主要防线，更不能因为改了端口就放松密钥和fail2ban那些真正的措施。

保哥的态度是：禁root必做，改端口可做但别当回事，两者都属于纵深防御里的一层，而不是终点。安全从来不靠某一个聪明的小技巧，而靠把一层层基本功都做扎实——密钥登录、关密码、禁root、最小权限、fail2ban，叠加起来才是真正撬不动的门。任何宣称做了某一件事就绝对安全的说法，都该警惕。

怎么用普通用户加sudo最小权限，告别整天root裸奔？

很多人图省事，从头到尾就用root一个账户干所有事——登录是root、跑服务是root、部署网站也是root。这叫root裸奔，是个相当危险的习惯，得改掉。

问题出在哪？root拥有系统的最高权限，能干任何事，包括删掉整个系统。用root日常操作，一个手滑的命令就可能酿成不可逆的灾难；更要命的是，如果你跑的某个服务、某段脚本被攻破，而它正以root身份运行，攻击者就直接继承了root的全部权限，整台机器瞬间易主。权限越大，出事时的破坏面就越大。

正确的做法遵循最小权限原则：日常用一个权限受限的普通用户登录和操作，只有在确实需要执行管理任务时，才通过sudo临时借用一下管理员权限，用完即还。这样平时跑着的进程都是低权限的，就算被攻破，攻击者拿到的也只是个受限账户，没法直接接管全系统，给你留出了反应和止损的空间。

落地上，新建一个专用的运维普通用户，把它加进sudo权限组，日常就用它登录。需要管理员操作时，命令前加sudo，系统会要求验证后再执行。

更精细的做法是通过sudoers配置，精确规定哪个用户能用sudo执行哪些命令——比如只允许某个部署用户重启特定的服务，而不给它全套root能力，把权限切到刚好够用。sudoers的语法和安全策略，Linux官方手册讲得很细Linux手册 — sudoers(5)（sudo安全策略与最小权限配置），配精细化权限前务必照它的规则来，写错sudoers反而可能开出意料之外的口子。

这套用户与权限的规划，和服务器上各种自动化运维脚本该用什么身份跑也是连在一起的。保哥在 Linux定时任务与运维自动化那篇里讲过，定时任务、部署脚本同样要遵循最小权限、别一律用root跑，登录加固和日常运维的权限设计要对齐成一套，才不会一边把登录焊死、一边又用root跑着一堆脚本留后门。

fail2ban怎么挡住暴力破解，几个关键参数怎么调？

密钥登录从原理上堵死了暴破，那还要fail2ban干嘛？因为日志里那些前赴后继的失败尝试虽然撞不开门，却在持续消耗资源、污染日志，而且多一道主动封禁的防线总是好的。fail2ban就是干这个的。

它的原理很直白：盯着登录日志，发现某个IP在一段时间内反复登录失败、超过设定的次数，就自动调用防火墙把这个IP临时封禁掉，让它在一段时间内连都连不上。这样那些不死心反复来试的扫描器，撞几下就被关在门外了。fail2ban通过一个叫jail（牢笼）的概念来组织规则，针对SSH的规则一般配在一个sshd的jail里。

几个关键参数决定了它的脾气：

# /etc/fail2ban/jail.local（自定义配置，不要直接改 jail.conf）
[sshd]
enabled  = true
maxretry = 4        # 允许失败几次，超过就封
findtime = 10m      # 在这个时间窗口内统计失败次数
bantime  = 1h       # 封禁多长时间，可设更长甚至永久

maxretry是容忍的失败次数，findtime是统计窗口，bantime是封禁时长。这三个要配合调：maxretry别设太小，免得自己偶尔输错也被误封；bantime可以设得长一点，让那些惯犯长时间进不来。还有个ignoreip，一定要把自己常用的固定IP加进白名单，避免哪天自己手滑被自己的fail2ban关在门外。

配置上有条铁律：不要直接改 .conf结尾的默认配置文件，而是新建对应的 .local文件来覆盖，这样软件升级时你的配置不会被冲掉。fail2ban的jail配置、各参数的含义和常见服务的规则，Arch Linux Wiki整理得非常清楚Arch Linux Wiki — Fail2ban（jail配置、maxretry、findtime、bantime参数详解），配置前可以对着它逐项理解再动手。

fail2ban跑起来后，也别装完就不管。日常可以用它自带的状态命令看看某个jail当前封了哪些IP、一共拦截了多少次，对服务器正在承受多大强度的爆破心里有个数。对那些反复被封、解封后又来的惯犯IP，fail2ban还支持递增封禁——封禁时长随重犯次数逐步拉长，甚至专门设一条统计长期累犯的规则把它们长时间关死。把这些用起来，fail2ban才从一套静态规则变成会越拦越狠的主动防线。

要提醒的是，fail2ban是补充而非替代。它的逻辑是事后封禁，依赖攻击者多次失败触发规则，而且老练的攻击者会用大量不同IP轮换、让每个IP都不够触发阈值。所以它永远只是叠加在密钥登录之上的一层，绝不能因为装了它就觉得可以省掉密钥、留着密码登录——那是捡芝麻丢西瓜。

除了SSH，还有哪些登录面要一起收紧？

SSH焊死了，但服务器对外暴露的登录面往往不止SSH一个。只堵了最大那个口，别的口子敞着，照样可能出事。

第一个要收紧的是防火墙——只开该开的端口。一台服务器上跑着各种服务，但真正需要对公网开放的端口其实很少，通常就是网站的80、443和SSH那个端口。其余的，比如数据库端口、各种管理后台端口、缓存服务端口，绝大多数根本不该暴露在公网，只需要本机或内网访问。用防火墙（ufw、firewalld或云厂商的安全组）把不该开的端口全关掉，是减少攻击面最直接有效的一招。保哥见过太多事故，根子就在数据库端口图方便对公网开着、还用了弱口令，被人直接连进去拖库。

第二个是各种应用层的登录后台。网站的管理后台、数据库管理工具、服务器面板，这些带登录框的地方，本质上都是登录面。它们同样要用强口令、最好限制只有特定IP能访问、能开两步验证就开。这些虽然超出了SSH本身，但属于同一个登录加固的整体思路——凡是能登录进来的入口，都要设防。

对安全要求更高的场景，SSH本身也能再叠一层两步验证——在密钥之外，登录时还要再输入一个手机上动态生成的一次性验证码。这样即便私钥不慎泄漏，攻击者没有你手机上那个动态码也进不来，相当于又上了一把锁。它会让自己登录稍微麻烦一点，要不要上取决于这台服务器上数据的敏感程度，对存着大量客户数据、支付信息的机器，这一层额外的麻烦通常很值。

第三个是把没用的账户和服务清理掉。系统里那些不用的、默认创建的、或者历史遗留的账户，要么禁用要么删除，别给攻击者留可乘之机；不用的服务也关掉、不监听就不暴露。账户越少、暴露的服务越少，能被攻击的面就越小。登录加固的本质，就是把所有能进来的门都数清楚、该锁的锁、该拆的拆。

怎么发现有人正在爆破，登录审计该看哪些地方？

加固做完不等于一劳永逸，还得有眼睛盯着——知道有没有人在试、试得凶不凶、有没有谁居然登进来过。这就是登录审计要干的事。

看登录情况，有几个手边就能用的工具。认证日志是核心——Linux的认证相关日志（在Debian/Ubuntu系一般是 /var/log/auth.log，在RHEL系是 /var/log/secure）记录了所有登录尝试，成功的失败的都在，翻它就能看到谁在什么时候从哪个IP试图登录、成没成功。失败尝试如果密密麻麻、来自天南海北的IP，那就是正在被爆破的典型景象（装了fail2ban的话这些大多已经被自动封了）。

还有两个命令很顺手：last 能列出最近成功登录的记录，让你一眼看清都有谁、从哪登进来过——如果看到陌生的IP或时间登录成功，那就要高度警觉了；lastb 则专门列失败的登录尝试，是观察爆破强度的好帮手。日常扫一眼这些，对服务器的登录态势就心里有数。

更进一步，是把这种盯梢自动化、常态化。手动隔三差五翻日志容易漏，更好的做法是把登录失败激增、出现陌生成功登录这类信号接入监控告警，异常了主动推送给你，而不是等出了事再去翻日志。这就和服务器整体的日志管理与告警体系连上了，保哥在 Linux服务器日志管理那篇里专门讲了日志怎么收、怎么轮转、怎么从被动查变主动告警，登录审计正是其中安全相关的一块，把它纳入统一的日志告警里最省心。

另外提一句，如果发现服务器莫名其妙变慢、负载飙高，除了排查业务本身，也要警惕是不是已经被攻进去、被植入了挖矿程序或被当成跳板在跑别的东西——异常的资源占用有时就是入侵的尾巴。这种情况下怎么从负载、进程、网络去定位，保哥在 Linux服务器高负载排查那篇里有系统的方法，安全和性能排查这时候是连在一起看的。

服务器登录加固的落地顺序和最容易踩的5个坑是什么？

道理讲完，落地按什么顺序来最稳妥？保哥把一台新服务器的登录加固整理成一条不会把自己锁在门外的路径。

顺序上，先配密钥、验证能登、再关密码、然后禁root、建普通用户配sudo、装fail2ban、最后收紧防火墙并接上审计。第一步在本地生成密钥、把公钥传上服务器；第二步另开窗口用密钥实际登录成功一次，确认无误；第三步才改sshd_config关闭密码登录、禁用root直接登录并重载服务。

第四步建好日常用的普通运维用户、配好sudo最小权限；第五步装上fail2ban配好sshd的jail并把自己IP加白名单；第六步用防火墙关掉一切不该对公网开放的端口；最后把登录审计接进日常监控。

每一步都建立在前一步验证成功的基础上，尤其密钥不验证不关密码这条，是整条路径的安全绳。

再说5个最容易踩的坑：

坑一：没验证密钥就关了密码登录，把自己锁在门外。头号惨案——配完密钥没实际登录验证，就急着关密码、断开会话，结果新方式连不上、旧方式已关闭，只能去找云厂商的救援控制台。关密码前必须另开窗口验证密钥能登。

坑二：以为站小没人攻，干脆不设防。自动化扫描器不挑目标，任何公网服务器开机就被扫。抱侥幸心理用root加弱口令裸奔，是被攻破的最常见原因。

坑三：把改端口当成了主要防线。改SSH端口只能挡无脑扫描、减少噪音，认真的攻击者扫全端口照样找到。把它当核心措施、放松了密钥和fail2ban，等于没设防。

坑四：fail2ban没把自己IP加白名单。配好封禁规则却忘了ignoreip，结果自己偶尔输错几次密码、或换了网络，反被自己的fail2ban关在门外，哭笑不得。

坑五：只焊SSH，数据库等端口却对公网敞着。SSH加固得固若金汤，数据库端口却图方便对公网开着还用弱口令，攻击者绕过SSH直接从这里进，前功尽弃。登录面要一起收紧。

把这条顺序和这5个坑当成一份开服清单，每台新服务器上线前过一遍。服务器登录加固说复杂不复杂，核心就是密钥登录、关密码、禁root、最小权限、防爆破、收端口这几板斧，花一两个小时就能做完，却能把绝大多数自动化攻击挡在门外，是性价比最高的安全投入。

但也要记住，加固降低的是被攻破的概率，不是把概率清零——纵深防御之外，还得有备份和恢复演练兜底，万一真出了事能快速还原。这层底气怎么建，保哥在 灾备恢复演练那篇里讲得很透，把登录加固和备份兜底配齐，服务器的安全才算有了完整的两条腿。安全不是一劳永逸的开关，而是把每一道门都焊好、再留一手退路的持续功夫。

常见问题解答

我的服务器又没什么人知道，也会被攻击吗？

一定会，而且攻击几乎是开机就来。这是很多人最大的误解——以为自己站小、没名气就没人惦记。事实是，互联网上有海量的自动化扫描器，全天候不间断地扫描整个公网IP段，挨个IP试SSH的常见端口、试root加常见弱口令，完全不挑目标。你的服务器一旦绑上公网IP，几分钟内就会进入这些扫描器的视野，登录日志里很快会堆满来自世界各地的尝试登录记录。这跟你有没有名气、站大站小毫无关系，纯粹是机器在批量碰运气。所以别抱侥幸心理，任何一台暴露在公网的服务器，都必须做基本的登录加固，这是底线不是选配。

密钥登录比密码登录到底强在哪，密码设复杂点不行吗？

核心区别在于能不能被在线暴力破解。密码登录的命门是：攻击者可以对着你的登录端口无限次地猜密码，再复杂的密码理论上也能被慢慢撞开，何况大多数人的密码并没那么复杂。而密钥登录用的是一对非对称密钥——公钥放服务器、私钥留在你自己手里，登录时靠密码学验证你持有私钥，攻击者手里没有那个私钥，再怎么猜都没用，因为它不是靠猜一个字符串，而是靠你拥有一个根本猜不出来的密钥文件。一个标准的SSH密钥，其强度远不是任何人类能记住的密码能比的。设复杂密码确实比弱口令强，但只要还开着密码登录这条路，暴破的大门就没关上；换成密钥登录加关闭密码登录，等于直接把这条路堵死了。这是登录加固里收益最大的一步。

改了SSH端口、禁了root，是不是就绝对安全了？

不是，这些只是降低风险，不是绝对安全，得分清各自的作用。改SSH端口的作用是减少噪音——把默认端口换成一个不常见的端口，能挡掉绝大多数只扫默认端口的无脑扫描器，让你的日志清净很多，但它属于隐藏而非加固，遇到认真扫全端口的攻击者照样能找到，所以改端口可以做但绝不能当成主要防线。禁用root直接登录是实打实的加固——root是人人都知道的超级管理员账户名，是暴破的头号目标，禁掉它、改用普通用户登录再提权，攻击者就得先猜中你的用户名再猜密钥，难度陡增。但即便这两样都做了，真正的地基仍然是密钥登录加关闭密码登录加fail2ban。安全是一层层叠加的纵深防御，没有任何单一措施能让你绝对安全，正确的心态是把每一层都做到位，让攻破的成本高到不值得。

关闭密码登录后，万一密钥丢了或者连不上，会不会把自己锁在门外？

这是关闭密码登录前最该担心、也最该提前防范的风险，处理好了就不可怕。关键原则是：永远先确认新的登录方式真能用，再关掉旧的。具体说，配好密钥登录后，一定要另开一个终端窗口、用密钥实际登录成功一次，确认万无一失，再去关闭密码登录，绝不能配完密钥没验证就急着关密码、然后退出当前会话。万一真被锁在外面，也还有后路：几乎所有云服务器厂商都提供网页版的控制台或VNC救援登录入口，它不走SSH，可以直接进系统改回配置；另外提前把私钥安全地备份到别的地方，换了电脑也能恢复。把这几条后路备好，关闭密码登录就是个安全操作，不必提心吊胆。

装了fail2ban是不是就不用关密码登录、不用配密钥了？

不能本末倒置，fail2ban是补充防线，不是替代品。fail2ban的作用是发现某个IP短时间内反复登录失败就临时封禁它，能有效拖慢、阻断暴力破解的节奏，是很有价值的一层。但它的逻辑是事后封禁，依赖攻击者多次失败触发规则，如果你还开着密码登录、口令又弱，理论上存在攻击者运气好在触发封禁前就猜中的可能；而且攻击者可以用大量不同IP轮流来，分散到每个IP都不够触发封禁阈值。所以正确的关系是：密钥登录加关闭密码登录是把门焊死的根本措施，让暴破从原理上无法成功；fail2ban是在这之上再加一道，封掉那些徒劳尝试的IP、减少日志噪音和资源消耗。两者叠加才是完整方案，绝不是有了fail2ban就可以省掉密钥这一步，那是捡了芝麻丢了西瓜。

权威参考资料