1. 项目概述为什么 Ubuntu 18.04 服务器的初始配置至今仍值得深挖“Configuração Inicial de servidor com Ubuntu 18.04”——这个葡萄牙语标题直译是“使用 Ubuntu 18.04 进行服务器初始配置”表面看是个老系统、老操作甚至有人会说“都 2024 年了还搞 18.04”。但恰恰是这种看似过时的操作藏着大量被新教程刻意跳过的底层逻辑和真实生产环境中的硬核细节。我过去十年在金融、教育、政务类私有云项目里部署过超过 1200 台 Ubuntu 系统服务器其中近 30% 仍运行着 18.04 LTS长期支持版不是因为守旧而是因为它的内核稳定度、UFW 防火墙策略成熟度、systemd 服务管理颗粒度在特定嵌入式网关、离线审计终端、老旧硬件兼容场景中反而比 20.04/22.04 更少出意外。你搜到的那些“sql server 登录失败”“failed to start login server”“cant connect to mysql server”报错90% 的根源不在数据库本身而是在初始配置阶段就埋下的权限链断裂、端口暴露失控、SELinux/AppArmor 冲突或 UFW 规则顺序错误。比如“sudo ufw allow samba command not found”这个热搜词根本不是 Samba 没装而是用户在未执行ufw enable前就试图添加规则又或者误把ufw当成iptables的别名去调用——这些坑只有亲手在物理机上敲过 50 遍apt update apt upgrade才会刻进肌肉记忆。本文不讲“三步安装 Web 服务器”的快餐教程而是带你回到第一台 Ubuntu 18.04 服务器通电后的第 67 秒从 BIOS 引导选择开始到ssh连接稳定、防火墙策略生效、系统日志可追溯、关键服务启动无告警为止。适合正在接手遗留系统运维的工程师、需要为等保三级做基线加固的安全人员以及想真正理解 Linux 权限模型与网络栈联动机制的开发者。你不需要会葡萄牙语但必须愿意花 20 分钟把/etc/ssh/sshd_config里的PermitRootLogin和/etc/ufw/before.rules里的-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT对照着敲一遍。2. 初始配置的整体设计思路为什么必须放弃“一键脚本”回归手动分步验证2.1 不是所有“自动化”都叫可靠初始配置必须是“可审计、可回滚、可解释”的很多人看到“Configuração Inicial”第一反应就是找一个 GitHub 上 star 过千的 shell 脚本curl -sL https://xxx.sh | bash一气呵成。我在 2019 年某省级医保平台迁移项目中就吃过这个亏一个封装了ufw enable、fail2ban安装、nginx配置的脚本在凌晨三点自动执行后把 SSH 端口 22 的入站规则写成了-j DROP而非-j ACCEPT导致整个运维团队被锁在服务器外 47 分钟。事后复盘发现脚本作者为了“通用性”把ufw default deny incoming放在了ufw allow OpenSSH之前执行而 Ubuntu 18.04 的 UFW 实现中规则是按写入顺序加载的default deny一旦生效后续allow就无法覆盖——这不是 bug是设计哲学安全策略宁可严苛也不留模糊地带。所以我的初始配置流程强制拆解为 7 个原子步骤每步执行后必须人工验证输出且所有命令带--dry-run或--check参数如ufw status verbose、ss -tuln | grep :22。这看起来慢但换来的是当某天你收到“sign-in failed: failed to start login server”报警时你能立刻定位到是第 3 步的 PAM 模块加载失败而不是在 200 行脚本里逐行echo调试。2.2 Ubuntu 18.04 的特殊性LTS 版本的“稳定”背后是内核与工具链的精确咬合Ubuntu 18.04 基于 Linux kernel 4.15配套的systemd是 237 版本ufw是 0.36openssh-server是 7.6p1。这个组合在 2018–2023 年间被 Red Hat、SUSE 等厂商深度测试过尤其在 ARM64 架构的边缘计算节点上表现极稳。但这也意味着它不兼容很多新语法。例如你在 22.04 上写的ufw allow from 192.168.1.0/24 to any port 3306 proto tcp在 18.04 上会报ERROR: Bad source address因为老版本 UFW 不支持 CIDR 写法中的/24后缀必须写成ufw allow from 192.168.1.0/255.255.255.0 to any port 3306。再比如journalctl -u ssh --since 2 hours ago在 18.04 中会提示--since无效得用journalctl -u ssh --since 2024-05-20 14:00:00这种绝对时间格式。这些细节任何“适配全版本”的脚本都会回避但手动配置时你必须直面。我坚持用apt list --installed | grep -E (ufw|openssh|systemd)先确认版本再查对应 man pageman ufw-framework而不是依赖 Stack Overflow 上 2021 年的过期答案。这种“笨功夫”才是避免“the server selected protocol version tls10 is not accepted by client”这类跨协议握手失败的根本。2.3 防火墙策略设计的底层逻辑UFW 不是 iptables 的包装而是策略编排引擎很多人把 UFW 当作iptables的简化前端这是致命误解。UFW 的核心价值在于策略分层before.rules处理 ICMP、loopback、连接跟踪after.rules处理 NAT 和转发user.rules才是你的业务端口规则。当你执行ufw allow 80/tcpUFW 实际在user.rules末尾追加一行-A ufw-user-input -p tcp --dport 80 -j ACCEPT但这条规则能否生效取决于before.rules里是否已放行 ESTABLISHED 连接、/etc/default/ufw中DEFAULT_INPUT_POLICY是否为DROP。这就是为什么“ufw allow samba command not found”会高频出现——用户只记得ufw allow samba却忘了 Samba 依赖 137/138/139/445 四个端口且 137/138 是 UDP必须显式声明ufw allow 137/udp。更隐蔽的是Samba 的nmbd服务在启动时会尝试绑定0.0.0.0:137如果 UFW 的before.rules中没有-A ufw-before-input -p udp --dport 137 -j ACCEPTnmbd就会因 bind 失败而退出日志里只显示Failed to start nmbd.service: Unit nmbd.service not found根本不会提防火墙。所以我的初始配置中UFW 部分永远分三步走先改/etc/default/ufw设定默认策略再编辑before.rules加基础协议白名单最后用ufw app list确认内置应用配置如 OpenSSH、CUPS是否可用再执行ufw enable。跳过任何一步后面所有“sql server 连接失败”都是自找的。3. 核心细节解析与实操要点从 BIOS 到 root 密码的 12 个必验环节3.1 BIOS/UEFI 设置别让 Secure Boot 成为 SSH 登录的第一道墙很多新手在 VMware 或 VirtualBox 里装完 Ubuntu 18.04ifconfig看到 IP 却死活ssh不进去查日志发现sshd[1234]: error: Could not load host key: /etc/ssh/ssh_host_rsa_key。根源常在 BIOS 的 Secure Boot 设置。Ubuntu 18.04 的内核模块签名机制与某些 OEM 主板的 Secure Boot 策略冲突会导致modprobe nf_conntrack_ftp失败进而使sshd的密钥生成脚本卡住。解决方案不是关 Secure Boot这违反等保要求而是进 BIOS 找到 “Secure Boot Mode” → 设为 “Standard”再进 “Key Management” → 选择 “Restore Factory Keys”。实操中我习惯在安装前就用ls /sys/firmware/efi/efivars/验证 EFI 模式是否启用如果目录存在且非空说明是 UEFI 启动必须检查 Secure Boot如果报No such file or directory则是传统 BIOS需确认硬盘分区表是 MBR 而非 GPT。这个细节99% 的中文教程都不会提但它直接决定你后续所有网络服务的启动成功率。3.2 网络配置/etc/netplan/不是万能的ifconfig和ip link才是真相Ubuntu 18.04 默认用 Netplan 管理网络配置文件在/etc/netplan/01-netcfg.yaml。但 Netplan 只是 YAML 解析器最终调用的是systemd-networkd或NetworkManager。问题来了如果你的服务器插着双网卡Netplan 配置里写了renderer: networkd但实际systemctl is-active systemd-networkd返回inactive那所有配置都是废纸。我强制要求初始配置时执行三连查# 查当前生效的网络后端 systemctl list-units | grep -E (networkd|NetworkManager) # 查物理网卡真实状态绕过 Netplan 缓存 ip link show | grep -E (state|eth|enp) # 查 IP 分配是否由 DHCP 完成避免静态 IP 写错子网掩码 dhclient -v eth0 21 | grep bound to曾有个客户现场Netplan 配置明明写了addresses: [192.168.10.100/24]但ip addr show eth0显示的是169.254.x.x查journalctl -u systemd-networkd发现DHCP lease expired, no response from server根源是交换机端口开启了 DHCP Snooping 但没配信任端口。这种问题Netplan 的netplan apply永远不会告诉你必须用底层命令挖。3.3 用户与权限root密码不是必须的但sudo组的NOPASSWD必须禁用Ubuntu 安装时默认禁用root账户所有管理通过sudo。这很安全但初始配置时很多人会为图省事执行echo %sudo ALL(ALL) NOPASSWD: ALL /etc/sudoers以为这样就能免密执行所有命令。大错特错。NOPASSWD会绕过sudo的日志记录/var/log/auth.log中不再有sudo: user : TTYpts/0 ; PWD/home/user ; USERroot ; COMMAND/bin/bash导致安全审计失效。等保二级明确要求“特权操作应有完整日志”。正确做法是保留默认的%sudo ALL(ALL:ALL) ALL然后为特定命令设别名如alias upsudo apt update sudo apt upgrade -y既提升效率又保日志。更关键的是必须检查/etc/passwd中root行的密码字段如果是*或!说明账户锁定这是对的如果是$6$...这样的哈希值说明root密码被意外启用必须立即sudo passwd -l root锁定。我见过最危险的案例某医院 HIS 服务器的root密码被设为123456黑客通过扫描22端口爆破成功不是因为密码弱而是因为root账户本不该存在。3.4 SSH 服务加固PermitRootLogin只是冰山一角MaxAuthTries和LoginGraceTime才是防爆破核心/etc/ssh/sshd_config的修改是初始配置中最易被轻视的部分。除了常规的PermitRootLogin no、PasswordAuthentication no必须调整三个参数MaxAuthTries 3限制单次连接最多尝试 3 次密码超过即断开。注意不是MaxAuthTries 6因为6是默认值很多扫描器就是按 6 次设计的。LoginGraceTime 30登录宽限期设为 30 秒超时自动断开。这能有效阻断慢速暴力破解如 Hydra 的-t 1模式。UsePAM yes必须开启 PAM否则fail2ban无法读取/var/log/auth.log中的失败记录。实操验证时我从来不用sudo systemctl restart ssh而是用sudo sshd -t检查配置语法再用sudo ss -tuln | grep :22确认端口监听状态。曾有个项目sshd_config里写了Port 2222但ss -tuln显示:22仍在监听查systemctl cat ssh发现ExecStart被硬编码为/usr/sbin/sshd -D $SSHD_OPTS$SSHD_OPTS为空导致配置未生效。这种细节只有手动敲命令才能暴露。3.5 UFW 防火墙ufw status的“active”不等于“生效”必须用iptables -L交叉验证UFW 的status输出常给人虚假安全感。比如ufw status verbose显示Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- 22/tcp ALLOW IN Anywhere你以为 22 端口开放了不一定。执行sudo iptables -L INPUT -n --line-numbers你会看到num target prot opt source destination 1 ufw-before-logging-input all -- 0.0.0.0/0 0.0.0.0/0 2 ufw-before-input all -- 0.0.0.0/0 0.0.0.0/0 3 ufw-after-input all -- 0.0.0.0/0 0.0.0.0/0 4 ufw-after-logging-input all -- 0.0.0.0/0 0.0.0.0/0 5 ufw-reject-input all -- 0.0.0.0/0 0.0.0.0/0 6 ufw-track-input all -- 0.0.0.0/0 0.0.0.0/0关键在第 2 行ufw-before-input它指向/etc/ufw/before.rules。如果这个文件里有-A ufw-before-input -p tcp --dport 22 -j DROP比如某次误操作残留那么ufw allow 22/tcp添加的规则在ufw-user-input链里永远到不了。所以我的标准动作是ufw reset清空所有规则 → 手动编辑before.rules确保lo、ESTABLISHED、ICMP白名单在顶部 →ufw default deny incoming→ufw allow OpenSSH→ufw enable→ 最后sudo iptables -L INPUT -n | head -10确认规则链顺序。这个流程比任何“ufw allow samba command not found”的报错排查都管用。3.6 时间同步systemd-timesyncd不够用必须上ntpd或chronyUbuntu 18.04 默认用systemd-timesyncd同步时间但它精度只有 ±1 秒对数据库事务、SSL 证书校验、Kerberos 认证都是灾难。error 2003 (HY000): cant connect to mysql server的常见原因就是客户端和服务端时间差超过 300 秒MySQL 的require_secure_transport拒绝连接。解决方案是卸载systemd-timesyncd安装chronysudo systemctl stop systemd-timesyncd sudo systemctl disable systemd-timesyncd sudo apt install chrony sudo systemctl enable chrony然后编辑/etc/chrony/chrony.conf注释掉默认的pool行添加国内 NTP 服务器server ntp.aliyun.com iburst server ntp1.aliyun.com iburst server ntp2.aliyun.com iburst验证用chronyc tracking看Last offset是否在±0.01秒内。我坚持用chrony而非ntpd因为chrony在虚拟机中抗时钟漂移能力更强chronyc sources -v能清晰显示每个源的状态比ntpq -p直观十倍。3.7 日志轮转logrotate不是摆设/var/log/ufw.log必须单独配置UFW 默认不记录日志必须手动开启。但开启后/var/log/ufw.log会疯狂增长df -h一周就爆满。很多人用rm /var/log/ufw.log清理结果ufw进程因SIGPIPE崩溃。正确做法是配置logrotatesudo tee /etc/logrotate.d/ufw EOF /var/log/ufw.log { daily missingok rotate 14 compress delaycompress notifempty create 644 syslog adm sharedscripts postrotate invoke-rc.d rsyslog rotate /dev/null endscript } EOF关键是create 644 syslog adm确保新日志文件权限正确否则rsyslog无法写入。我还会在/etc/rsyslog.d/50-default.conf里加一行:msg, contains, UFW /var/log/ufw.log把 UFW 日志单独分流避免和auth.log混在一起。这样查“failed to start login server”时grep REJECT /var/log/ufw.log | tail -20就能一眼看出是哪个 IP 在扫端口。3.8 内核参数优化vm.swappiness1不是玄学是防止 OOM Killer 杀掉 MySQLUbuntu 18.04 的默认vm.swappiness60在内存紧张时会频繁 swap导致 MySQL 查询延迟飙升触发communications link failure。必须调低echo vm.swappiness1 | sudo tee -a /etc/sysctl.conf sudo sysctl -p同时为防止OOM Killer误杀关键进程给mysqld设oom_score_adjecho oom_score_adj -500 | sudo tee -a /etc/systemd/system/mysqld.service.d/override.conf sudo systemctl daemon-reload这个-500不是随便写的oom_score_adj范围是 -1000永不杀到 1000优先杀MySQL 进程默认是 0设 -500 是平衡点。我测过设 -1000 会导致系统在内存耗尽时假死设 -500 则OOM Killer会先杀java进程默认 0再杀mysqld-500最后才轮到sshd-100保证运维通道不丢。3.9 安全基线apt install unattended-upgrades是起点不是终点自动更新必须开但不能无脑开。unattended-upgrades默认只升级security源但updates源里的内核更新如linux-image-4.15.0-218-generic会被跳过导致CVE-2023-1234漏洞长期存在。必须编辑/etc/apt/apt.conf.d/50unattended-upgradesUnattended-Upgrade::Allowed-Origins { ${distro_id}:${distro_codename}-security; ${distro_id}:${distro_codename}-updates; // 取消注释这一行 };然后sudo unattended-upgrade --dry-run --debug测试。更重要的是必须配置邮件通知否则更新失败你根本不知道。在/etc/apt/apt.conf.d/50unattended-upgrades末尾加Unattended-Upgrade::Mail admincompany.com; Unattended-Upgrade::MailOnlyOnError true;这样每次更新失败/var/log/unattended-upgrades/unattended-upgrades.log里会有详细报错比等客户报“sql server 连接失败”强一万倍。3.10 文件系统挂载noatime,nodiratime不是性能优化是延长 SSD 寿命的刚需Ubuntu 18.04 默认用ext4但/etc/fstab里没加noatime。这意味着每次读文件系统都要更新atime访问时间元数据对 SSD 是无谓的写入放大。在/etc/fstab中找到根分区行把errorsremount-ro后面加上,noatime,nodiratimeUUIDxxxx-xxxx / ext4 defaults,noatime,nodiratime,errorsremount-ro 0 1然后sudo mount -o remount /生效。实测某台日志服务器加了这个参数后iostat -x 1显示w_await平均写等待从 12ms 降到 2ms%util设备利用率从 98% 降到 35%。这不是玄学是 SSD 的物理特性决定的。3.11 服务管理systemctl is-enabled比systemctl status更早暴露问题很多“server start failed”错误根源是服务没设开机自启。systemctl status nginx显示active (running)但systemctl is-enabled nginx返回disabled意味着重启后服务就没了。必须对所有关键服务执行for svc in ssh nginx mysql fail2ban; do sudo systemctl enable $svc echo $svc: $(systemctl is-enabled $svc) done更狠的是用systemd-analyze blame查启动最慢的服务systemd-analyze critical-chain看依赖链瓶颈。我遇到过最诡异的案例mysql启动慢blame显示mysql.service耗时 42 秒但critical-chain显示它卡在network.target查systemctl list-dependencies --reverse network.target发现isc-dhcp-server在等一个不存在的网卡eth1删掉/etc/default/isc-dhcp-server里的INTERFACESeth1就秒启。3.12 最终验证清单12 个命令5 分钟跑完拒绝“我以为好了”初始配置结束必须执行这 12 个命令缺一不可hostname -I—— 确认 IP 地址正确ping -c 3 8.8.8.8—— 确认外网连通ssh -o ConnectTimeout5 userlocalhost—— 本地 SSH 自检ufw status numbered—— 确认规则序号和状态sudo ss -tuln | grep :22\|:80\|:443—— 确认端口监听sudo journalctl -u ssh --since 1 hour ago | grep Accepted—— 确认登录日志sudo chronyc tracking | grep Last offset—— 确认时间精度df -h / | awk $5 80 {print ALERT: / usage 80%}—— 确认磁盘余量sudo systemctl list-units --statefailed—— 确认无失败服务sudo apt list --upgradable—— 确认无待升级包sudo ufw logging on—— 确认日志开启sudo reboot sleep 60 ssh userserver_ip—— 终极重启验证这 12 条我写了 7 年改了 127 次现在每台服务器上线前必跑。它不炫技但能让你在客户问“为什么 sql server 连不上”时底气十足地说“我刚验证过网络、防火墙、时间、日志全正常问题一定在 SQL Server 配置本身。”4. 实操过程与核心环节实现从裸机到可交付服务器的完整流水线4.1 环境准备物理机、VMware、VirtualBox 的差异化处理实操前必须明确部署环境因为不同环境的 BIOS 设置、驱动加载、网络模式差异巨大。我按优先级排序物理服务器最高优先级BIOS 设置关闭 C-State节能状态避免intel_idle驱动导致 CPU 频率抖动影响 MySQL 性能RAID 配置用mdadm软 RAID 1 做系统盘/boot单独分区避免 GRUB 无法识别 RAID 10网卡绑定/etc/network/interfaces中配置bond0模式选balance-rr轮询而非active-backup主备因后者在交换机故障时切换慢VMware Workstation次优先级虚拟机设置CPU 选“Intel VT-x/EPT”内存勾选“Enable virtual memory”否则kvm模块无法加载网络适配器用vmxnet3驱动非e1000需在.vmx文件中加ethernet0.virtualDev vmxnet3共享文件夹禁用open-vm-tools的vmhgfs-fuse改用sshfs避免Permission denied错误VirtualBox最低优先级仅测试用网络模式必须用Bridged AdapterNAT模式下ufw无法控制入站流量增强功能安装virtualbox-guest-utils后执行sudo usermod -aG vboxsf $USER否则共享文件夹权限错误无论哪种环境安装 Ubuntu 18.04 ISO 时必须在 GRUB 启动菜单按e键找到linux行末尾加net.ifnames0 biosdevname0强制使用eth0命名避免enp0s3这类 unpredictable names 导致 Netplan 配置失效。4.2 安装阶段最小化安装 手动包选择拒绝“桌面版”诱惑Ubuntu 18.04 安装镜像提供“Server”和“Desktop”两个版本必须选Server。Desktop 版自带gdm3、gnome-shell等 GUI 组件不仅浪费 2GB 磁盘更会因systemd-logind与sshd争抢PAM模块导致login server error: token exchange failed。安装时勾选[x] Install OpenSSH server必须[ ] Install a mail server禁用用外部 SMTP[ ] Configure LVM禁用除非你真懂 LVM 快照[ ] Use an entire disk推荐避免分区错误安装完成后第一件事不是apt update而是sudo apt clean sudo rm -rf /var/lib/apt/lists/*清空缓存再sudo apt update。因为安装镜像自带的apt缓存可能指向archive.ubuntu.com而国内源是mirrors.aliyun.com不清缓存会导致apt update卡在Waiting for headers。4.3 网络配置实操Netplan YAML 的 7 个易错语法点/etc/netplan/01-netcfg.yaml是初始配置的雷区。以下是 7 个我踩过的坑及修复方案坑 1缩进用 Tab 而非空格YAML 严格要求空格缩进Tab 会报Invalid YAML: tab characters are not allowed。用vim编辑时执行:set expandtab ts2 sw2确保 Tab 自动转 2 空格。坑 2IP 地址后多写斜杠错误写法addresses: [192.168.1.100/24/]末尾多/正确写法addresses: [192.168.1.100/24]坑 3网关写成gateway4而非routesUbuntu 18.04.5 已弃用gateway4必须用routesroutes: - to: default via: 192.168.1.1坑 4DNS 服务器用search而非nameservers错误dns-nameservers: [8.8.8.8]正确nameservers: addresses: [8.8.8.8, 114.114.114.114] search: [company.com]坑 5双网卡时忘记routing-policy如果eth0走内网eth1走外网必须指定策略路由ethernets: eth0: dhcp4: false addresses: [10.0.0.100/24] eth1: dhcp4: true routing-policy: - from: 10.0.0.100/24 table: 100坑 6match字段匹配不到网卡match: name: enp0s3可能失败改用 MAC 地址ethernets: eth0: match: macaddress: 00:0c:29:xx:xx:xx坑 7netplan apply后网络中断永远先用sudo netplan try它会 120 秒倒计时期间可CtrlC中断并恢复原配置。try成功后再sudo netplan apply。4.4 UFW 防火墙实操从ufw app list到自定义应用配置UFW 的app list是宝藏。执行sudo ufw app list你会看到Available applications: AIM Bonjour CIFS DNS Dovecot IMAP OpenSSH ...这些是/etc/ufw/applications.d/下的预定义配置。但OpenSSH只开放22/tcp而生产环境常需2222/tcp备用端口这时要创建自定义应用sudo cp /etc/ufw/applications.d/openjdk-8-jre-headless /etc/ufw/applications.d/my-ssh sudo sed -i s/OpenSSH/MySSH/g; s/22/2222/g /etc/ufw/applications.d/my-ssh sudo ufw app update MySSH然后sudo ufw allow MySSH。这样做的好处是规则可读性强ufw status显示2222/tcp (MySSH)比2222数字直观得多。对于 Sambaufw app list里没有必须手动建cat EOF | sudo tee /