Contents

Linux 新服务器初始化完全指南:从零到生产就绪(通用教程)

本文适用场景

你刚买了一台 VPS,系统选了 Debian / Ubuntu,root 登录进去后面对一个空荡荡的终端——接下来该做什么?

本文给你一份完整的初始化清单,涵盖安全加固、网络优化和时间同步。教程以 Debian 13 (Trixie) 为例,同时标注了 Ubuntu 差异点——两套系统我都长期在生产环境使用,命令上的差异不超过 5%。

如果你还没有服务器,可以通过以下链接购买:


1. 系统更新:打好地基

拿到新服务器的第一件事——不是装软件,而是先把系统包更新到最新。

apt update -y && apt upgrade -y

apt update 刷新软件包索引,apt upgrade 把已安装的包升级到最新版本。-y 跳过交互式确认——新服务器没有需要评估的依赖冲突,直接跑。

生产环境注意

如果这是已经在跑的服务器,升级前请评估依赖兼容性。全新服务器直接跑,没有任何顾虑。

如果你用的是 CentOS / Rocky Linux,等效命令是 dnf update -y


2. 创建日常操作用户

Root 直接操作是安全禁忌。创建一个具备 sudo 权限的普通用户,日常操作全都用它。

2.1 创建用户并设置密码

# 创建用户(-m 自动创建 home 目录)
useradd -m -s /bin/bash vpsdeck

# 设置密码
passwd vpsdeck
用户名选择
不要用 admindeployansible 这类太明显的名字。攻击者扫描时会优先尝试这些账户。

2.2 赋予 sudo 权限

# 将用户加入 sudo 组(Debian/Ubuntu 默认有这个组)
usermod -aG sudo vpsdeck

2.3 可选:免密 sudo

每次 sudo 都输密码会打断操作流。个人独享的服务器可以开免密:

echo "vpsdeck ALL=(ALL) NOPASSWD: ALL" | tee /etc/sudoers.d/vpsdeck
chmod 440 /etc/sudoers.d/vpsdeck
安全警告
多用户共享的服务器不要设免密 sudo。这条规则的原则是:能接触到终端的只有你一个人时,免密是效率工具;有其他人时,密码是最后一道防线。

3. 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。星爷粉丝看到会心一笑,攻击者扫描列表里大概率没有这个端口。

端口选择建议
选 1024-65535 之间的端口。避开 2222、22222、10022 等常见替代端口——它们同样在扫描列表里。

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_keys

3.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 开销 较高 低(嵌入式设备友好)
推荐场景 需要兼容老旧设备的混合环境 所有新建基础设施的默认选择
一句话结论
2026 年的新服务器,一律使用 ed25519。RSA-4096 只在需要兼容 2014 年以前的旧客户端时才用。这条建议来自我过去 8 年管理 200+ Linux 服务器的经验。

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_hosts

3.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 ssh
关键步骤:不要关闭当前会话
重启 SSHD 后,先另开一个终端窗口测试密钥登录,确认能登录之后,再关闭原来的 root 会话。否则一个配置错误就能把你锁在外面——然后你只能通过 VNC / 控制台去恢复了。

4. 更换国内镜像源(中国大陆服务器专属)

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 update

Ubuntu 用户:只需将 URL 中的 debian 改为 ubuntutrixie 改为你的 Ubuntu 版本代号(如 noblejammy):

sudo sed -i 's|http://.*archive.ubuntu.com|https://mirrors.ustc.edu.cn|g' /etc/apt/sources.list
sudo apt update

4.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 trixie

5. 修改时区与 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
IANA 时区数据库中,Asia/ShanghaiAsia/ChongqingAsia/Harbin 的别名(alias)。三者完全等价,都代表 UTC+8。Asia/Shanghai 是 1990 年后 IANA 推荐的规范名称。很多旧的教程写 Asia/ChongqingAsia/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.000123s

Offset 在毫秒级别即为正常工作。

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 vs ntpd vs chrony
  • 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 Google
基于带宽+延迟(Model-based) BBRv3 BBR 改进版,修复了 BBRv1 抢占性过强的问题 2023 Google

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 / 大文件传输 带宽跑不满 接近线路物理极限
BBR 不是万能的
BBR 的正确评价:在存在丢包的高延迟链路(如跨境 VPS)上显著优于 CUBIC;在纯净低延迟链路上两者差异不大。如果你的 VPS 只有 CN2 GIA 等优质线路,丢包率接近 0%,BBR 的提升就有限。但对于 99% 的 VPS——特别是晚高峰会堵的非优化线路——BBR 让你用同样的带宽得到更多的实际吞吐量。

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 ...
fq 队列是必需的
如果只设 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_forward
IP 转发与安全
IP 转发开启后,服务器可以充当路由器转发数据包。如果你的服务器没有 iptables/nftables 规则限制转发,它可能被滥用以转发恶意流量。只在实际需要转发(Docker/VPN/NAT)时才开启。 如果只是跑 Nginx / MySQL 等应用,不用开。

8. 收尾:重启验证

所有配置改完后,重启服务器确认所有改动在重启后仍然生效:

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: normalOffset 毫秒级

推荐阅读


关于作者
我是 VPSDeck,一个在 DevOps 和系统运维领域摸爬滚打十年的老工程师。我用过几乎所有的主流 VPS 厂商,搭建过从单机建站到跨洲 Kubernetes 集群的各种架构。写这些教程的目的很简单:让你少踩我踩过的坑