Ubuntu 18.04服务器初始化三板斧:root密码、SSH与vsftpd一次到位

📅 发布时间:2026/9/29 13:07:45
Ubuntu 18.04服务器初始化三板斧:root密码、SSH与vsftpd一次到位
简介在Ubuntu 18.04环境下围绕服务器基础配置的docx文档面向需要远程管理Linux系统的运维初学者或开发者。文档内容完整覆盖四大关键操作使用sudo passwd root修改root用户密码通过apt-get install openssh-server安装SSH服务并用netstat -tlp验证状态编辑/etc/ssh/sshd_config将PermitRootLogin设为yes以允许root远程登录以及安装vsftpd后将vsftpd.conf中write_enableYES注释去掉以获得上传权限。资源包内含1个docx文件大小仅556KB为图文并茂的速查手册适合在部署云服务器或虚拟机时按步骤对照执行。文档采用分步图示配合命令行展示对每处需要修改的配置项都给出前后对比方便读者快速定位与检查。目前已有364人学习过该文档操作指引具备实际参考价值。通过该文档读者可完成远程登录与FTP服务配置同时理解核心配置项和重启服务方法有效避开常见权限问题。1. Ubuntu-18.04 服务器初始化三板斧root、SSH、vsftp 一次配到位刚接触 Ubuntu-18.04 的人最容易在三件事上翻车装完系统发现 root 没密码、SSH 默认拒绝 root 登录、vsftpd 装好后客户端能连上却列不出文件。这三个问题单独看都是几条命令的事但串在一起就变成“服务器装好了远程却进不去”的黑匣子。这份笔记就是我把 Ubuntu-18.04 服务器重装后前 30 分钟要做的事拆成完整流程先解决 root 身份认证再让 SSH 能远程进来最后把 FTP 服务搭稳。适合两类人一类是从 CentOS 切过来的运维需要快速对齐 Ubuntu 的初始化习惯另一类是刚入门 Linux 的新手照着敲就能通踩坑记录留着下次少走弯路。2. 修改 root 用户密码首次初始化与单用户恢复两条路径2.1 首次装完系统为什么 sudo passwd root 才是正解Ubuntu 安装过程中创建的账号默认拥有 sudo 权限但 root 用户本身没有可登录的密码。很多新手上来就敲su -回显Authentication failure以为系统坏了其实只是 root 密码从未设置过。这时不需要重新安装系统也不需要进恢复模式一条命令就能解决sudo passwd root系统会提示Enter new UNIX password:输入两次新密码后看到passwd: password updated successfully就说明写入了/etc/shadow。这是一条交互式命令密码不会显示在终端上这是 passwd 的正常行为不是卡住。这里有个细节容易被忽略sudo passwd root修改的是 root 账户的密码而passwd不带参数时修改的是当前登录用户的密码。如果目标只是让 root 能直接登录用前者如果只是改 ubuntu 这个普通账号的密码用后者。两个命令执行时都需要交互输入两次新密码Linux 的密码策略默认对弱密码不做强制校验PAM 的 pwquality 模块在 Ubuntu-18.04 默认未启用强策略所以密码长短完全由你自己把控但这不代表可以偷懒生产环境至少 12 位混合字符。2.2 忘记 root 密码grub 单用户模式恢复全流程服务器用久了忘记 root 密码是常见事故。重启后进入 grub 引导菜单选择默认内核那一项按e进入编辑模式找到以linux开头的那一行把末尾的ro recovery nomodeset改成rw single init/bin/bash。这里有两个关键参数rw让文件系统以读写方式挂载single进入单用户模式init/bin/bash则是直接拉起一个 bash 作为初始进程跳过所有服务。改完后按CtrlX或F10启动。mount -o remount,rw / passwd root exec /sbin/init进入 shell 后第一件事是先确认根分区是读写状态。如果之前的参数里用的是ro此时/etc/shadow文件是只读的直接passwd root会报Authentication token manipulation error。所以先执行mount -o remount,rw /把根分区重新挂载成可写再改密码。改完后执行exec /sbin/init回到正常启动流程。有些服务器在虚拟化平台上 grub 菜单被跳过开机直接进系统。这时重启时按住ShiftBIOS 引导或不断按EscUEFI 引导让 grub 菜单出现。还有个玄学场景VMware 虚拟机里 grub 菜单一闪而过按Shift也没反应可以试试在虚拟机设置里把启动时进入固件勾上先进 BIOS 再重启一次。CtrlD 卡在 recovery 模式输入不了的情况通常是文件系统挂载状态异常先看/是不是只读再检查磁盘是否满了。2.3 密码策略检查为什么新密码老被 PAM 弹回来某些云镜像或定制版 Ubuntu 会预装额外的 PAM 密码策略模块设置过短或与用户名相似的密码会被拒绝。sudo passwd root执行后如果看到BAD PASSWORD提示这是 libpam-pwquality 在拦截。要么换一个更复杂的密码要么临时调整策略sudo sed -i s/password requisite pam_pwquality.so.*/password requisite pam_pwquality.so retry3 minlen8/ /etc/pam.d/common-password这条命令把最小长度要求降到 8 位。注意/etc/pam.d/common-password是所有密码修改操作passwd、chpasswd、useradd都会引用的公共 PAM 配置改完立即生效不需要重启服务。不建议在生产环境把 minlen 设成 1那等于关掉了所有密码强度保护。如果只针对 root 放开策略需要单独写/etc/security/pwquality.conf里的enforce_for_root参数但一般场景下统一降门槛就够了。3. 安装 SSH 服务并放行 root 远程登录密钥优先级与 config 参数详解3.1 安装 openssh-serverUbuntu 默认不装服务端Ubuntu-18.04 桌面版默认连 ssh 客户端都要手动补服务器版也未必装了 openssh-server。sudo apt install openssh-server装完后先确认服务状态sudo apt update sudo apt install -y openssh-server sudo systemctl enable --now ssh sudo systemctl status ssh ss -tlnp | grep :22第一行把包管理器索引刷新后安装服务端-y跳过确认。第二行里enable设置开机自启--now表示立即启动这条命令比分开写enable和start省一步。第三行看服务是否处于 active 状态。第四行直接检查 22 端口是否在监听这一步比看 systemd 状态更直观——服务显示 active 但端口没起来多半是配置语法错误导致 sshd 启动后随即退出。Ubuntu 上 SSH 服务名称是ssh而不是sshd这是和 CentOS 差别最大的地方。有很多人照着 CentOS 的systemctl start sshd敲回显Unit sshd.service not found然后就开始怀疑人生。Ubuntu 的ssh.service是一个 alias实际对应/lib/systemd/system/ssh.service和ssh.socket两个单元文件。如果你查systemctl status ssh显示Loaded: alias不要慌这是正常现象。3.2 sshd_config 拆解PermitRootLogin 与 PasswordAuthentication 的四种组合SSH 服务装好后默认配置大概率拒绝 root 直接登录。Ubuntu-18.04 的/etc/ssh/sshd_config里默认是PermitRootLogin prohibit-password意思是 root 只能通过密钥登录密码登录被禁止。这对刚配好密码、还没生成密钥的用户来说就等于“root 进不来”。要允许 root 用密码远程登录sudo sed -i s/^#\?PermitRootLogin.*/PermitRootLogin yes/ /etc/ssh/sshd_config sudo sed -i s/^PasswordAuthentication.*/PasswordAuthentication yes/ /etc/ssh/sshd_config sudo sshd -t sudo systemctl reload sshsshd -t是配置语法校验只检查不生效返回码为 0 才继续执行 reload。这里有个常见坑reload只是让 sshd 重新读取配置不会踢掉当前已建立的连接但如果配置里PermitRootLogin写的值非法sshd -t会直接报Bad yes/no argument此时 reload 不会生效服务继续用旧配置跑。四个取值的关系值得记一下yes允许 root 用任何认证方式登录prohibit-password允许 root 但只用密钥forced-commands-only允许 root 但只能执行指定命令no完全拒绝 root。PasswordAuthentication yes/no控制的是密码认证总体开关对 root 和普通用户都生效。四者组合后的实际效果如下表PermitRootLoginPasswordAuthenticationroot 密码登录root 密钥登录普通用户密码登录yesyes允许允许允许yesno拒绝允许拒绝prohibit-passwordyes拒绝允许允许noyes拒绝拒绝允许很多人在云服务器上遇到“密钥能登、密码登不上”的怪现象查了半天发现是云镜像默认把PasswordAuthentication设成了no加上PermitRootLogin prohibit-password两重限制叠一起就把密码登录彻底堵死了。判断当前生效配置别靠眼睛看文件直接跑sshd -T打印所有有效参数这是最靠谱的排查手段。3.3 密钥登录与 authorized_keys 权限陷阱既然密钥认证是 Ubuntu 的默认偏好干脆配一组密钥让 root 免密登录比每次输密码更稳。生成密钥的操作在本地机器上执行ssh-keygen -t rsa -b 4096 -C rootubuntu1804 -f ~/.ssh/id_rsa_ubuntu ssh-copy-id -i ~/.ssh/id_rsa_ubuntu.pub root192.168.1.100第一条命令生成 4096 位 RSA 密钥对-C是注释标签-f指定文件名避免覆盖默认密钥。第二条命令把公钥追加到远程服务器的/root/.ssh/authorized_keys。ssh-copy-id会要求输入一次 root 密码前提是上一步已经把PermitRootLogin改为yes并且密码登录开启写入后立即提示可以密钥登录。直接手动追加公钥时最容易踩权限坑。~/.ssh目录权限必须是 700authorized_keys文件必须是 644 或 600.ssh目录所有者和用户主目录所有者必须一致。sshd对权限非常敏感只要authorized_keys是 777 或者被 root 以外用户持有写权限密钥认证会被静默忽略然后退回密码认证。排查时先怀疑权限不要急着去重新生成密钥。查看远程端权限状态可以用ls -ld /root/.ssh /root/.ssh/authorized_keys chmod 700 /root/.ssh chmod 600 /root/.ssh/authorized_keyschown root:root /root/.ssh -R也别落下尤其是当你曾经用普通用户执行过ssh-copy-id root...这种情况生成的文件属主可能是普通用户。sshd会拒绝读取属主不对的 key 文件日志里留下一行Authentication refused: bad ownership or modes。4. 搭建 vsftpd 服务主动被动模式选型与多用户目录隔离4.1 安装 vsftpd 与基础配置vsftpd 是 Ubuntu 软件源里最稳定的 FTP 服务端包名就叫vsftpdapt 直接装sudo apt install -y vsftpd sudo systemctl enable --now vsftpd sudo cp /etc/vsftpd.conf /etc/vsftpd.conf.bak装完立刻停一下Ubuntu-18.04 的/etc/vsftpd.conf默认配置里listenNO和listen_ipv6YES是互斥的如果系统同时启用了 IPv6 和 IPv4需要手动确认。默认配置还禁止写入write_enableNO匿名登录也开着anonymous_enableYES这些都要按需调整。先把配置文件备份好后面改坏了随时cp回来。基础配置做三件事允许本地用户登录、允许写入、指定监听模式sudo sed -i s/^anonymous_enableYES/anonymous_enableNO/ /etc/vsftpd.conf sudo sed -i s/^#\?write_enableYES/write_enableYES/ /etc/vsftpd.conf sudo sed -i s/^#\?local_umask022/local_umask022/ /etc/vsftpd.conf sudo sed -i s/^listen.*/listenYES/ /etc/vsftpd.conf sudo sed -i s/^listen_ipv6.*/listen_ipv6NO/ /etc/vsftpd.confanonymous_enableNO把匿名访问关掉否则任何人都能连上来下载文件write_enableYES开启上传、删除、重命名权限这个不开的话 vsftpd 会拒绝一切写操作客户端报 550 Permission deniedlocal_umask022决定上传文件默认权限022 意味着上传的文件是 644、目录是 755对多用户共享场景比较合理listenYES让 vsftpd 以独立服务方式监听listen_ipv6NO避免和 IPv4 监听冲突。4.2 被动模式参数与防火墙端口段FTP 有主动和被动两种模式。主动模式下服务器主动连客户端的高位端口客户端在 NAT 后面基本必挂被动模式下服务器监听一个端口范围等待客户端来连穿透性更好。公网环境百分之百选被动模式sudo cat /etc/vsftpd.conf EOF pasv_enableYES pasv_min_port30000 pasv_max_port30010 pasv_address192.168.1.100 EOFpasv_enableYES开启被动模式pasv_min_port和pasv_max_port定义一个 10 个端口的区间服务器在这个范围内挑选端口作为数据传输通道pasv_address是服务器对外的公网或局域网 IP当服务器有多块网卡或者在内网 NAT 后面时不写这个客户端会收到一个内网地址连接直接卡死。如果服务器有固定公网 IP这里填公网地址如果没有公网 IP只在内网用填服务器内网 IP 即可。这个端口段必须同步放行到防火墙。Ubuntu-18.04 默认没有启用 ufw很多人会跳过去但如果你之前手动开过 ufw 或者云安全组限制了端口就要把 21 端口和数据端口一起放开sudo ufw allow 21/tcp sudo ufw allow 30000:30010/tcp sudo ufw status注意 ufw 放行端口段的写法是30000:30010/tcp中间是冒号不是横杠写错的话 ufw 会直接报语法错误。云服务器还要去控制台安全组里加同样的规则否则本地 ufw 开了也白搭——流量在到达系统之前就被云防火墙挡在门外了。4.3 限制 root 与普通用户的目录边界vsftpd 默认允许所有本地用户登录包括 root。root 登录后能访问整个文件系统从安全角度看这是灾难。生产环境建议用普通用户跑 FTP同时把用户限制在自己的 home 目录里sudo sed -i s/^#\?chroot_local_userYES/chroot_local_userYES/ /etc/vsftpd.conf sudo sed -i s/^#\?allow_writeable_chrootYES/allow_writeable_chrootYES/ /etc/vsftpd.confchroot_local_userYES把所有本地用户锁在自己的 home 目录中用户将无法通过cd /etc跳出目录。这个参数有个著名的副作用当用户 home 目录本身可写时vsftpd 会拒绝服务报500 OOPS: vsftpd: refusing to run with writable root inside chroot()。报错原因很直白——chroot 后用户已经看到整个“世界”如果根目录还可写用户就能上传覆盖自己目录下的关键文件。allow_writeable_chrootYES就是取消这层保护。如果不想让 root 登录 FTP可以在配置文件里显式禁止echo userlist_enableYES /etc/vsftpd.conf echo userlist_denyYES /etc/vsftpd.conf echo root /etc/vsftpd.userlist这三行的含义是开启用户名单检查userlist_denyYES表示名单里的用户被拒绝登录把 root 写进名单就让 root 无法登录 FTP。如果哪天要临时放行 root改userlist_denyNO相当于把名单变成白名单此时文件里写的所有用户都允许登录其他一律拒绝。这两种模式别搞混了改错其中一个可能把所有人都挡在外面。5. 集成排查避坑改完密码登录不上、SSH 拒绝、FTP 列表失败的对症处理5.1 su 报“鉴定令牌操作错误”先查 shadow 文件再查 PAM现象sudo passwd root显示密码更新成功但执行su -输入新密码后回显su: 鉴定令牌操作错误英文是su: Authentication token manipulation error怎么输都进不去。原因这个错误字面意思是“认证令牌操作失败”通常不是密码本身错了而是密码写入/etc/shadow时出了问题。常见诱因有三个一是 passwd 命令执行过程中被中断比如输入密码时按了 CtrlC导致 shadow 文件里对应行的哈希没写完整二是/etc/shadow文件权限或属主被改坏三是系统使用 LDAP/NIS 等外部认证源passwd 本地命令和远端认证源不同步。解决先检查/etc/shadow里 root 那一行的格式正常的是一个root:$6$salt$hash:...的长串如果看到root:!:或root:*:说明密码是锁定状态。恢复手段是用单用户模式重新设置密码参考 2.2 节。如果 shadow 文件权限异常执行chmod 640 /etc/shadow chown root:shadow /etc/shadow。外部认证源的情况需要确认/etc/nsswitch.conf里passwd: compat而不是passwd: ldap如果确实走了 LDAP要在 LDAP 服务端改密码而不是在本地改。5.2 SSH 连不上区分连接被拒、超时、认证失败三种形态现象ssh 客户端连接服务器时报错但报错内容每次都不一样有时是Connection refused有时转了半天才报Connection timed out有时直接弹Permission denied (publickey,password)。原因这三种报错对应完全不同的故障点。Connection refused是服务器的 22 端口根本没在监听sshd 没启动或启动后退出Connection timed out是数据包发不过去要么防火墙拦截要么服务器不在同一网络Permission denied是端口通了但认证没过密钥不对、密码策略不允许、账号被锁定都会这样。很多人拿到报错就一头扎进 sshd_config其实先分清这三点能把排查范围缩小一大半。解决按顺序排查。看端口监听状态与防火墙规则注意 ufw 和 cloud security group 是两个独立关口ss -tlnp | grep :22 sudo systemctl status ssh --no-pager -l journalctl -u ssh --no-pager -n 30第一条命令没有输出说明 sshd 没起来看第二条查服务为什么挂通常配置语法错误会在启动时直接打印到 systemd 的日志里第三条看最近 30 条 sshd 日志Connection refused的同时日志里会有error: Bind to port 22 failed之类的线索八成是端口被别的服务占了。Permission denied的排查方向看/var/log/auth.log里面会明确写Failed password for root from ...还是User root from ... not allowed because not listed in AllowUsers。5.3 root 允许用密钥但不能用密码云镜像残留的禁密码配置现象/etc/ssh/sshd_config里已经改成PermitRootLogin yes和PasswordAuthentication yes但 root 密码登录还是报Permission denied普通用户却能正常用密码登录。原因云厂商镜像或历史配置可能残留了/etc/ssh/sshd_config.d/目录下的附加配置文件。Ubuntu-18.04 的 sshd 主配置文件末尾有Include /etc/ssh/sshd_config.d/*.conf这个目录下的配置文件优先级高于主文件里面可能写着PasswordAuthentication no直接覆盖了你改的主配置。解决不要只看主配置文件检查目录里所有 conf 文件的参数覆盖关系grep -R PasswordAuthentication\|PermitRootLogin /etc/ssh/sshd_config.d/ /etc/ssh/ sshd -T | grep -E passwordauthentication|permitrootloginsshd -T输出的才是 sshd 实际生效的运行时参数。如果看到PasswordAuthentication no而主文件里是 yes把那一条从sshd_config.d里删掉再 reload。从那以后我也养成了习惯判断 SSH 配置以sshd -T为准改完后永远先跑一遍语法校验再重启。5.4 vsftpd 能连上但列不出目录被动模式端口被挡现象FTP 客户端能正常登录并显示欢迎信息但执行ls命令后一直转圈最后超时报Failed to retrieve directory listing或者提示227 Entering Passive Mode后卡死。原因控制连接21 端口通了每次列出目录或传输文件时协商的数据连接被动模式端口段却被防火墙拦了。“能登录但列不出目录”基本可以断定是数据端口的问题而不是账号问题。FTP 客户端一般默认被动模式服务器回给客户端的227响应里包含 IP 和端口客户端去连那个端口时数据包被丢弃目录列表自然拉不回来。解决检查三处——vsftpd.conf里pasv_min_port/pasv_max_port是否已配置且范围合理ufw 是否放行了对应的端口段云安全组是否同步放行。注意pasv_address也要核对如果服务器不恰当地响应了内网 IP 而客户端在外面连接会直接失败。用命令行客户端验证最直观ftp -v 192.168.1.100登录后执行passive开启被动模式再执行ls如果报Connection timed out就说明端口段没放行。本地测试建议把pasv_min_port和pasv_max_port的范围设小一点比如 10 个端口方便在防火墙规则里一眼看清。5.5 单用户模式下 passwd 报错文件系统只读导致写入失败现象忘记 root 密码后按 2.2 节进入 recovery 模式执行passwd root时报错或提示“鉴定令牌操作错误”密码始终无法更新。原因这是最经典的坑——grub 启动参数里可能保留了原有的ro挂载选项导致根分区以只读方式挂载passwd无法写入/etc/shadow。前面提到要改成rw但如果用recovery nomodeset启动时忘记带上rw或者某些定制内核强制重挂为只读就会踩这个坑。解决进入 shell 后先执行mount -o remount,rw /确认mount | grep / 输出里包含rw再改密码。另外注意恢复模式里可能只有mount基础命令可用如果passwd不在 PATH 里用/usr/bin/passwd或/bin/passwd的绝对路径执行。改完密码后建议sync一下再重启避免内存中的内容没落盘。6. 验证脚本与后续加固初始化后强制走一遍的三连检查第 2 到第 5 章把三件事都配完了但配置完不等于能用。我每次初始化完一套 Ubuntu-18.04都会强制走一遍“端口监听 → SSH 实测 → FTP 实测”的三连检查三个环节各对应一个命令全部通过才算交付。这个习惯帮我挡掉了至少三次“配完就忘、第二天连不上”的事故。先做端口与服务的静态检查ss -tlnp | grep -E :22|:21|:30000|:30010 sudo systemctl is-active ssh vsftpd第一条命令把 SSH22、FTP 控制端口21和被动模式端口段30000-30010全部列出确认都在 LISTEN 状态。第二条用is-active一次查两个服务输出active即正常。这一步只花了 5 秒但能暴露 80% 的服务未启动问题。接着做 SSH 的实测连接从另一台机器或同一台机器的 localhost发起ssh -o BatchModeyes -o ConnectTimeout5 root192.168.1.100 whoami hostnameBatchModeyes禁止交互输入密码如果密钥认证没配好这条命令会立即失败而不是挂在密码输入上适合脚本化验证。ConnectTimeout5把连接超时限制在 5 秒内避免网络不通时卡半天。返回结果是root加上主机名说明 root 远程登录和密钥链路都通了。如果返回Permission denied回头看 5.2 和 5.3 节的排查路径。最后验证 FTP 服务能不能列目录和传文件。用 lftp 比交互式 ftp 更适合脚本lftp -u webuser,YourPassword 192.168.1.100 -e ls; put /tmp/testfile.txt; bye-u里用逗号分隔用户名和密码-e后面跟命令串ls列目录put上传本地测试文件bye退出。如果ls卡住或失败就是 5.4 节说的被动模式端口段问题。测试文件上传成功后再到服务器上ls -l /home/webuser/testfile.txt确认文件落盘权限是否符合local_umask预期。后续加固走两个动作。一是把 sshd_config 里的PermitRootLogin从yes收紧回prohibit-password密钥登录不受影响但密码爆破路径被堵死二是给 vsftpd 加上登录失败限制sudo apt install -y fail2ban后创建/etc/fail2ban/jail.local里面写入[vsftpd] enabled true和[sshd] enabled true两段。日志位置也不一样SSH 看/var/log/auth.logvsftpd 看/var/log/vsftpd.log出错时先tail -n 50再搜关键词比盲猜快得多。这套检查流程看起来琐碎但正是这些琐碎动作让我在运维事故里找到了一条标准路径。从那以后我每次重装 Ubuntu 服务器都强制走一遍“端口监听 SSH BatchMode 实测 lftp 传文件”三连配完了不急着上线先花两分钟把链路跑通这样后面哪怕出问题也知道锅在哪个环节。希望这份初始化流程和踩坑记录能帮到你让你第一次配 Ubuntu-18.04 时少走几步弯路。本文还有配套的精品资源点击获取