Linux SSH安全加固实战：从密钥认证到端口防护-代码聚汇网

Linux SSH安全加固实战：从密钥认证到端口防护

燕家猫·2026-08-29·阅读 23 GEO检测（免费）

SSH安全密钥认证端口防护

|难度：普通|阅读约 38 分钟

很多人刚接触Linux服务器管理时，第一步就是搞定SSH登录，但大部分人的配置还停留在"默认22端口+密码登录"的状态。直到我去翻一台线上服务器的认证日志，看到密密麻麻的Failed password记录，才发现SSH早就成了互联网上被扫射最密集的服务之一。这篇内容围绕Linux SSH安全展开，核心就两件事：把密钥认证用起来，把端口防护做实，顺带把加固过程中容易翻车的细节一起讲清楚。内容主要面向需要自己维护服务器的Linux运维、开发者和刚上手的自建服务玩家，能帮你把SSH从"能连就行"提升到"能用且扛打"的水平。

1. 互联网上真实的SSH安全威胁：不加固就是在裸奔

1.1 每时每刻都在发生的端口扫描与暴力尝试

如果你在一台有公网IP的Linux服务器上装了SSH服务，默认监听22端口，那么从接入公网的那一刻起，就可能一直有人在扫描你。这不是危言耸听，而是互联网背景噪声的一部分。扫描器会遍历大段IP地址，尝试连接常见的22端口，发现开放后就开始用内置字典尝试用户名和密码。这些扫描器大部分是自动化的，一天二十四小时不休息。

我随便截一段实际服务器上的/var/log/secure或/var/log/auth.log日志给大家感受一下：Failed password for root from 203.0.113.25 port 53924 ssh2，这类记录在未加固的服务器上非常常见，有时一晚上能刷出几百条。攻击者成功登入后通常会做几件事：下载挖矿程序、安装后门、清理日志、把机器变成肉鸡继续扫描其他主机。一台只有2核4G的小机器，中了挖矿木马之后CPU直接拉满，业务还没跑起来就先给别人打工了。

所以SSH安全的核心逻辑，就是把你系统的暴露面和被成功突破的概率同时降下去。密钥认证解决的是"密码可能被猜出来"的问题，端口防护解决的是"暴露在扫描器视野内"的问题。

1.2 密码认证的结构性弱点

很多人觉得只要把密码设复杂一点就安全了，但密码认证从机制上就有几个绕不开的坑：

第一，密码是可以通过网络传输的，哪怕SSH协议本身对传输做了加密，但服务器端必须验证你提交的密码。攻击者如果拿到了服务器上的密码哈希，或者通过网络中间人攻击截获了认证过程中的关键信息，就有机会离线破解或者直接重放。

第二，人类不擅长记随机字符串。一旦密码是"Sunshine2023!"这种带英语单词和生日的组合，字典里早就收录了变体。如果多个服务器用了同一个密码，一台泄露全线沦陷。

第三，暴力破解的成本太低了。攻击端可以同时用几万台机器组成的僵尸网络对一个IP发起分布式密码尝试，普通弱密码在几分钟内就会被试出来。即便你的密码强度够高，海量尝试也会产生大量垃圾日志、消耗服务器CPU和带宽资源。

密钥认证从根本上绕开了这些问题：服务器不验证"你知道什么"，而是验证"你是否持有某把私钥"。密码没有出现，字典攻击自然失效，中间人想要伪造认证也没法凭空生成一把私钥。

1.3 密钥认证的原理：你用数学证明了自己

SSH密钥认证使用的是公钥密码学中的非对称加密。简单来说，服务器上存放的是公钥，客户端保存的是私钥。登录时，服务器会发送一个质询（challenge），只有持有对应私钥的客户端才能正确回应这个质询，服务器验证通过后即完成认证。整个过程私钥永远不会通过网络传输，私钥也不离开客户端设备。

用生活化的例子来理解：公钥相当于一把"锁"，私钥是这把锁唯一的"钥匙"。你在服务器上安装公钥，等于在这台服务器的大门上加了一把锁，只有拿着匹配钥匙的客户端才能打开。攻击者哪怕复制走了公钥，也完全没有用，因为公钥只能用来验证，不能用来反推私钥。这种机制决定了密钥认证的安全下限，天然远高于密码认证。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 密钥认证的完整落地：从生成密钥到彻底关掉密码登录

2.1 生成密钥对时的参数选择：ed25519还是RSA

在客户端上生成密钥对，理论上很简单，一条ssh-keygen命令就够。但很多人在参数选择上容易踩坑。目前推荐的算法是ed25519，密钥短、性能好、安全性足够强，而且生成的公钥格式简洁。如果你的客户端或服务器环境太老（比如CentOS 6），才考虑RSA并加大位数。

生成命令示例：

bash复制ssh-keygen -t ed25519 -C "your-name@your-server" -f ~/.ssh/id_ed25519

-C是注释，建议写上你的身份标识，方便以后管理多台服务器时知道哪个密钥是谁的。-f指定生成路径和文件名，默认是~/.ssh/id_ed25519。执行过程中会提示你是否设置passphrase（私钥口令），这里建议不要留空。

设置passphrase相当于给私钥再加一道保险。即使私钥文件泄露，没有passphrase，攻击者也没法直接用。有些人嫌麻烦干脆不设，我觉得至少你的主力开发机和工作笔记本要设置一下，配合ssh-agent可以做到只在首次使用时输入一次。

如果你确实需要兼容老环境，生成RSA版本：

bash复制ssh-keygen -t rsa -b 4096 -C "your-name@your-server" -f ~/.ssh/id_rsa

两种算法在后续使用上没有区别，公钥都是追加到服务器的authorized_keys里，私钥都留在客户端。

2.2 公钥分发的标准姿势：ssh-copy-id与手动权限设置

生成密钥对之后，你需要把公钥内容放到服务器的~/.ssh/authorized_keys文件中。最省事的方法是使用ssh-copy-id命令，它会把本地的公钥自动追加到远程服务器的正确位置，并设置好权限：

bash复制ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server-ip

它会提示你输入一次用户密码，这是整个过程中最后一次使用密码。之后该用户就能通过密钥直接登录了。

如果你遇到ssh-copy-id不可用的场景（比如有些精简版系统没装这个命令），可以手动完成。原理是三步：在服务器上创建.ssh目录、追加公钥到authorized_keys、设置正确权限。

bash复制# 在服务器上执行（或者通过单次密码登录后执行）
mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "公钥内容" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

权限设置非常关键。SSH服务端对authorized_keys文件、.ssh目录以及用户主目录的权限有严格检查，权限过宽会被安全策略直接拒绝。.ssh目录必须是700，authorized_keys文件必须是600，主目录不能对组和其他用户可写。

2.3 sshd_config核心参数修改：让服务器只认密钥

公钥分发好之后，先别急着操作。你需要修改服务器端SSH配置，启用密钥登录并禁用密码登录。配置文件路径是/etc/ssh/sshd_config，修改前建议先备份一份。

bash复制sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo vim /etc/ssh/sshd_config

重点看这几个参数：

ini复制PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

PubkeyAuthentication yes确保服务端允许公钥认证。PasswordAuthentication no是关闭密码认证，ChallengeResponseAuthentication no和UsePAM no是为了避免某些系统默认的PAM模块绕过密码禁用策略。实际环境中UsePAM是否关闭要根据你的系统情况来定，有些发行版本关闭UsePAM后反而会影响键盘交互认证，所以在部分系统上保持UsePAM yes并把KbdInteractiveAuthentication no关掉效果更一致。修改完先做语法检查：

bash复制sudo sshd -t

必须确认没有输出任何错误信息。语法检查通过后，再选择合适时机重载服务。为什么要强调这个顺序？因为如果配置写错了就直接重启SSH服务，连接一断，你可能就再也连不上了。

2.4 私钥的保存纪律与日常使用技巧

服务端配置完成后，你日常使用的客户端要养成几个好习惯：

第一，私钥文件本身的权限必须是600或更严格。在Linux/macOS上执行chmod 600 ~/.ssh/id_ed25519，如果权限过宽，SSH客户端会直接拒绝使用这把私钥。

第二，设置了passphrase后，配合ssh-agent可以省去重复输入。在本地执行：

bash复制eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

之后在同一个会话内连接多台服务器都不用再次输入passphrase。

第三，不要把私钥随便同步到网盘、代码仓库或者聊天工具里。私钥就是你的钥匙，丢了钥匙换把锁没关系，怕的是你根本不知道钥匙什么时候丢的。如果在GitHub或其他地方不小心提交过私钥，立即删除对应账号在服务器上的公钥条目，并重新生成密钥对。

3. 修改SSH端口：前置准备比改端口本身更重要

3.1 改端口这件事急不得：先想好怎么回来

把SSH默认端口从22改成其他高位端口，是降低被扫描概率的有效手段，但前提是你得保证自己能连回来。我见过太多人改完端口忘了放防火墙规则，然后自己被锁在服务器外面，只能让机房或者云平台的管理员帮忙恢复。所以，动手之前先做三件事：

第一，确认自己有备用登录途径。云服务器有VNC/管理终端，物理服务器有IPMI或本地控制台，先确认这些通道是通的。第二，确认当前服务器的防火墙状态。不管是ufw、firewalld还是iptables，要知道新端口该在哪里放行。第三，准备一个"回滚方案"。最稳妥的思路是先在配置文件里同时监听22和新端口，测试新端口能登录后，再回头关闭22端口。

这种"双端口过渡"策略是我一直推荐的做法：在sshd_config中写两行Port参数：

ini复制Port 22
Port 23456

重载SSH服务后，两个端口同时生效。先连一下23456，确认密钥认证正常工作、权限没问题，再把Port 22那行去掉，再次重载，才算真正完成端口切换。

3.2 端口号的挑选思路：别用太容易被猜中的

改端口不是随便改个数字就完事。很多人喜欢用2222、22222这种一眼就能看出来的替代品，扫描器对这类端口同样有命中列表。更合理的做法是选一个不常用、且不容易和系统已用端口冲突的高位端口号。比如3306是MySQL、6379是Redis，这些有明确用途的端口不能碰。我习惯在49152到65535的动态端口区间里挑一个没被占用的号码，这样既不会和常见服务冲突，也不会出现在扫描器的默认字典顶层。

在服务器上检查端口占用情况：

bash复制sudo ss -tlnp | grep 23456

如果没有任何输出，说明端口是空闲的。同时在云平台的安全组规则里放行新端口，这个步骤很多人容易遗漏，因为云服务器有双层防火墙：云平台安全组和系统内部防火墙，两层都要放行。

3.3 防火墙联动放行：ufw和firewalld的配置示例

Ubuntu/Debian系统默认使用ufw，添加放行规则的命令很简单：

bash复制sudo ufw allow 23456/tcp
sudo ufw reload

CentOS/RHEL 7及以上使用firewalld：

bash复制sudo firewall-cmd --permanent --add-port=23456/tcp
sudo firewall-cmd --reload

如果是裸的iptables：

bash复制sudo iptables -A INPUT -p tcp --dport 23456 -j ACCEPT
sudo service iptables save

注意iptables规则重启后需要持久化保存，否则服务器一重启规则就丢了。

放行完成之后，务必从客户端测试新端口连通性：

bash复制ssh -p 23456 user@your-server-ip

确认能正常登录后，再回头清理22端口的监听和放行规则。整个过程的原则就是"先开新路，再关旧路"。

3.4 SELinux和AppArmor对非标准端口的限制

这是改端口时最容易被忽视的暗坑。CentOS/RHEL系列默认开了SELinux，而SELinux对SSH服务监听的端口类型有明确限制，默认只放行22端口对应的ssh_port_t标签。如果你直接改了Port为23456，却没有更新SELinux端口类型配置，重启sshd后服务可能根本起不来，或者端口无法正常监听。

需要执行：

bash复制sudo semanage port -a -t ssh_port_t -p tcp 23456
sudo semanage port -l | grep ssh

确认新端口出现在列表里。有些最小化安装的系统没有semanage命令，需要装一下：

bash复制sudo yum install policycoreutils-python-utils
# 或者
sudo dnf install policycoreutils-python-utils

Ubuntu/Debian上如果开了AppArmor，影响通常没有SELinux那么直接，但如果你遇到了改端口后服务状态异常，也要检查一下AppArmor对sshd的配置策略。

4. 加固组合拳：把SSH服务从"能用"调到"扛打"

4.1 禁用root直接登录：权限下沉到普通用户

服务器的root账户是攻击者最想拿下的目标，因为root权限太大了。SSH直接放行root登录，等于把一把万能钥匙挂在门口。合理的做法是关闭root的SSH登录，日常运维使用一个普通用户登录，需要提权时再用sudo。

在sshd_config中设置：

ini复制PermitRootLogin no

有些人会设置成prohibit-password，意思是禁止root密码登录但允许root密钥登录。我的建议是如果业务确实需要root直连（比如自动化运维脚本），可以用prohibit-password加严格限制；对一般场景，直接no更干净。

配套的操作是确保普通用户有sudo权限：

bash复制sudo usermod -aG wheel your-user   # CentOS/RHEL
sudo usermod -aG sudo your-user    # Ubuntu/Debian

注意不要把sudo权限给得太随意，能sudo的用户等于半个root，人员流动时要及时清理。

4.2 登录白名单：AllowUsers和AllowGroups精准管控

不管服务器上有多少个系统用户，SSH登录入口只开放给你指定的人。sshd_config中支持白名单配置：

ini复制AllowUsers user1 user2 admin@192.168.1.0/24
AllowGroups sshusers

第一条AllowUsers限制的是允许登录的用户列表，可以带来源IP限制，比如只允许某个IP段的用户登录。第二条AllowGroups限制的是用户组，如果用户较多，建议统一放到一个组里管理。

这里有个细节容易被忽略：AllowUsers和AllowGroups是同时生效的，只要写了一项，不在白名单里的用户就会被拒绝。配置后所有SSH登录尝试都会经过这个过滤，日志里会出现User xxx from xxx not allowed because not listed in AllowUsers的记录，这比密码暴力破解那种日志干净多了。

再加一个限制条件会更稳：只允许密钥认证，禁止密码认证。两者一结合，暴力破解基本没有操作空间。

4.3 登录失败惩罚：fail2ban的正确打开方式

密钥认证+关闭密码+修改端口这三板斧过后，SSH安全等级已经很高了。但如果你想更进一步，或者服务器需要开放给外部用户密码登录，就必须上fail2ban这种失败惩罚机制。

fail2ban的逻辑很简单：监控SSH的认证日志，在单位时间内发现多次认证失败，就把来源IP加入防火墙黑名单，在设定时间内拒绝其所有连接。安装配置过程：

bash复制sudo apt install fail2ban   # Ubuntu/Debian
sudo yum install fail2ban   # CentOS/RHEL

主配置文件是/etc/fail2ban/jail.conf，但一般不建议直接改这个文件，而是在/etc/fail2ban/jail.local里覆盖配置：

ini复制[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600

maxretry是最大失败次数，bantime是封禁时长（秒），findtime是统计时间窗口。我一般设maxretry=3、bantime=3600，既拦得住扫描器，又不会因为手滑输错密码就把自己封太久。

启动：

bash复制sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

status输出能看到当年封了哪些IP，也是一份不错的威胁情报。注意fail2ban依赖日志路径，不同发行版路径不一样，Ubuntu是/var/log/auth.log，CentOS是/var/log/secure，配错了就监测不到任何东西。

4.4 算法与超时参数收紧：减少没必要暴露的面

SSH服务本身暴露给外部的东西越少越好。sshd_config里还有几个值得一并调整的参数：

ini复制LoginGraceTime 30
MaxAuthTries 3
MaxSessions 10
ClientAliveInterval 300
ClientAliveCountMax 0

LoginGraceTime 30限制客户端必须在30秒内完成认证，超时自动断开。MaxAuthTries 3限制单次连接最多尝试3次认证，攻击者想在同一连接里连续试密码也试不了几次。ClientAliveInterval和ClientAliveCountMax配合使用，检测失效连接，防止大量僵尸SSH会话堆积。我自己会把ClientAliveInterval 300加上，长时间空闲的连接会收到服务端的保活探针，如果客户端失去响应就把它断开，资源占用会好看很多。

关于加密算法，比较新的Linux发行版默认配置已经足够安全，一般不需要专门调整。除非你的服务器比较老，否则不建议动KexAlgorithms、Ciphers、MACs这些参数，改得不好可能反而导致某些老客户端连不上。

4.5 加固后的定期体检：快速检查配置是否一直有效

加固不是一个一次性的动作，过了半年、一年，系统升级、配置漂移、新加用户，都可能让原来的安全策略失效。所以养成定期体检的习惯很重要。最直接的检查命令：

bash复制sudo sshd -T

sshd -T会输出当前实际生效的SSH配置，包括从配置文件读取到的所有参数和系统默认值。想快速确认几个关键项：

bash复制sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin|port'

正常状态下应该看到passwordauthentication no、permitrootlogin no、port 23456这些结果。另外别忘了经常翻翻认证日志，看有没有异常尝试：

bash复制sudo journalctl -u sshd --since today
# 或者
sudo grep 'Failed password' /var/log/auth.log

有异常记录不要慌，先分析IP来源和尝试规律，再针对性调整fail2ban策略或防火墙规则。

5. 加固过程中最容易翻车的几个瞬间与自救手段

5.1 改完配置连不上：第一反应别慌，先理清链路

SSH加固操作中，最常见的翻车场景就是改完配置重载服务后，当前连接直接被断开，然后怎么都连不上了。遇到这种状况，第一件事是别慌，更别在云控制台里重启服务器，因为重启可能让问题更复杂（比如防火墙规则被重置、SELinux策略未生效）。要按链路一步步排查：

客户端提示连接超时，优先检查云安全组和系统防火墙是否放行了新端口。客户端提示Connection refused，说明端口本身没监听，检查sshd状态和SELinux端口类型。客户端提示Permission denied，则说明认证环节有问题，可能是密钥分发不对、权限设置不当，或密码登录被关导致无法回退。

这就是为什么我一直强调"双端口过渡"策略的重要性。如果你按这个策略操作，最坏的情况也只是新端口连不上，老端口还在，可以立刻回滚配置。省掉这个过渡步骤，等于把自己逼到了悬崖边上。

5.2 公钥配置了却仍然提示no more authentication methods

这是密钥认证落地时高频出现的报错，完整提示类似no more authentication methods available或Permission denied (publickey)。原因通常是服务器端已经关闭了密码认证，但客户端提交的公钥没有被服务器接受。

排查思路按顺序来：

首先在服务器上确认公钥内容确实在authorized_keys里，并且用户对应用户目录权限正确。很多问题是root执行了ssh-copy-id，把公钥放到了/root/.ssh/authorized_keys，但你用普通用户登录，自然不匹配。

其次检查sshd的实际配置文件，确认AuthorizedKeysFile有没有被改成非默认路径。有些加固脚本会把AuthorizedKeysFile指向/etc/ssh/authorized_keys/%u这样的公共目录，如果你没有同步创建对应文件，就永远验证不通过。

最后，在服务器端用调试模式临时跑一个SSH进程观察日志，是最快的定位方式：

bash复制sudo /usr/sbin/sshd -d -p 2222

这个命令会在前台启动一个SSH服务，监听2222端口，并把详细的认证日志输出到终端。客户端连这个测试端口，服务端会直接打印出"拒绝公钥""权限错误"等具体原因，比自己瞎猜快得多。调试完直接Ctrl+C杀掉测试进程即可。

5.3 Windows客户端常见的.ssh目录缺失问题

很多Windows用户第一次使用SSH密钥登录时，会遇到这么一条报错：could not create directory '/c/users/xxx/.ssh'。这不是服务器配置的问题，而是Windows上的OpenSSH客户端找不到也创建不了.ssh目录。

解决方法是手动创建用户主目录下的.ssh文件夹：

powershell复制mkdir $HOME\.ssh

如果是在Git Bash或WSL环境里，路径可能显示为/c/users/xxx/.ssh，那么在Windows资源管理器里直接创建C:\Users\xxx\.ssh目录也可以。创建完成后，把私钥文件放进去，或者用ssh-keygen重新生成密钥。Windows的OpenSSH客户端对目录权限的要求有时比较苛刻，如果提示私钥权限不安全（UNPROTECTED PRIVATE KEY FILE），需要右键私钥文件进入属性、安全、高级，给当前用户完全控制权限并删除其他用户的权限条目。

5.4 从最坏的情况里爬出来：控制台、VNC和临时端口

万一你确实把自己锁在门外了，也别急着重装系统。云服务器基本都提供VNC/管理终端这种脱离网络的操作界面，通过浏览器就能像坐在机房显示器前一样操作Linux的命令行。如果你改配置之前没有在这种控制台模式下确认能登录，现在就等于多了一条救命通道。

登录控制台后，把sshd_config里的错误修改还原或改成安全状态，再重启sshd就恢复了。物理服务器如果没有配置IPMI，也可以联系机房管理员协助，但沟通成本和响应时间都不可控，所以再次强调：改SSH配置前，先写好回滚预案。

我还习惯在配置目录里留一个带日期后缀的备份文件：sshd_config.bak-2024-12-01。以后无论哪次修改出问题，都能迅速找到上一次的可用版本。

5.5 加固完成后的最后兜底：别把所有鸡蛋放一个篮子里

密钥认证、关闭密码、修改端口、白名单、fail2ban，这一套东西下来，SSH的安全等级会有质的提升。但我想提醒一点：SSH安全是服务器安全的一部分，不是全部。就算你SSH做得再严，如果服务器上的Web应用有漏洞、Redis没设密码、防火墙封了SSH却放开了成千上万个其他服务，攻击者一样可以从别的路进来。

所以务实的做法是把这套SSH加固当成基础操作，而不是终极方案。对重要的服务器，开启系统自动安全更新，定期备份数据，日志集中收集，有条件的上入侵检测系统。SSH这扇门关紧了，只是让攻击者少了一条最顺手的路。

6. 给新手的实操建议：按这个顺序动手最稳

根据我踩坑的经验，如果你要给一台全新的Linux服务器做SSH加固，最稳妥的操作顺序是：先建普通用户并加入sudo组，用普通用户登录并配置好密钥认证，确认密钥登录可用后再关闭密码认证，然后改端口，最后配置白名单和fail2ban。每一步完成后都实际测试一遍，确认无误再进行下一步。

我把一套最小安全的配置清单整理在这里，可以对照检查：

配置项	推荐值	说明
PermitRootLogin	no	禁止root直连SSH
PasswordAuthentication	no	禁止密码登录
PubkeyAuthentication	yes	启用密钥认证
Port	高位随机端口	避开22和常见替代端口
AllowUsers	白名单用户	只允许指定用户登录
MaxAuthTries	3	限制认证尝试次数
LoginGraceTime	30	限制认证超时

顺带分享一个我操作时的小习惯：每次改完sshd_config，先执行sshd -t验证语法，再执行sshd -T确认实际生效参数，最后才重载服务。重载之后不关当前连接，另开一个终端测试新配置，确认没问题再断开旧连接。这套"先验证后切换"的思路，让我在多次服务器加固过程中都全身而退。SSH安全说难不难，说简单也不简单，核心在于耐心和细节，一个个参数验证过去，基本就不会出大问题。