Linux 新服务器初始化完全指南:从零到生产就绪(通用教程)
1. 系统更新:打好地基
拿到新服务器的第一件事——不是装软件,而是先把系统包更新到最新。
apt update -y && apt upgrade -yapt update 刷新软件包索引,apt upgrade 把已安装的包升级到最新版本。-y 跳过交互式确认——新服务器没有需要评估的依赖冲突,直接跑。
如果这是已经在跑的服务器,升级前请评估依赖兼容性。全新服务器直接跑,没有任何顾虑。
如果你用的是 CentOS / Rocky Linux,等效命令是 dnf update -y。
2. 创建日常操作用户
Root 直接操作是安全禁忌。创建一个具备 sudo 权限的普通用户,日常操作全都用它。
2.1 创建用户并设置密码
# 创建用户(-m 自动创建 home 目录)
useradd -m -s /bin/bash vpsdeck
# 设置密码
passwd vpsdeckadmin、deploy、ansible 这类太明显的名字。攻击者扫描时会优先尝试这些账户。2.2 赋予 sudo 权限
# 将用户加入 sudo 组(Debian/Ubuntu 默认有这个组)
usermod -aG sudo vpsdeck2.3 可选:免密 sudo
每次 sudo 都输密码会打断操作流。个人独享的服务器可以开免密:
echo "vpsdeck ALL=(ALL) NOPASSWD: ALL" | tee /etc/sudoers.d/vpsdeck
chmod 440 /etc/sudoers.d/vpsdeck3. SSH 安全加固
SSH 是服务器安全的第一道门。默认配置——22 端口 + 密码登录 + root 允许——等于开着门等人来踹。
3.1 修改 SSH 端口
全网 22 端口的自动化扫描脚本每秒都在跑。换到高位端口,能过滤掉 99% 的噪音。
# 备份原配置
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
# 修改端口(以 9527 为例)
sed -i 's/^#Port 22/Port 9527/' /etc/ssh/sshd_config为什么是 9527?这是周星驰电影《唐伯虎点秋香》里唐伯虎在华府的编号——华府低等下人 9527。星爷粉丝看到会心一笑,攻击者扫描列表里大概率没有这个端口。
3.2 禁止 Root 直接登录
sed -i 's/^#PermitRootLogin prohibit-password/PermitRootLogin no/' /etc/ssh/sshd_config等效操作:直接编辑 /etc/ssh/sshd_config,找到 PermitRootLogin 行改为 no。
3.3 禁用密码登录,只用密钥
sed -i 's/^#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config执行之后,所有 SSH 登录只能通过密钥完成——即便有人猜到你的密码,也无法登录。
3.4 生成 ed25519 密钥对(含 Windows / Linux 详细教程)
密钥生成在你自己的电脑上执行,不是服务器上。
下面是针对不同操作系统的详细步骤。很多 Windows 用户卡在这一步——2026 年了,Windows 10/11 已经内置 OpenSSH,不需要装 PuTTYgen。
Windows 10/11 用户
Windows 10(1809+)和 Windows 11 已内置 OpenSSH 客户端。你不需要下载任何软件。
第一步:确认 OpenSSH 已安装
打开 PowerShell(在开始菜单搜索 “PowerShell”),运行:
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH.Client*'输出中 State : Installed 表示已安装。如果不是,通过以下方式安装:
- 方法 A(GUI):设置 → 应用 → 可选功能 → 添加功能 → 搜索 “OpenSSH 客户端” → 安装
- 方法 B(PowerShell 管理员):
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
第二步:生成密钥
打开 PowerShell 或 命令提示符(CMD) ——两个终端都能用,效果一样:
ssh-keygen -t ed25519 -C "vpsdeck@myserver" -f "$env:USERPROFILE\.ssh\vpsdeck_ed25519"执行后会提示你输入 passphrase(密码短语)。这是一个二次保护——即使私钥文件泄露,没有 passphrase 也无法使用。输入两次后密钥就生成了。
密钥文件位置(在文件资源管理器地址栏粘贴以下路径即可直达):
%USERPROFILE%\.ssh\你会看到两个新文件:
| 文件 | 说明 |
|---|---|
vpsdeck_ed25519 |
私钥——绝不要发给任何人 |
vpsdeck_ed25519.pub |
公钥——放到服务器上 |
Windows 用户的常见问题:
| 问题 | 原因 | 解决 |
|---|---|---|
ssh-keygen 不是内部或外部命令 |
OpenSSH 未安装 | 按第一步安装 |
Could not create directory |
~/.ssh 目录不存在 |
手动创建:mkdir %USERPROFILE%\.ssh |
生成后看不到 .ssh 文件夹 |
文件资源管理器隐藏了以点开头的文件夹 | 直接在地址栏输入 %USERPROFILE%\.ssh |
CMD 中 %USERPROFILE% 不展开 |
语法问题 | 改用 %HOMEPATH% 或直接用 C:\Users\你的用户名\.ssh\vpsdeck_ed25519 |
Linux / macOS 用户
打开终端:
ssh-keygen -t ed25519 -C "vpsdeck@myserver" -f ~/.ssh/vpsdeck_ed25519按提示输入 passphrase(可选但推荐),两次回车后密钥生成完毕。
验证生成的文件:
ls -la ~/.ssh/vpsdeck_ed25519*
# 输出:
# -rw------- 1 you staff 419 Jul 16 12:00 vpsdeck_ed25519
# -rw-r--r-- 1 you staff 102 Jul 16 12:00 vpsdeck_ed25519.pub为什么不建议用 PuTTYgen?
PuTTYgen 生成的 .ppk 格式是 PuTTY 私有的,其他工具不认识。Windows 自带的 OpenSSH 生成的密钥是标准 OpenSSH 格式,可以用在任何地方——VS Code 远程开发、Git SSH、SCP 文件传输。2026 年了,用标准格式是对自己负责。
3.5 把公钥上传到服务器
Windows 用户
打开 PowerShell,用 scp 上传公钥(Windows 10 1809+ 已内置 scp):
scp -P 22 "$env:USERPROFILE\.ssh\vpsdeck_ed25519.pub" root@<服务器IP>:~/然后 SSH 登录服务器,手动追加:
mkdir -p ~/.ssh
cat ~/vpsdeck_ed25519.pub >> ~/.ssh/authorized_keys
rm ~/vpsdeck_ed25519.pub或者直接用 ssh-copy-id(需要在 PowerShell 中安装,或者用 Git Bash):
ssh-copy-id -i ~/.ssh/vpsdeck_ed25519.pub -p 22 root@<服务器IP>Linux / macOS 用户
ssh-copy-id -i ~/.ssh/vpsdeck_ed25519.pub root@<服务器IP>如果 ssh-copy-id 不可用,手动操作:
# 在你自己电脑上查看公钥
cat ~/.ssh/vpsdeck_ed25519.pub
# SSH 登录服务器后
mkdir -p ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1..." >> ~/.ssh/authorized_keys3.6 配置 SSH 客户端快捷连接
在你的电脑上创建 ~/.ssh/config(Windows:%USERPROFILE%\.ssh\config):
Host myserver
HostName <服务器IP>
Port 9527
User vpsdeck
IdentityFile ~/.ssh/vpsdeck_ed25519之后只需 ssh myserver 就能登录。
3.7 RSA vs ed25519:为什么选后者
两种算法我都在生产环境用过。以下是真实对比:
| 维度 | RSA (4096-bit) | ed25519 |
|---|---|---|
| 安全强度 | ~128-bit(等效对称) | ~128-bit(等效对称) |
| 密钥长度 | 私钥 3,244 字节,公钥 800 字节 | 私钥 419 字节,公钥 102 字节 |
| 签名速度 | 较慢(4096-bit 模幂运算) | 快(椭圆曲线,常数时间) |
| 验证速度 | 快(e=65537,只需 17 次乘法) | 快(略快于 RSA-4096 验证) |
| 抗量子计算 | ❌(Shor 算法可破解) | ❌(同样面临量子威胁) |
| 侧信道攻击 | 容易写出非恒定时间实现 | 算法设计上就是恒定时间 |
| 兼容性 | 所有 SSH 客户端都支持(1995 年至今) | OpenSSH 6.5+(2014 年),覆盖 99.9% 的生产环境 |
| 生成时间 | ~2-10 秒(依赖 CPU 熵源) | < 0.1 秒 |
| SSH 握手 CPU 开销 | 较高 | 低(嵌入式设备友好) |
| 推荐场景 | 需要兼容老旧设备的混合环境 | 所有新建基础设施的默认选择 |
3.8 ~/.ssh 目录与文件权限
SSH 对权限极其苛刻。错一个数字,密钥登录就静默失败——日志里还不一定写原因。
| 路径 | 建议权限 | 所有者 | 说明 |
|---|---|---|---|
~/.ssh/ |
700 (drwx——) |
用户自己 | 目录必须只能被 owner 访问。权限过松(如 755)会导致 SSH 拒绝使用该目录下的密钥 |
~/.ssh/authorized_keys |
600 (-rw——-) |
用户自己 | 存放允许登录的公钥列表。一行一个公钥。权限必须是 600 |
~/.ssh/id_ed25519 |
600 (-rw——-) |
用户自己 | 私钥。权限绝对不能超过 600 |
~/.ssh/id_ed25519.pub |
644 (-rw-r–r–) |
用户自己 | 公钥,可以公开,644 即可 |
~/.ssh/config |
600 (-rw——-) |
用户自己 | SSH 客户端配置文件。600 足够,因为包含连接信息 |
~/.ssh/known_hosts |
644 (-rw-r–r–) |
用户自己 | 记录过已连接主机的指纹,公开无影响 |
快速修复脚本:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys ~/.ssh/id_ed25519 ~/.ssh/config
chmod 644 ~/.ssh/id_ed25519.pub ~/.ssh/known_hosts3.9 authorized_keys vs known_hosts vs config
新手容易混淆这三个文件。用一个表格说清楚:
| 文件 | 位置 | 用途 | 谁写的 | 类比 |
|---|---|---|---|---|
authorized_keys |
服务器 ~/.ssh/ |
列出允许登录的客户端公钥。每个公钥代表一个被授权的"门禁卡" | 你自己手动写入 | 门禁系统的白名单 |
known_hosts |
客户端 ~/.ssh/ |
记录你曾经连接过的服务器主机指纹(host key)。防止中间人攻击 | SSH 客户端自动写入 | 浏览器的 HSTS 预载列表 |
config |
客户端 ~/.ssh/ |
SSH 客户端的行为配置(别名、端口、密钥路径、代理跳板等) | 你自己手动写入 | 快捷方式管理器 |
实际工作流:
你电脑上的 config → 指定用哪个私钥 → 私钥匹配服务器上的 authorized_keys → 登录成功
你电脑上的 known_hosts → 验证服务器主机指纹 → 防止连接伪造的服务器3.10 重启 SSH 服务使配置生效
systemctl restart sshd
# 或(Ubuntu/Debian 新版)
systemctl restart ssh4. 更换国内镜像源(中国大陆服务器专属)
4.1 什么时候需要换源
| 服务器位置 | 是否需要换源 | 原因 |
|---|---|---|
| 腾讯云 / 阿里云中国大陆 | ❌ 不需要 | 云厂商自带的 OS 镜像已将源指向自家内网镜像,延迟 < 5ms |
| 其他国内 IDC(非云厂商) | ✅ 建议换 | 直接访问 deb.debian.org 速度可能只有几十 KB/s |
| 海外服务器 | ❌ 不需要 | 官方源访问速度快 |
| 中国大陆教育网/CERNET | ✅ 必须换 | 中科大 USTC / 清华 TUNA 免流量 |
如果你是从腾讯云或阿里云购买的服务器,系统自带的源就是各家自己的内网镜像,不需要手动修改。这也是选择大厂的优势——基础设施层面已经帮你优化好了。
还没有服务器?可以通过以下链接购买:
4.2 更换为中国科学技术大学(USTC)镜像
我推荐优先使用中科大镜像,而非清华 TUNA。理由很直接:
| 对比维度 | 中科大 USTC | 清华 TUNA |
|---|---|---|
| 教育网免流量 | ✅ | ✅ |
| 同步频率 | 每 6 小时 | 每 6 小时 |
| 上游 | 直接同步 Debian 官方 | 直接同步 Debian 官方 |
| 带宽 | 10 Gbps(骨干网出口大) | 10 Gbps |
| HTTrack 支持 | ✅ 允许(方便本地镜像) | 部分受限 |
| 稳定运营年限 | 2002 年至今(23 年) | 2012 年至今(14 年) |
中科大 LUG(Linux User Group)维护的镜像站从 2002 年开始服务,是中国大陆历史最悠久的开源镜像站之一。Debian 官方将 USTC 列为 全球官方备份镜像 之一。
# 1. 备份原始源文件
cp /etc/apt/sources.list /etc/apt/sources.list.bak
# 2. 写入中科大镜像源(Debian 13 Trixie)
cat > /etc/apt/sources.list << 'EOF'
deb https://mirrors.ustc.edu.cn/debian/ trixie main contrib non-free non-free-firmware
deb https://mirrors.ustc.edu.cn/debian/ trixie-updates main contrib non-free non-free-firmware
deb https://mirrors.ustc.edu.cn/debian/ trixie-backports main contrib non-free non-free-firmware
deb https://mirrors.ustc.edu.cn/debian-security/ trixie-security main contrib non-free non-free-firmware
EOF
# 3. 更新软件包索引
apt updateUbuntu 用户:只需将 URL 中的 debian 改为 ubuntu,trixie 改为你的 Ubuntu 版本代号(如 noble、jammy):
sudo sed -i 's|http://.*archive.ubuntu.com|https://mirrors.ustc.edu.cn|g' /etc/apt/sources.list
sudo apt update4.3 其他国内镜像选择
| 镜像站 | 地址 | 特点 |
|---|---|---|
| 中科大 USTC | mirrors.ustc.edu.cn |
老牌镜像,教育网免流量,本文推荐首选 |
| 清华大学 TUNA | mirrors.tuna.tsinghua.edu.cn |
带宽充足,同步及时 |
| 阿里云 | mirrors.aliyun.com |
阿里云 ECS 内网免流量 |
| 腾讯云 | mirrors.cloud.tencent.com |
腾讯云 CVM 内网免流量 |
| 华为云 | repo.huaweicloud.com |
华为云用户专用 |
# 用 netselect-apt 自动选最快的源
apt install netselect-apt -y
netselect-apt -n trixie5. 修改时区与 NTP 时间同步
时区和时间准确性直接影响日志排查、证书验证和分布式系统一致性。新服务器默认时区通常是 UTC(Etc/UTC),凌晨三点日志显示为 03:00——不符合国内运维人员的阅读习惯。
5.1 修改时区为上海
# Debian / Ubuntu 通用方法
timedatectl set-timezone Asia/Shanghai
# 验证
timedatectl输出应显示 Time zone: Asia/Shanghai (CST, +0800)。
Asia/Shanghai 是 Asia/Chongqing 和 Asia/Harbin 的别名(alias)。三者完全等价,都代表 UTC+8。Asia/Shanghai 是 1990 年后 IANA 推荐的规范名称。很多旧的教程写 Asia/Chongqing 或 Asia/Harbin——本质一样,只是名字不同。5.2 配置 NTP 时间同步
Linux 内核时钟在虚拟机环境下漂移严重——KVM/Xen 虚拟机的时钟漂移通常达到每天 1-5 秒。长期不校准会导致:
- SSL/TLS 证书验证失败(时间偏差超过证书有效期窗口)
- 日志时间线错乱,无法关联多台服务器的事件
- Docker/K8s 节点
token expired错误
Debian 13 / Ubuntu 24.04 默认使用 systemd-timesyncd 作为 NTP 客户端。我们将其指向中科大 NTP 服务器:
# 1. 编辑 timesyncd 配置
cat > /etc/systemd/timesyncd.conf << 'EOF'
[Time]
NTP=time.ustc.edu.cn ntp.aliyun.com
FallbackNTP=ntp.ubuntu.com
EOF
# 2. 重启服务并启用
systemctl restart systemd-timesyncd
systemctl enable systemd-timesyncd
# 3. 查看同步状态
timedatectl timesync-status输出示例:
Server: 202.141.160.2 (time.ustc.edu.cn)
Poll interval: 34min 8s
Leap: normal
Offset: +0.000123sOffset 在毫秒级别即为正常工作。
| NTP 服务器 | 地址 | 位置 | 推荐用途 |
|---|---|---|---|
| 中科大 NTP | time.ustc.edu.cn |
安徽合肥 | 国内首选,教育网/公网双栈 |
| 阿里云 NTP | ntp.aliyun.com |
全国多节点 | 阿里云 ECS 内网可直接访问 |
| 腾讯云 NTP | time.cloud.tencent.com |
全国多节点 | 腾讯云 CVM 专用 |
| NTP Pool | cn.pool.ntp.org |
中国区池 | 备选(解析到随机节点) |
- systemd-timesyncd:轻量 SNTP 客户端,仅做客户端(不对外提供 NTP 服务),适合 99% 的 VPS 场景。本文使用这个。
- chrony:功能更全,支持对时精度到微秒级,适合物理服务器和需要对外提供 NTP 服务的场景。
- ntpd:传统方案,已被 chrony 取代。RHEL 8+ 和 Debian 10+ 默认不再预装。
除非你的 VPS 对内网其他机器提供授时服务,否则 systemd-timesyncd + 中科大 NTP 完全够用。VM 虚拟化场景下,物理时钟由宿主机控制,chrony 的高精度优势无法发挥。
6. 开启 TCP BBR 拥塞控制
6.1 先理解:Linux 拥塞控制算法全景
Linux 内核支持多种 TCP 拥塞控制算法,可以通过 sysctl net.ipv4.tcp_available_congestion_control 查看当前内核支持的全部列表。
主流算法分三大类:
| 分类 | 代表算法 | 核心原理 | 诞生年份 | 提出者 |
|---|---|---|---|---|
| 基于丢包(Loss-based) | Reno | 检测到丢包 → 拥塞窗口减半 | 1990 | Van Jacobson |
| 基于丢包(Loss-based) | CUBIC | 三次函数建模窗口增长,Linux 默认 | 2008 | Ha et al. |
| 基于带宽+延迟(Model-based) | BBR | 持续估算瓶颈带宽和 RTT,不依赖丢包信号 | 2016 | |
| 基于带宽+延迟(Model-based) | BBRv3 | BBR 改进版,修复了 BBRv1 抢占性过强的问题 | 2023 |
6.2 算法横向对比
| 维度 | Reno | CUBIC | BBR |
|---|---|---|---|
| 算法类型 | 丢包检测 | 丢包检测 | 带宽延迟建模 |
| Linux 默认 | ❌(1990-2008 年默认) | ✅(2008 年至今默认) | ❌(需手动开启) |
| 高带宽长延迟链路(BDP 大) | 带宽利用率 20%-40% | 带宽利用率 50%-70% | 带宽利用率 70%-95% |
| 1% 随机丢包场景 | 吞吐量暴跌 50%+ | 吞吐量下降 30%-50% | 几乎不受影响 |
| 缓存膨胀(Bufferbloat) | 严重(填满缓冲区才丢包) | 中等 | 极低(BBR 跟踪 RTT 变化,主动限速) |
| 公平性(多流共享链路) | 公平 | 较公平 | BBRv1 抢占性强(已改进) |
| CPU 开销 | 极低 | 极低 | 略高(带宽探测计算),可忽略 |
| 适合场景 | 无 | 公平性优先的混合流量 | 跨洲跨境 VPS、视频流、大文件传输 |
| Google 内部实测 | — | — | YouTube 吞吐量提升 4%,Google.com 延迟降低 14%(ACM Queue 2017) |
6.3 为什么 VPS 场景推荐 BBR
| 场景 | CUBIC(默认) | BBR |
|---|---|---|
| 中美跨境链路(延迟 150ms+) | 带宽利用率 30%-50% | 带宽利用率 70%-95% |
| 晚高峰丢包 1%-5% | 吞吐量骤降(误判为拥塞) | 不受影响(BBR 不依赖丢包信号) |
| 本地局域网(< 1ms) | 表现正常 | 表现正常(无提升,也无劣化) |
| YouTube / 大文件传输 | 带宽跑不满 | 接近线路物理极限 |
6.4 开启 BBR + fq 队列
BBR 必须搭配 fq(Fair Queuing)队列调度算法使用。fq 负责做 pacing(流量整形)——没有它,BBR 的带宽探测逻辑无法正常工作。
# 1. 加载 BBR 内核模块
modprobe tcp_bbr
# 2. 写入 sysctl 配置
cat >> /etc/sysctl.conf << 'EOF'
# TCP BBR 拥塞控制 + fq 队列
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF
# 3. 应用配置
sysctl -p
# 4. 验证(输出应为 bbr)
sysctl net.ipv4.tcp_congestion_control验证 BBR 已生效——输出应为 bbr:
sysctl net.ipv4.tcp_congestion_control
# net.ipv4.tcp_congestion_control = bbr
# 验证 fq 队列已启用
tc -s qdisc show | grep fq
# qdisc fq 8004: dev eth0 root refcnt 2 ...tcp_congestion_control = bbr 而不设 default_qdisc = fq,BBR 依然能跑,但性能打折扣——特别是在带宽波动较大的广域网链路上。fq 负责将 BBR 计算出的发送窗口均匀分布到每个 RTT 周期中,形成 TCP pacing。不用 fq,BBR 的 pacing 效率降低约 30%-40%。7. 开启 IPv4 转发
如果你需要在服务器上运行 Docker、Kubernetes、或者做 VPN/代理服务,IPv4 转发必须开启。内核默认是关闭的。
# 1. 临时开启(立即生效)
echo 1 > /proc/sys/net/ipv4/ip_forward
# 2. 永久生效
sed -i 's/^#net.ipv4.ip_forward=1/net.ipv4.ip_forward=1/' /etc/sysctl.conf
sysctl -p
# 3. 验证(输出应为 1)
cat /proc/sys/net/ipv4/ip_forward8. 收尾:重启验证
所有配置改完后,重启服务器确认所有改动在重启后仍然生效:
reboot重启后用新端口 + 新用户 + 密钥重新登录,验证以下几项:
| 检查项 | 命令 | 预期输出 |
|---|---|---|
| SSH 端口 | ss -tlnp | grep ssh |
:9527 |
| Root 禁止登录 | ssh root@<IP> |
Permission denied |
| BBR 已开启 | sysctl net.ipv4.tcp_congestion_control |
bbr |
| fq 队列已生效 | tc -s qdisc show | grep fq |
包含 fq 字样的 qdisc |
| IP 转发已开启 | cat /proc/sys/net/ipv4/ip_forward |
1 |
| 源已更换 | apt update |
速度正常,连接 mirrors.ustc.edu.cn |
| 时区正确 | timedatectl | grep "Time zone" |
Asia/Shanghai (CST, +0800) |
| NTP 同步正常 | timedatectl timesync-status |
Leap: normal,Offset 毫秒级 |
推荐阅读
- 🔒 Fail2ban 部署指南 — 自动封禁恶意 IP,防御 SSH 爆破
- 📄 Nginx 第 1 期:源码编译安装 — FHS 规范、configure 参数解析、平滑升级
- 🌐 中国三大运营商精品线路指南 — CN2 GIA / 9929 / CMIN2 一篇搞懂
- 🖥️ RustDesk Server 自建教程 — 自建远程桌面,不上传数据到第三方