嘿，朋友。如果你现在正盯着屏幕上那个熟悉的 CentOS 6 登录提示符发呆，或者正准备给一台老旧的服务器做最后一次远程维护，那你来对地方了。我知道，CentOS 6 就像是你家里那台用了十年的老冰箱，虽然还能制冷，但电费贵、噪音大，而且厂家早就停止维修了。2020 年 11 月 30 日，Red Hat 正式结束了对 CentOS 6 的生命周期支持（EOL）。这意味着什么？意味着如果有人发现了这个系统的漏洞，不会再有补丁发布。这就好比你住在一个没有锁的房子里，而且还在朋友圈发定位。
不过，生活有时候就是这样，旧系统还在跑，新系统没就绪，我们得在“危险”中求生存。今天我不给你念那些枯燥的红头文件，咱们聊聊怎么在这台“老伙计”上，把远程连接、SSH 安全配置、防火墙（iptables）以及权限管理这几件事儿做扎实。就算它终将退役，在它退休前的每一天，我们都得让它走得安稳、走得体面。
别让 root 裸奔：SSH 配置的“第一道防线”
很多人（包括我早期的自己）有个习惯，登录服务器直接 ssh root@192.168.1.100，密码一输，进去了。爽吗？爽。危险吗？非常危险。
SSH（Secure Shell）是我们在 Linux 世界里远程操控服务器的主要通道。默认情况下，CentOS 6 的 SSH 配置相当宽松。我们要做的第一件事，就是给这扇门加把更可靠的锁。
修改 SSH 配置文件
SSH 的主配置文件位于 /etc/ssh/sshd_config。在修改之前，请务必保留一个活跃的终端窗口，别把自己锁在外面——除非你想亲自跑到机房去插键盘，那体验并不好。
打开终端，执行编辑命令：
sudo vi /etc/ssh/sshd_config
我们要修改几个关键参数。别急，我一个个解释，就像教小朋友搭积木一样，每一块都有它的用处。
禁止 Root 直接登录
这是最重要的一条。攻击者扫描到端口后，首先尝试的就是
root用户。如果直接禁止 root 登录，他们就少了一半的攻击机会。找到这一行（可能被注释掉了，前面有个
#）：#PermitRootLogin yes把它改成：
PermitRootLogin no小贴士：一定要确保你已经创建了一个具有 sudo 权限的普通用户，否则改完这条你就真的进不去了。
更改默认端口（可选，但推荐）
默认端口是 22。全世界的扫描器都在盯着 22 端口。把端口改掉，就像把门牌号换掉，能过滤掉 99% 的自动化扫描攻击。
找到：
Port 22改成：
Port 2222注意：如果你改了端口，以后连接的时候就得指定端口了，比如
ssh -p 2222 user@ip。启用密钥登录，禁用密码登录
密码再复杂，也怕暴力破解。SSH 密钥对（公钥+私钥）的安全性远高于密码。我们可以强制要求使用密钥登录，彻底关闭密码验证。
找到并修改：
PasswordAuthentication no PubkeyAuthentication yes这一步需要你在本地机器生成密钥对，并把公钥拷贝到服务器的
~/.ssh/authorized_keys文件中。如果你还没准备好这一步，可以先只开启PubkeyAuthentication yes，保留PasswordAuthentication yes作为备用，但强烈建议尽快迁移到密钥登录。设置空闲超时断开
防止你忘记退出终端，让黑客趁虚而入。
在文件末尾添加：
ClientAliveInterval 300 ClientAliveCountMax 2这意味着每 300 秒（5 分钟）服务器会向客户端发送一个心跳包，如果客户端没响应，发两次后就断开连接。
重启 SSH 服务
修改完配置，记得重启服务让配置生效：
sudo service sshd restart
如果一切顺利，你应该能用普通用户登录了。这时候，千万不要急着关那个能登录 root 的旧终端，先用新窗口测试一下新的 SSH 配置是否通畅。
给院子砌墙：iptables 防火墙的精准控制
CentOS 6 用的是 iptables 作为防火墙工具，而不是后来 Centos 7+ 的 firewalld。很多新手看到 iptables 的一堆命令就头疼，其实它的逻辑很简单：规则是顺序匹配的，一旦匹配就执行动作，后面的规则就不看了。
我们的目标是：只允许必要的端口被访问，其他全部拒绝。
查看当前规则
先看看现在的房子有哪些窗户开着：
sudo iptables -L -n -v
清理旧规则，从零开始
为了安全，我们建议先清空规则（注意：这会立即断开所有当前连接，所以请在控制台或确保有带外管理权限的情况下操作）：
sudo iptables -F
sudo iptables -X
sudo iptables -Z
设置默认策略：只进不出？不，是只进该进的
默认策略是 ACCEPT（允许），我们要改成 DROP（丢弃），这样没人能访问任何端口，除非我们显式放行。
# 默认拒绝所有入站连接
sudo iptables -P INPUT DROP
# 允许本地回环接口（lo）的通信，这是系统内部进程通信所必需的
sudo iptables -A INPUT -i lo -j ACCEPT
# 允许已建立或相关联的通信（比如你刚 SSH 连进来，回来的数据包必须允许）
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
开放必要的端口
假设我们之前把 SSH 改到了 2222 端口，并且需要开放 80（HTTP）和 443（HTTPS）。
# 允许 SSH (2222端口)
sudo iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
# 允许 HTTP (80端口)
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# 允许 HTTPS (443端口)
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
保存规则
iptables 的规则是临时的，重启后会丢失。CentOS 6 提供了命令来保存：
sudo service iptables save
这会将规则保存到 /etc/sysconfig/iptables 文件中。
常见错误排查
如果你在配置防火墙后发现自己连不上了，不要慌，通常有以下几个原因：
- 忘了放行 SSH 端口：这是最常见的。如果你改动了 SSH 端口，却在 iptables 中只放了 22，那肯定连不上。检查规则时，用
sudo iptables -L INPUT -n --line-numbers看清楚放行了哪些端口。 - 默认策略设成了 DROP，但没放行 ESTABLISHED：如果你只设了
INPUT DROP，没有允许已建立连接的数据包回传，那么即使你刚才连进去了，数据包也回不来，连接会瞬间断开。记得加那条-m state --state ESTABLISHED,RELATED的规则。 - 云服务器的安全组：如果你用的是 AWS、阿里云、腾讯云等云服务器，iptables 只是内网第一道防线。云平台本身还有一层“安全组”或“防火墙”设置。你需要同时在云控制台上放行对应的端口，否则外层流量根本到不了你的服务器。
权限的最小化：sudo 用户的艺术
既然我们不能直接用 root 登录，那普通用户怎么执行需要管理员权限的命令呢？答案就是 sudo。
创建新用户并赋予权限
假设我们要创建一个名为 admin 的用户：
sudo useradd admin
sudo passwd admin
接下来，我们需要让 admin 拥有 sudo 权限。在 CentOS 6 中，通常通过编辑 /etc/sudoers 文件来实现，但强烈建议使用 visudo 命令，因为它会检查语法错误，防止你改坏了文件导致所有人都无法 sudo。
sudo visudo
找到这一行：
root ALL=(ALL) ALL
在下面添加：
admin ALL=(ALL) ALL
这就意味着 admin 用户可以执行任何命令，但每次执行前都需要输入自己的密码。
更安全的做法：限制 sudo 范围
“ALL=(ALL) ALL” 有点太粗暴了。如果 admin 用户不小心（或者被恶意利用）执行了 rm -rf /，那后果不堪设想。更安全的做法是，只允许 admin 执行特定的命令。
比如，我们只允许 admin 重启服务和查看日志：
admin ALL=(ALL) /sbin/service, /usr/bin/tail, /usr/bin/cat
这样，即使密码泄露，攻击者能做的手脚也有限得多。当然，对于管理员来说，这可能会比较麻烦，需要根据实际工作需求来平衡安全性和便利性。
文件权限的基本功
除了命令权限，文件本身的权限也要管好。CentOS 6 遵循标准的 Unix 权限模型：读（r）、写（w）、执行（x）。
用 ls -l 查看文件权限：
-rw-r--r--. 1 root root 4096 Nov 10 10:00 config.txt
第一列的 -rw-r--r-- 就是权限。
root用户可以读写。root组用户可以读。- 其他人只能读。
确保敏感文件（如 SSH 密钥、配置文件）权限正确：
# 设置 SSH 私钥权限为 600，只有所有者可读写
chmod 600 ~/.ssh/id_rsa
# 设置公钥权限为 644
chmod 644 ~/.ssh/id_rsa.pub
# 设置 .ssh 目录权限为 700
chmod 700 ~/.ssh
如果权限太开放，OpenSSH 会拒绝使用这些密钥，导致登录失败。这也是常见的报错来源之一。
应对“连不上去”的急诊室
在实际操作中，远程连接出问题是最让人头大的。以下是对策清单：
报错 1：Connection refused
原因：目标端口没有服务在监听，或者防火墙直接拒绝了连接。 排查：
- 检查 SSH 服务是否运行：
sudo service sshd status - 检查监听端口：
sudo netstat -tlnp | grep sshd - 检查 iptables 规则：
sudo iptables -L -n | grep 2222（假设你改成了 2222） - 检查云服务商的安全组设置。
报错 2：Permission denied (publickey,password)
原因：认证失败。 排查：
- 确认用户名和密码是否正确（注意大小写）。
- 如果使用密钥登录，检查
~/.ssh/authorized_keys文件是否存在，权限是否正确（应为 600），公钥内容是否完整。 - 检查
/etc/ssh/sshd_config中的PubkeyAuthentication yes和PasswordAuthentication设置是否与你的登录方式匹配。 - 查看 SSH 服务端日志获取更详细的错误信息：
sudo tail -f /var/log/secure。在另一个终端尝试登录，观察这个日志的实时变化，通常会有非常明确的报错原因。
报错 3：Too many authentication failures
原因：短时间内多次认证失败，SSH 服务可能触发了 fail2ban 或者 iptables 的 drop 规则，暂时封禁了你的 IP。 排查：
- 等待几分钟再试。
- 检查 iptables 是否有针对 SSH 的速率限制规则：
sudo iptables -L INPUT -n -v | grep 2222 - 如果使用了 fail2ban，检查其状态：
sudo service fail2ban status。
报错 4：Host key verification failed
原因：服务器的 SSH 主机密钥发生了变化，可能是系统重装后，或者你正在使用跳板机/代理，导致本地 known_hosts 文件中的记录与新服务器不匹配。
排查：
- 删除本地
~/.ssh/known_hosts文件中对应的服务器条目。 - 重新连接，接受新的主机密钥。
写在最后：升级是唯一的出路
朋友，我们花了这么多篇幅来讲 CentOS 6 的安全配置，但这并不是在鼓励你长期停留在这个系统上。恰恰相反，这些配置的目的，是在你完成迁移之前，为这台老机器穿上最后的“防弹衣”。
CentOS 6 的内核版本、软件仓库、依赖库都已经严重过时。许多现代软件（如新版 Docker、Node.js、Python 等）已经不再支持 CentOS 6。继续使用它，就像是在一辆没有安全气囊、刹车失灵的老车上跑高速公路，风险是不可控的。
你的下一步行动应该是：
- 评估业务依赖：列出所有运行在 CentOS 6 上的应用，确认它们在 CentOS 7 或 CentOS Stream 8⁄9 上的兼容性。
- 备份数据：无论是系统状态还是数据文件，务必在迁移前进行完整备份。
- 制定迁移计划：考虑使用 Packer、Ansible 等工具自动化构建新环境，或者逐步灰度迁移。
- 立即行动：不要等到下一个漏洞爆发，或者业务高峰期出问题，才想起来要迁移。
CentOS 6 是一个时代的结束，但技术总是在向前发展的。做好这些最后的守护，然后，勇敢地迈向更安全的未来吧。如果在迁移过程中遇到任何具体问题时，欢迎随时再来找我聊聊。