企业官网建设流程全解析

“FileZilla 连接 Ubuntu”这个搜索词我见了太多次，而且几乎每次都是同一个卡点：用户高高兴兴装好了 FileZilla，填上 Ubuntu 的 IP，点“快速连接”，然后收获一句“连接被拒绝（ECONNREFUSED）”。如果你也卡在这，先把手从键盘上拿开，问题大概率不在 FileZilla，而是 Ubuntu 端压根没把 SSH 服务跑起来。这篇文章我打算按实际排障的顺序来写，而不是按软件手册来写：先讲 Ubuntu 那边要准备什么，再讲 FileZilla 里最容易被忽略的配置项，然后是真实使用中一定会的上传下载和权限坑，最后是把常见报错连成一条排查链路。新装完的 Ubuntu 想被稳定连上，跟着十分钟左右能解决；已经能连上但被权限、密钥和断线折磨的人，后面几段也有对应解法。

1. 连接前先摸清 Ubuntu 后端：SSH 服务其实没起来

先说一个反直觉的结论：FileZilla 的“连接 Ubuntu”，在九成情况下走的是 SFTP 协议，而 SFTP 依赖的是 Ubuntu 里的 OpenSSH 服务。也就是说，你在 Windows 上把 FileZilla 折腾得再明白，Ubuntu 这边不开 SSH 服务，一切都是白搭。很多第一次接触 Ubuntu 的人会默认“系统装好了就能远程连”，但实际并不是。

Ubuntu 桌面版默认不安装 openssh-server，服务器版最小化安装时也不会主动装。这不是 FileZilla 的问题，也不是 Ubuntu 故意为难人，而是出于安全考虑：一个默认不监听外部连接的系统，攻击面天然小。所以拿到新系统后，第一步永远是检查并安装 SSH 服务。

1.1 先看一眼 SSH 服务到底装没装

判断方法很简单，在 Ubuntu 终端执行：

dpkg -l | grep openssh-server

如果返回为空，说明根本没安装；如果有ii openssh-server开头的输出，说明装上了。另一种快速判断法是直接看服务状态：

systemctl status ssh

Ubuntu 下 ssh 和 sshd 都会指向同一个服务，哪个名字都能用。如果状态是Active: inactive (dead)或者提示Unit ssh.service could not be found，那甭管 FileZilla 怎么配置，结果都是连不上。

我遇到过一个最典型的场景：用户用虚拟机装 Ubuntu，装的时候一路回车，看到桌面能进、浏览器能开，就觉得系统正常了。之后在 Windows 用 FileZilla 连，反复报错。最后远程指导他在 Ubuntu 里敲了一句sudo systemctl start ssh，连接立刻通了。整个过程不到一分钟，但之前这位朋友已经折腾了两天。所以网上所有“FileZilla 连不上 Ubuntu”的求助帖，我第一反应永远是：先确认 SSH 服务在跑。

1.2 安装并设置开机自启

没装的话，执行下面的命令：

sudo apt update sudo apt install -y openssh-server

安装完成后，再执行一次启动和开机自启：

sudo systemctl enable --now ssh sudo systemctl status ssh

看到Active: active (running)，并且第一行里有Loaded: loaded (/lib/systemd/system/ssh.service; enabled; preset: enabled)，说明服务已经跑起来，而且重启系统后也会自动启动。

接着可以用一条命令确认端口监听：

sudo ss -tlnp | grep :22

有输出说明 22 端口正在监听，这是 SSH/SFTP 的标准端口。没输出的话，多半是 sshd 启动失败，继续看systemctl status ssh里的日志信息。

1.3 拿到 Ubuntu 的 IP，并放行防火墙

FileZilla 里要填的“主机”，就是 Ubuntu 的 IP 地址。查看方式：

ip -4 addr show

输出里inet后面的地址就是局域网 IP，常见的是192.168.x.x或10.0.x.x。如果你在虚拟机里装的 Ubuntu，这一步容易踩坑：NAT 模式下，虚拟机可以联网，宿主机也能连到虚拟机，但局域网里的其他电脑不一定能连上来；桥接模式则会让虚拟机和宿主机处在同一局域网，访问方式更符合直觉。如果你只是本机 Windows 加 VMware/VirtualBox 里一台 Ubuntu，NAT 模式通常也够用，关键是 FileZilla 填的 IP 要和 Ubuntu 终端里显示的一致。

然后处理防火墙。Ubuntu 默认不一定启用 UFW，但如果你之前开过，或者系统镜像预设了规则，很可能把 22 端口挡在外面：

sudo ufw allow OpenSSH sudo ufw status

看到OpenSSH ALLOW Anywhere就说明放行了。顺便说一句，我自己新装 Ubuntu 后会顺手跑一遍sudo ufw enable，然后只放行 SSH 和必要端口。SFTP 本身走的是加密通道，配合防火墙限制来源 IP，是成本最低的安全手段。

做完这些，Ubuntu 这一端已经具备被连接的条件了。你可以先在本地自测一下：

ssh 用户名@localhost

能登录就说明 SSH 服务基本正常。接下来进入 FileZilla 的配置环节。

2. FileZilla 连接配置：协议、站点管理与指纹确认

很多人在 FileZilla 里填错的第一步，就是协议。FileZilla 支持 FTP、FTPS、SFTP 等多种协议，看着都差不多，实际上天差地别。连 Ubuntu，我几乎只用 SFTP。

2.1 为什么是 SFTP 而不是 FTP

FTP 是 FileZilla 名字里带着的经典协议，但它有一个致命问题：默认不加密，用户名密码和文件内容都是明文传输。在局域网里用问题不大，一旦越过公网，账号密码等于在路上裸奔。FTPS 是在 FTP 基础上加了 TLS 加密，但又引入了证书、显式/隐式加密等一堆概念，端口和传输模式都需要额外折腾。

SFTP 的全称是 SSH File Transfer Protocol，它建立在 SSH 协议之上，默认走 22 端口，单端口搞定加密、认证和传输。OpenSSH 服务装好之后，SFTP 能力是自动附带的标准功能，不需要单独装 FTP 服务器软件。对新手来说，SFTP 几乎不用额外配置；对老手来说，SFTP 只需在防火墙里放行一个端口，省心很多。

2.2 站点管理器里的关键字段

打开 FileZilla，菜单栏“文件”里找到“站点管理器”，或者直接按Ctrl+S。点“新站点”，按下面这样填：

填完之后，点“连接”。如果一切正常，FileZilla 会弹窗提示未知主机密钥，这个我们下一步专门说。

登录类型里还有个“正常”选项，可以直接把密码保存下来，下次连的时候不用输。我个人的建议是：家里自用的小服务器无所谓，公司或公网服务器，要么选“询问密码”，要么用后面要讲的密钥登录，不要明文存密码。

2.3 首次连接的主机密钥指纹确认

这是最容易被忽略、但很重要的一步。FileZilla 第一次连接会弹一个对话框，显示一串字符串，叫“主机密钥指纹”。这串东西相当于 Ubuntu 服务器在 SSH 世界里的身份证。

很多新手看到弹窗就晕，直接点确定，其实这里是有安全意义的。正确的做法是，在 Ubuntu 终端执行：

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Ubuntu 各版本默认密钥类型可能不太一样，也可以先ls /etc/ssh/ssh_host_*看看有哪些公钥文件，再用上面的ssh-keygen -lf查看对应文件的指纹。如果 FileZilla 弹窗里的字符串和终端里的一致，说明你连的就是目标机器，可以放心信任并加入信任列表。

如果你重装了 Ubuntu 系统，或者换了台服务器，再连接时 FileZilla 还会弹一次这个窗口，而且会提醒“主机密钥与之前不同”。这种情况要警惕，可能是系统确实重装了，也可能是存在中间人劫持风险。确认过服务器确实重装过之后，再清除旧密钥、信任新密钥。

2.4 界面和传输设置在连接前顺手调一下

协议填对、端口正确、指纹确认后，FileZilla 的主界面通常就能看到两个窗格：左边是本地文件，右边是远程 Ubuntu 文件。有几个默认设置我每次都会改：

• 菜单“编辑” -> “设置” -> “界面”，把语言改为中文，日志显示改成详细模式，排错时能看到更多信息；
• “设置” -> “传输” -> “并发传输数”，从默认的 2 调到 4 或 6，批量传文件时明显更快；
• “设置” -> “连接” -> “FTP”，如果是走普通 FTP 连其他服务器，建议保持被动模式；连 Ubuntu 走 SFTP 时，这个选项不参与。
• “查看”菜单里打开“目录比较”，两侧文件不一致时会高亮显示，同步文件时非常好用。

这些调整不影响基本连接，但会直接影响后续使用体验。尤其是日志窗口，连接失败时里面每个Error:或Response:都是排查线索。

3. 上传下载、远程编辑与目录权限的实操细节

连接成功后，FileZilla 的用法看起来很简单：左边选本地文件，右键上传；右边选远程文件，右键下载。但实际用起来，有几个细节会让体验天差地别。

3.1 上传下载的操作逻辑与覆盖规则

最直接的方式是拖拽，左边文件拖到右边窗格就是上传，反方向就是下载。不过拖拽这种方式有个问题：遇到同名文件时，FileZilla 默认会弹窗问你是覆盖、跳过还是重命名。

如果你要传大量文件，不想一个一个点确认，可以在菜单“传输” -> “处理文件已存在”里设置规则，比如“如果文件大小不同则覆盖”，或者“始终覆盖”。这个弹窗逻辑在批量同步时很重要，好些人第一次传整个目录，弹窗弹了上百次，几乎崩溃，那就是没提前设默认策略。

我的习惯是设成“覆盖如果文件较新或大小不同”，这样既能避免重复下载旧文件，也不会漏掉真正有变化的文件。真传错了，FileZilla 的传输队列里保留记录，右键也能看历史。

并发传输数调大之后，上传一个包含几千个小文件的目录能明显感觉效率提升。但如果你的磁盘是机械硬盘或者网络很慢，并发太高反而会互相拖累，稳妥起见普通电脑 4 并发就够了。公网慢速网络下，我甚至会降到 2。

FileZilla 还有“限速”功能，在“编辑” -> “设置” -> “速度限制”里，可以按时间段限制最大上传下载速度。如果这台 Ubuntu 是生产服务器，你想传个大文件又不影响其他人访问，把自己限速到几百 KB/s 是基本礼仪。

3.2 远程编辑：改服务器配置文件最顺手的姿势

FileZilla 有一个被很多人忽略的功能：右键远程文件，选择“查看/编辑”。它会把这个文件下载到本地临时目录，用你本地的编辑器打开，你改完后保存，FileZilla 检测到本地文件变化，会问你是否将改动上传回服务器。

这个流程用来改配置文件非常舒服。比如你想改 Ubuntu 上的 Nginx 配置或者 Python 脚本，不用先在本地改完再上传，也不用在终端里用 vim 费劲，直接在本地编辑器里改，保存确认上传就行。

不过有个细节要注意：FileZilla 默认会用系统关联程序打开文件，Windows 下很可能关联的是记事本。记事本对 Linux 的换行符和 UTF-8 编码支持不够好，改完可能会出现奇怪问题。我一般会把“设置” -> “文件编辑”里的默认编辑器改成 VS Code 或 Notepad++，并勾选“跟踪修改过的文件”。

另外，改远程配置文件之前，强烈建议先右键文件 ->“下载”一份到本地备份。改坏了还能救回来。特别是/etc/ssh/sshd_config这种文件，改错了可能导致 SSH 服务直接起不来。

3.3 目录列表报错的传输模式问题

连接没问题、但远程目录列表一直刷不出来，这也是高频问题。如果你严格按前面的步骤用 SFTP 连 Ubuntu，这类问题很少出现。但如果你的使用场景是连接某些老旧的 FTP 服务器，就会碰到“无法读取目录列表”的报错，原因是 FTP 主动模式/被动模式没配对。

简单解释一下：主动模式下，客户端连上服务器 21 端口后，服务器主动去连客户端的一个随机端口传数据；被动模式下，服务器开一个随机端口等客户端来连。家用宽带、虚拟机和大多数路由器环境，主动模式经常被防火墙拦掉，所以现代 FTP 客户端默认都是被动模式。

FileZilla 里对应设置是“设置” -> “连接” -> “FTP” -> “被动模式”，默认开启。连不上或者列表刷不出来时，可以在这里切换“主动模式”再试。但最后还是建议直接走 SFTP，前面说过，它在设计上压根没有主动被动这个烦恼，所有数据都走同一个已加密的 22 端口连接。能在 2025 年还坚持用明文 FTP 的场景，我是真想不到几个。

3.4 普通用户上传到 /var/www 权限不足，别上来就 chmod 777

代码写到一半，想把网站文件传到 Ubuntu 的/var/www/html目录下，结果 FileZilla 报“Permission denied”。这个场景太常见了。

原因很简单：/var/www默认属于 root 用户，你的普通系统用户没有写权限。很多人这时候的第一反应是chmod 777，直接全网公开写权限，这是最省事但也是最糟糕的解法，相当于把这台机器的大门钥匙挂在了门框上。

按优先级，我建议这样解决：

• 如果网站目录允许，把你的用户加入www-data组，并给目录设置组写权限：

sudo usermod -aG www-data $USER sudo chown -R root:www-data /var/www/html sudo chmod -R 775 /var/www/html

修改完组后要重新登录一次 Ubuntu，组权限才会生效。之后 FileZilla 就能正常写入，其他用户仍然没有写权限，安全性比 777 高一个量级。

• 如果是个人开发机，干脆把目录所有者直接改给你自己：

sudo chown -R $USER:$USER /var/www/html

简单直接，适合自己一台机器折腾的情况。缺点是如果这台机器要给多用户用，其他用户只能改属于自己组的文件，共享协作会麻烦一些。

• 如果你确实需要临时改文件，又不想动整个目录的权限，可以只对当前文件用 ACL：

sudo setfacl -m u:$USER:rwx /var/www/html

这是最精细的做法，也是我线上环境里用得最多的方式。普通用户只能操作被授权的路径，其他目录一律动不了。

提示：任何情况下，不要为了图省事给 Ubuntu 的系统目录或网站根目录执行chmod -R 777。一旦服务器暴露在公网，这种权限配置几乎等于欢迎别人进来写 webshell。

4. 连不上的高效排查链路：从症状到根因一次走完

FileZilla 连 Ubuntu 这种看起来很简单的操作，报错方式五花八门。很多人一遇到报错就慌，到处重新装软件，其实大部分问题都能靠一条清晰的链路定位出来。我把常见的报错按症状分类，再给一条“从上到下”的排查顺序。

4.1 先分清症状：超时、拒绝、认证失败、列表失败

先对照表格确定问题在哪个层面，再往下查，效率会高很多。

4.2 从终端到服务的逐层排查

第一层，确认 Ubuntu 的 IP 是否正确。在 Ubuntu 终端执行ip -4 addr show，把实际 IP 和 FileZilla 里填的主机名对比。虚拟机用户注意检查网卡状态，克隆的虚拟机经常出现 IP 变了但客户端里还填旧地址的情况。

第二层，确认 SSH 服务在跑。执行：

systemctl status ssh sudo ss -tlnp | grep :22

没在监听就把服务拉起来：sudo systemctl restart ssh。Ubuntu 里如果看到服务状态是failed，再用journalctl -u ssh -n 30看最近日志，多半是配置写错了，比如 sshd_config 里有非法参数。

第三层，确认防火墙没拦。sudo ufw status看 22 端口是否放行。如果你用的是云服务器，还要去云控制台的安全组里放行 22 端口。我自己就遇过一次：Ubuntu 本地防火墙全开，SSH 服务也在跑，但云安全组没放行，外部永远连不上，这是最容易被忽略的一层。

第四层，VM 网络模式。虚拟机里装 Ubuntu 连不上时，检查是 NAT 还是桥接。NAT 模式下宿主机能连，局域网其他电脑未必能连；桥接模式下要确认虚拟机和宿主机在同一个网段。Windows 防火墙也可能拦 SFTP 出站，虽然少见，但排查时别排除。

4.3 翻日志定位认证类问题

认证失败这个报错最让人痛苦，因为它原因非常多：密码输错、用户不存在、SSH 配置里禁用了密码登录、甚至用户 shell 异常登录不上。

遇到认证失败，不要反复试密码，直接去 Ubuntu 看日志：

sudo tail -n 50 /var/log/auth.log

日志里会记录每次 SSH 登录尝试的结果。常见的几种行：

• Failed password for user from xx port xx ssh2：密码错误，继续检查输入；
• Connection closed by authenticating user xx：客户端拿到了连接但认证未完成，可能是服务器要求密钥登录但客户端在输密码；
• invalid user xx：用户名不存在，检查大小写和拼写；
• user is not allowed to authenticate：sshd_config 里可能设置了AllowUsers白名单，当前用户不在里面。

我自己排查认证问题时基本不猜，打开这个日志看三秒就能锁定方向。比在 FileZilla 里反复重试实在得多。

4.4 老旧加密算法不兼容：No compatible algorithm

如果你连接的是比较老的 Ubuntu 系统（比如 16.04 前后），或者服务器 sshd 配置里默认禁用了 ssh-rsa 签名算法，FileZilla 可能报类似“No compatible algorithm”的错误。这不是密码错，而是新版客户端和老服务端算法对不上。

解决办法分两边。只改客户端最简单：FileZilla 菜单“设置” -> “SFTP”，可以添加或编辑密钥文件，同时修正加密算法配置。如果你有服务器的操作权限，更彻底的办法是在 sshd_config 里允许旧的 ssh-rsa：

# 仅当服务器确实需要兼容老客户端时才开启 PubkeyAcceptedAlgorithms +ssh-rsa

然后重启 SSH 服务。不过这种兼容性配置能不开就不开，老算法等于老漏洞。更推荐的是把 Ubuntu 升级到受支持的新版本，顺便把密钥换成 ed25519。

4.5 把问题“隔离开”再动手

最后强调一个排查思路：FileZilla 连接失败时，先不用盯着 FileZilla 里的报错猜。用终端里的 SSH 客户端做一次最小化测试，比如：

ssh 用户名@IP

如果终端能登录，说明网络、SSH 服务、账号密码都没问题，那就是 FileZilla 侧配置的事；如果终端也登录不了，恭喜，问题在 Ubuntu 或网络，继续往上翻。这一步能帮你把问题一分为二，避免在两边反复横跳。我远程帮人排查时，几乎每次都让他们先跑这条命令，效率极高。

5. 用久了必然碰到的进阶问题：密钥登录、root 策略与锁定 SFTP

等你用 FileZilla 连 Ubuntu 连顺手了，大概率会开始考虑几个新问题：密码老要输，能不能一劳永逸？自己电脑丢了/服务器被扫怎么办？能不能让某个账号只能传文件，不能登录 Shell？

这节聊的正是这些。属于纯经验向的内容，我用得最多，也最值回票价。

5.1 用密钥登录替代密码，一劳永逸还更安全

密钥认证的原理是：服务器保存你的公钥，客户端保存私钥，连接时通过数学签名证明身份，整个过程不传输密码。密钥比密码长得多，也几乎没有暴力破解的可能。

在 Ubuntu 上生成密钥：

ssh-keygen -t ed25519 -C "filezilla desktop key"

一路回车会在~/.ssh/下生成两个文件：id_ed25519是私钥，id_ed25519.pub是公钥。然后把自己的公钥安装到服务器上：

ssh-copy-id 用户名@Ubuntu的IP

这个命令会把你的公钥写到服务器~/.ssh/authorized_keys里。之后在 FileZilla 的站点管理器里，把“登录类型”改成“密钥文件”，指明私钥文件路径，连接时就不需要密码了。

如果用的是 Windows，FileZilla 新版能直接读取 OpenSSH 格式的私钥，也就是id_ed25519这个文件。老版本可能要求 PPK 格式，那就用 PuTTYgen 把 OpenSSH 私钥转换成 ppk 再加载。还有一点，私钥文件不要放到被网盘同步的目录里，它相当于你家的钥匙，泄露了比密码泄露还严重。

密钥配置好之后，如果你确认不再需要密码登录，可以在 sshd_config 里加一句：

PasswordAuthentication no

这样服务器只接受密钥认证，密码暴力破解直接失效。注意改之前一定先测试：保持一个终端 SSH 会话不关，用密钥登录确认没问题，再重启 sshd。要是新会话连不上，你还有后路可走。

5.2 root 登录 SFTP：能不开就别开

Ubuntu 默认没有为 root 设置密码，安装过程中建立的第一个用户拥有 sudo 权限，日常用这个普通用户足够了。但总有人想用 root 直接连 FileZilla，图省事。

我的建议是：root 直接登录这件事，能不开就不开。默认 Ubuntu 安装的时候 root 没有密码，你要强行开 root 登录，得先sudo passwd root给他设一个密码，这等于给服务器树了一个高权限靶子。一旦密码泄露，对方拿到的就是整台机器，而不是普通用户。

如果你确实有需要，比如本地虚拟机里做测试，至少做两件事：一是禁止 root 密码登录，只允许密钥登录，在 sshd_config 里保持：

PermitRootLogin prohibit-password

二是用AllowUsers白名单限制能登录的账号：

AllowUsers yourname

这样就算知道 root 密码，也无法用密码登录；就算你有密钥，也得先通过用户名白名单这一关。两个条件同时满足才能登进来。

如果你只是在做网站文件管理，需要 root 权限才能写入某些目录，更推荐回看第 3 章的目录权限方案，把需要的目录授权给普通用户，而不是让 root 满天飞。

5.3 把账号锁成纯 SFTP，只传文件不登录 Shell

生产环境里最常见的需求是这样：给合作的同事开一个账号，只能往指定目录传文件，不能 SSH 登录 Shell，不能看系统其他文件。这用 SSH 的功能就能做到，不用单独装别的软件。

先在 Ubuntu 上建一个组，比如sftp_only，再建一个用户并加入这个组：

sudo groupadd sftp_only sudo useradd -m -g sftp_only -s /usr/sbin/nologin sftpuser sudo passwd sftpuser

重点是把用户的 shell 设为nologin，这样就算猜到密码也不能登录 Shell。然后在/etc/ssh/sshd_config末尾加一段：

Match Group sftp_only ForceCommand internal-sftp X11Forwarding no AllowTcpForwarding no ChrootDirectory /home/sftpuser

这段配置的意思是：凡属于sftp_only组的用户，连接后只能使用 SFTP，并且被限制在自己的 home 目录里。重启 SSH 服务后生效：

sudo systemctl restart ssh

注意ChrootDirectory对目录权限有要求：被 chroot 的根目录不能由普通用户可写，否则 sshd 会拒绝连接。所以如果根目录指向/home/sftpuser，需要把该目录 owner 设为 root，再在下面建一个用户可写的子目录，例如/home/sftpuser/files。FileZilla 连接后看到的就是这个受限空间，只能在里面传文件，系统其他部分完全不可见。这个方案在纯 Linux 环境下非常利落，这也是我在多台服务器上摆控制权限时的默认方案。

5.4 如果客户端也想装在 Ubuntu 本机

标题是“FileZilla 连接 Ubuntu”，但反过来，Ubuntu 本机也有 FileZilla 客户端，用于连接其他 Linux/Windows 或网络存储。Ubuntu 上的安装更简单：

sudo apt update sudo apt install -y filezilla

装完会在应用菜单里看到 FileZilla。用法和 Windows 版几乎一样，同样支持 SFTP、FTP、站点管理器、队列、远程编辑。唯一需要注意的是 Ubuntu 的 Wayland 环境和高分屏适配，个别机器上会有点模糊，问题不大，不影响功能。

我自己的习惯是 Ubuntu 桌面端日常直接用内置文件管理器连 SFTP 也能解决一部分需求，但真正要批量传文件、验证目录结构时，还是 FileZilla 高效。毕竟它能记住站点、支持并发传输和目录比较，这些是文件管理器给不了的。

最后分享一个我养成的习惯：每次新装一台 Ubuntu，先装 openssh-server、生成密钥、写公钥、改 sshd 配置并测试连接，整套流程十分钟左右。之后无论是 FileZilla 传文件、终端管理，还是自动化脚本走 sftp，全部基于这同一套配置，不用再为“连不上”操第二次心。如果你只是刚接触 Ubuntu，也不用急着一次全搞完，把前面第 1 章的连接跑通、能把文件传上去，剩下的密钥和权限方案完全可以等用得多了、踩过坑之后再回来照