最基础的生成命令 - 易云城IT服务

theme: default themeName: "默认主题" title: "服务器被黑不是因为密码弱，是你没管好SSH密钥"

前言

我见过太多企业服务器被入侵的案例，事后复盘时，当事人第一反应往往是"密码太简单了"。但实际上，在2024年的攻防对抗里，弱密码早已不是主流入侵路径。真正让攻击者长驱直入的，是SSH密钥管理的混乱——私钥满天飞、权限一塌糊涂、密钥没有有效期、密钥丢了也不知道。

这篇文章不聊密码策略那些老生常谈的东西，重点讲SSH密钥的生成、分发、存储、使用、轮换、销毁这套完整生命周期里，有哪些坑和最佳实践。

先说个真实案例

某创业公司CTO说他们内网服务器被横向渗透，攻击者从一台开发机一路打到核心数据库。事后排查发现：所有服务器的`authorized_keys`里躺着20多个历史员工的公钥，有的密钥对应的私钥早就随员工电脑丢失了，还有些直接是从GitHub上泄露的仓库里找到的。攻击成本：零。

问题不在于密码，在于密钥管理压根没有制度。

密钥生成：一步做错，后面全是漏洞

用`ssh-keygen`的正确姿势

# 最基础的生成命令
ssh-keygen -t ed25519

生成时会被问到三个问题：
1. 保存路径：默认 ~/.ssh/id_ed25519，直接回车
2.  passphrase（密码短语）：强烈建议填写！否则等于明文存储
3. 确认passphrase：再输一遍

完整推荐命令（指定注释方便辨认）
ssh-keygen -t ed25519 -C "lisi@workstation-laptop-2024" -f ~/.ssh/id_ed25519_work

为什么推荐Ed25519而不是RSA：

算法	密钥长度	安全性	性能	兼容性
RSA	4096bit	中	慢	最高
Ed25519	256bit	高（现代）	极快	现代系统
Ed25519-SK	256bit	更高	极快	较新

Ed25519的256位密钥在安全性上等价于RSA的3072位，但签名速度是RSA的20倍。除非你要兼容上世纪的老系统，一律用Ed25519。

passphrase的重要性怎么强调都不为过：没有passphrase的私钥就是裸奔。捡到U盘或拿到备份盘的人直接就能用。passphrase不帮你登录，它用来加密本地存储的私钥文件。

生成后立即做的事

# 查看生成的公钥内容
cat ~/.ssh/id_ed25519_work.pub

查看私钥文件权限（必须600，否则ssh会拒绝使用）
ls -la ~/.ssh/

如果私钥权限不对，立即修复
chmod 600 ~/.ssh/id_ed25519_work chmod 644 ~/.ssh/id_ed25519_work.pub chmod 700 ~/.ssh/

密钥分发：安全地传公钥

禁止用微信/QQ/邮箱传私钥

这条写在任何安全规范里都不过分。私钥一旦经过不可信渠道传输，就等于公开了。

正确做法：

# 方式一：用ssh-copy-id（最安全，公钥加密传输）
ssh-copy-id -i ~/.ssh/id_ed25519_work.pub user@server

方式二：手动追加公钥到authorized_keys
在本机执行：
cat ~/.ssh/id_ed25519_work.pub
复制输出内容，登录服务器后：
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI..." >> ~/.ssh/authorized_keys

方式三：用ssh的ProxyJump通过跳板机中转（完全不在公网暴露端口）
ssh -J jump-server user@target-server

禁止authorized_keys滥用

很多工程师图方便，把`authorized_keys`设成777权限或者放在NFS共享存储上——这些都是安全隐患。

# authorized_keys的正确权限
chmod 600 ~/.ssh/authorized_keys

如果你的home目录权限过于宽松（攻击者可以重写authorized_keys）
chmod 755 ~
home目录必须不能让其他人有写权限
chmod 700 ~/.ssh/

检查是否有group可读写
禁止：others有写权限
chmod go-w ~/ ~/.ssh/

私钥存储：本地磁盘也不行

你以为私钥存在`~/.ssh/`就安全了？不对。

攻击场景：键盘记录器/内存提取

攻击者拿到机器访问权限后，虽然拿不到加密的私钥文件（因为有passphrase），但如果机器上运行着`ssh-agent`，私钥会被缓存在内存里，这时候用`strace`或`/proc`就能把私钥dump出来。

防御方案：用硬件密钥

# YubiKey支持存储Ed25519 SSH密钥
配置YubiKey作为SSH智能卡
ssh-keygen -K -t ed25519-sk -C "yubikey-lisi"
生成后密钥直接写在硬件里，无法被软件提取

macOS用户可以用内置的Secure Enclave
ssh-keygen -t ed25519 -O "置入安全隔区" -C "secure-enclave-lisi"

用ssh-agent但限制其风险

# 启动ssh-agent
eval $(ssh-agent)

添加密钥（每次需要输入passphrase）
ssh-add ~/.ssh/id_ed25519_work

设置代理超时（自动锁定，防止长时间无操作后被利用）
ssh-add -t 4h ~/.ssh/id_ed25519_work   # 4小时后自动从agent移除

列出当前加载的密钥
ssh-add -l

查看密钥指纹（方便核对）
ssh-add -l -E md5

不用时清空agent
ssh-add -D   # 清空所有

服务器端配置：限制密钥能干什么

`authorized_keys`不只是"允许哪个密钥登录"这么简单，可以精确控制每个密钥的行为范围。

# 典型的高安全级别authorized_keys配置
from="192.168.1.100" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... dev-user from="10.0.0.0/8" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... monitor-agent no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... ci-deploy no-pty,no-X11-forwarding,no-agent-forwarding ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... backup-agent

关键前缀解释：

前缀	作用
`from="IP/域名"`	限制登录来源IP，白名单
`no-pty`	禁止分配伪终端
`no-X11-forwarding`	禁止X11图形转发
`no-agent-forwarding`	禁止将SSH agent转发到远程
`no-user-rc`	禁止执行用户rc脚本
`command="/path/to/script"`	强制执行特定命令，密钥只能运行这个

服务器sshd_config加固

# /etc/ssh/sshd_config 推荐配置
PermitRootLogin no                    # 禁止root直接登录 PubkeyAuthentication yes              # 开启密钥登录 PasswordAuthentication no            # 关闭密码登录 MaxAuthTries 3                        # 最大尝试次数 AuthorizedKeysFile .ssh/authorized_keys PermitEmptyPasswords no ClientAliveInterval 300              # 5分钟无活动断开 ClientAliveCountMax 2 LogLevel VERBOSE                      # 记录详细登录日志方便审计 AllowUsers devops deploy admin        # 白名单用户

密钥轮换：多久换一次

没有硬性标准，但有参考原则：

人员离职 → 立即撤销对应公钥

设备丢失/更换 → 立即生成新密钥对

年度审计 → 全面检查`authorized_keys`清理

发现任何泄露嫌疑 → 立即轮换

建立SSH密钥台账（用Excel或数据库记录）：

密钥ID	持有人	设备	创建日期	用途	授权服务器	备注
key-001	张三	笔记本-ThinkPad	2024-01-15	开发	srv-dev-01~05	离职2024-06已撤销
key-002	李四	台式机-戴尔	2025-03-20	运维	全量服务器	在职

批量清理离职密钥脚本：

#!/bin/bash
revoke_keys.sh — 批量撤销离职员工密钥
OLD_EMPLOYEE="zhangsan" SERVER_LIST="srv-dev-01 srv-dev-02 srv-prod-01"

for server in $SERVER_LIST; do     echo "处理 $server ..."     ssh $server "sed -i '/$OLD_EMPLOYEE/d' ~/.ssh/authorized_keys" done

监控与告警：有人登录你得知道

# 实时监控SSH登录（推荐用auditd）
安装auditd
yum install audit -y   # CentOS apt install auditd -y   # Debian/Ubuntu

记录所有SSH登录
auditctl -w /usr/sbin/sshd -p x -k ssh_exec auditctl -w /etc/ssh/sshd_config -p war -k sshd_config

查询登录记录

ausearch -k ssh_exec tail -30


配合fail2ban自动封禁异常IP
/etc/fail2ban/jail.local
[sshd] enabled = true port = ssh maxretry = 5 findtime = 600 bantime = 3600 action = iptables-allports logpath = /var/log/secure

结语

SSH密钥的安全管理，本质上是一个身份与访问控制的问题。密钥是身份，服务器是资源，合理的做法是：最小授权（只给需要的服务器）、来源限制（只在指定的IP登录）、会话约束（不能转发agent和X11）、有效期管理（定期轮换+离职即撤销）。

很多企业把安全预算花在下一代防火墙和EDR上，却忽视了SSH密钥这种"老技术"的管理混乱。攻击者恰恰最喜欢这种"灯下黑"的地方。

希望本文的教程对你有所帮助。如有疑问或需要专业技术支持，可通过以下方式联系我们：

📞 服务热线：13708730161 💬 微信：eyc1689 📧 邮箱：service@eycit.com

易云城IT服务，您身边的IT专家。