前段时间一个朋友找我，说他每次给服务器传文件都要输入密码，而且用的还是那种明文传输的古老协议，总担心被人截获。我直接让他换成了SFTP，配上FileZilla这个客户端，再帮他配了一套密钥认证，弄完之后他感叹说：原来传输文件可以这么省心。今天就把这套完整的配置过程写出来，从零开始，把服务端配置、客户端连接、密钥认证整个链路都梳理一遍，给那些想彻底搞定Linux服务器文件传输的朋友一个可以直接照着操作的手册。
这篇内容适合谁看？一是刚接触Linux服务器，还在用密码登录、用FTP传文件的新手；二是已经用了SFTP但还在手动输密码，想升级成免密登录的效率党；三是在公司管着多台服务器，需要规范化登录方式的运维同学。全文围绕Ubuntu服务器和FileZilla客户端展开，把每一步的背景逻辑也讲清楚，方便你以后遇到变种问题时自己排查。
1. 先别急着装软件：理清SFTP到底解决什么问题
1.1 为什么不是FTP，而是SFTP
FTP（文件传输协议）诞生于上世纪七十年代，那个年代网络环境单纯，没人会想到有后来如此普遍的中间人攻击和数据窃听。FTP有两个致命硬伤：第一，它传输数据和控制信息用的不是同一条通道，控制走21端口，数据又单独开一条端口，这让防火墙配置变得异常痛苦；第二，用户名和密码在网络上几乎是裸奔，稍微在局域网里抓个包就能看到明文账号密码，传输的文件内容也是明文的。
而SFTP（SSH File Transfer Protocol）虽然名字里有File Transfer，但它不是FTP的升级版，而是完全基于SSH协议重新设计的文件传输协议。它默认走22端口，不需要额外打开数据端口，所有流量都被SSH加密通道包裹，用户名、密码、文件内容全程加密。这里有个很多人混淆的点需要说清楚：SFTP和FTPS不是一回事。FTPS是给传统FTP强制套上SSL/TLS层，本质还是FTP；SFTP则是SSH协议族的文件传输子协议，两者技术路线完全不同，配置方式也不同。
还有一个实际优势：只要服务器开了SSH服务，就等于同时开了SFTP能力，不需要单独安装FTP软件，也不需要为文件传输单独放行防火墙端口。这套方案的安全性和简洁性，是传统FTP完全比不了的。
1.2 FileZilla + Ubuntu 这套组合优势在哪
FileZilla是开源世界里非常老牌的图形化FTP/SFTP客户端，跨平台，Windows、macOS、Linux都有客户端，个人使用完全免费。选择它做SFTP客户端有几个很实际的原因：
第一，它对密钥认证的支持做得比较好。新版FileZilla已经可以直接加载OpenSSH格式的私钥文件，不像早期版本必须先把私钥转换成PPK格式才能用，省掉了不少麻烦。
第二，多标签、多站点管理做得顺手。我管理好几台服务器，用站点管理器把每台服务器的地址、端口、登录方式、本地同步目录都存好，换服务器就像切换浏览器标签一样方便。
第三，传输队列机制成熟。大文件批量上传下载时可以排队执行，中途断线还能续传，配合文件存在性校验，实际传输的可靠性比很多人想象的好。
服务端选Ubuntu也是基于同样的务实理由：它是目前社区文档最丰富、用户基数最大的Linux发行版之一，遇到任何奇怪问题基本都能搜到现成解决方案；包管理器稳定，安装OpenSSH服务一个命令搞定；而且它对SSH配置的默认策略相对保守，没有那么多花哨的安全功能干扰排查。
1.3 动手前的检查清单
配置之前建议先花两分钟确认三件事，避免配置过程中反复碰壁：
- Ubuntu服务器的SSH服务是否已安装并运行。没装就执行后面章节的安装命令；装了但没启动，先确认启动状态。
- 你能用密码通过SSH登录这台服务器。如果连密码登录都不通，后面所有配置都没意义。先排除网络不通、端口被封、IP错误这些问题。
- 防火墙规则是否放行了22端口。默认情况下UFW可能只放行了OpenSSH服务名，如果服务器用的是云厂商自带的安全组，还要检查外部防火墙。
这三件事确认完毕，整套配置流程就顺畅了。
2. Ubuntu服务端基础配置：让SSH服务先跑起来
2.1 安装与启动OpenSSH服务
在Ubuntu上安装SSH服务其实只有一个命令的事。打开终端，执行：
sudo apt update sudo apt install openssh-server -y安装完成后，用systemd管理这个服务：
sudo systemctl enable ssh --now sudo systemctl status ssh这里解释一下为什么是enable ssh --now：enable是设置开机自启，--now是立即启动当前服务，两个动作合并成一个命令执行。看到状态输出里有active (running)，说明服务已经跑起来了。
如果系统提示找不到openssh-server包，先执行sudo apt update刷新软件源缓存。Ubuntu的软件源有时候会滞后，初次安装时执行更新是惯例操作。
服务运行后验证端口监听情况：
sudo ss -tlnp | grep :22看到类似LISTEN 0 128 0.0.0.0:22 0.0.0.0:*的输出就说明22端口正常监听。这里顺带提一句：ss命令是现在Linux系统推荐的网络状态查看工具，老掉牙的netstat在新版本里可能没装，优先用ss。
2.2 sshd_config 里你一定要看的几个参数
SSH服务端的主配置文件是/etc/ssh/sshd_config，默认配置已经能用，但有几个参数值得手动确认或者调整，直接影响后续使用体验和安全级别：
Port 22：SSH监听端口。默认22是标准实践，但如果你处于公网环境，又特别担心扫描攻击，可以改成高端口（比如22022）。改完端口要注意防火墙放行新端口，同时这里强烈不建议完全禁用22端口，不然容易把自己锁在外面。PasswordAuthentication yes：是否允许密码登录。做密钥认证之前必须保持为yes，否则下面步骤无法进行。等密钥验证通过后再改成no。PubkeyAuthentication yes：是否允许公钥认证。默认是yes，但如果之前有人改过配置，确认一下没被关掉。PermitRootLogin prohibit-password：是否允许root直接登录。这里是个关键点：prohibit-password表示禁止root用密码登录，但允许root用公钥登录。如果你打算用root账号做密钥免密，保持这个值就行；如果你确定要用root密码登录，则改PermitRootLogin yes，但我不建议这么做，原因是root密码一旦泄露等于把整台机器拱手让人。
多用户服务器还有一个参数建议加上，可以有效限制谁能通过SSH登录：
AllowUsers alice bob这个配置只允许alice和bob这两个用户通过SSH登录，其他账号即使密码正确也会被拒绝。注意，如果配置里有多个账号，用空格分隔。
每次修改sshd_config之前，先备份：
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak改完配置后先做语法检查，再用systemd重载服务。新版OpenSSH支持直接测试配置是否正确：
sudo sshd -t sudo systemctl reload sshsshd -t如果输出为空，说明配置语法没问题；有报错就仔细看具体哪一行出了问题。
2.3 测试基础连通性
服务端配置完成后，先用最简单的密码登录方式测试一遍链路。如果你用的是Windows本机，直接运行FileZilla，按后面的步骤配置；如果手边有Linux或macOS环境，也可以用命令行验证：
ssh username@server_ip能正常登录、执行命令、退出，就说明SSH服务基础链路是通的。这一步别跳过，很多人在密钥认证配置了半天发现连不上，最后排查半天才发现是服务端防火墙压根没放行22端口。
3. FileZilla客户端连接：用密码认证跑通全流程
3.1 新建站点时的几个关键选择
打开FileZilla主界面，点击顶部菜单的“文件” → “站点管理器”（或者直接按快捷键Ctrl+S），在弹出的窗口里点击“新站点”，然后你会看到一列需要填写的配置项。这里最容易翻车的地方集中在三个选项：
- 协议：默认是“FTP - 文件传输协议”，一定要手动改成“SFTP - SSH文件传输协议”。很多人连接失败就是忘了改这一项，FileZilla还在往21端口的传统FTP协议上面尝试，自然连不上。
- 主机：填服务器IP或域名。这里提醒一下，千万别带
ftp://或者ssh://前缀，直接填裸IP或者裸域名。 - 端口：SFTP默认22端口，不用填。如果你在服务端改了SSH端口，这里填对应端口。
填写完主机、用户名和密码后，可以点“连接”测试。FileZilla首次连接SFTP会弹出一个未知主机密钥确认提示框，问你是否信任这台服务器的主机指纹。这一步很多人会被吓到，其实这是正常的安全机制：SFTP客户端首次连接时会接收服务器返回的主机公钥指纹，用于防止中间人攻击。确认这台服务器确实是自己的，勾选“始终信任该主机并继续连接”，然后点确认。
这里有一个安全细节值得说：如果之前连接正常，某一天突然弹出指纹变化提示，那就要警惕了，很可能是有人在你和服务器之间劫持了流量。正常服务器的SSH主机密钥不会随意变化，除非服务端重装过系统或者管理员手动重置了密钥。
3.2 登录成功后先做好两件事
成功连上服务器后，先别急着传文件，花两分钟把FileZilla的默认设置调整到合适状态。
第一件事：调整默认远程目录。在站点管理器窗口的“高级”选项卡里，把“默认远程目录”设置成你常用的路径，比如/home/username/www或者/srv/data。这样每次连接直接落地到工作目录，省掉每次手动cd的麻烦。
第二件事：设置本地目录。同样是“高级”选项卡，“默认本地目录”选一个常用的本地文件夹。这个设置配合后续的同步浏览功能，能让文件传输效率明显提升。FileZilla菜单栏“视图”里有个“同步浏览”选项，开启后你切换到服务器任意目录，左侧本地目录也会自动切换到设置的本地根目录下的对应路径。
3.3 传输模式和数据类型的正确选择
FileZilla界面下方有三个跟传输模式相关的选项，分别是传输模式（协议层面的）、数据类型（ASCII/二进制）、并传输的并发连接数。
传输模式那里选“主动”还是“被动”，在SFTP场景下其实不敏感，因为SFTP只有一个端口，不像FTP那样需要额外的数据连接。保持默认即可。
数据类型这里注意一下：如果服务器上存的都是图片、压缩包、文档这类二进制文件，选择“二进制”模式；如果经常编辑程序源代码或者纯文本配置文件，选“ASCII”模式会在传输时自动转换换行符。但对我个人来说，直接从菜单栏“传输” → “默认文件类型”里选“二进制”更省心，因为即使遇到UTF-8编码的纯文本文件，二进制模式也不会破坏内容，顶多是没有自动转换换行符而已。
并发连接数：站点管理器“传输设置”选项卡里默认并发连接数是2，如果经常批量传小文件，可以适当调大到4-6，能明显加速小文件的往返开销。要说明的是，并发数不是越大越好，开太多连接反而会让服务器端CPU上下文切换开销变大，对小规格服务器反而拖慢速度。
4. 密钥认证实战：从生成密钥到完全免密
4.1 为什么推荐密钥认证
密码认证最大的问题是密码本身可猜测、可复制、可爆破。哪怕你设置了一个足够复杂的密码，只要被某个中间环节记录泄露过一次，这台服务器就等于被人夺去了远程控制权。而密钥认证基于非对称加密，通信双方各持有一把不同的密钥，公钥可以公开随便给任何人，私钥永远留在自己手里，理论上暴力破解的成本高到不现实。
除此之外还有体验上的改善：配好密钥之后，登录服务器不再需要手动输密码。尤其配合FileZilla保存了私钥路径，每次打开软件直接连接，全程不中断操作流。如果你管理着十几台服务器，每台服务器都存着你的公钥，那体验差异就更明显了。
4.2 生成密钥：选ed25519而不是默认的RSA
在Windows上打开命令提示符或者PowerShell，在Linux/macOS上打开终端，执行以下命令生成密钥对：
ssh-keygen -t ed25519 -a 100 -C "个人标识"选项讲解：
-t ed25519：指定密钥类型为ed25519。这是目前推荐的椭圆曲线数字签名算法，它的优势是密钥长度短（公钥也就68字节左右）、生成速度快、安全性高，被OpenSSH原生支持。没特殊兼容性要求，优先ed25519。-a 100：指定KDF（密钥派生函数）迭代次数。迭代次数越高，私钥文件被暴力破解的难度越大。默认可能是16次，手动提到100次对日常使用几乎无感知，但保护强度提升明显。-C "个人标识"：给公钥加一个备注，不参与加密逻辑。推荐写上自己的邮箱或者用途标识，方便将来在多台设备间管理公钥时一眼认出。
如果某些老系统不支持ed25519（理论上2005年以后的OpenSSH版本都支持），那就退回到RSA：
ssh-keygen -t rsa -b 4096 -a 100 -C "个人标识"生成过程中会询问私钥保存路径和口令（passphrase）。路径默认是~/.ssh/id_ed25519（如果选了rsa就是~/.ssh/id_rsa），直接回车用默认即可。口令这一项我建议留空。留空的话，私钥文件本身不设密码，连接时会直接读取私钥完成认证，这就是真正意义上的“完全免密”；如果你设了口令，那么每次连接还是要输一次口令，等于把密码从服务器端搬到了客户端，但好处是即便私钥文件泄露，别人也无法直接使用，安全性更高。
根据自己的实际权衡来做选择，但这篇文章目标是“完全免密”，后续步骤按口令留空来写。
生成完成后，~/.ssh/目录下会出现两个文件：id_ed25519（私钥）和id_ed25519.pub（公钥）。私钥文件一定要妥善保管，谁拿到私钥谁就能以你的身份登录所有配置过对应公钥的服务器。家里多人共用电脑的情况，最好把私钥文件权限收紧，后面会讲到。
4.3 把公钥部署到服务器
生成密钥对只是完成了一半，你需要把自己的公钥添加到服务器的授权列表里。服务器上正确的位置是登录用户的~/.ssh/authorized_keys文件。
最省事的方式是用ssh-copy-id工具：
ssh-copy-id -i ~/.ssh/id_ed25519.pub username@server_ip这个命令会要求输入一次服务器密码，验证通过后把公钥内容追加到服务器的authorized_keys文件里，顺便修正文件权限。但有个坑：Windows自带的PowerShell不提供ssh-copy-id命令，要么用Git Bash等Linux兼容环境，要么手动操作。
手动放置公钥的步骤如下：
- 在本地查看公钥内容：
cat ~/.ssh/id_ed25519.pub通过FileZilla或者密码登录SSH，进入服务器。
在服务器上执行：
mkdir -p ~/.ssh chmod 700 ~/.ssh echo "这里贴你复制过来的公钥内容" >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys注意，公钥内容是一整行，以ssh-ed25519 AAAA...开头，一定要复制完整，不要带换行符。追加之后如果之前在服务器上已经有过别的公钥，会用>>符号把新公钥追加在文件末尾，不会覆盖已有内容。
权限检查这一步对新手来说是绕不开的坑。SSH服务在读取authorized_keys时对文件权限非常敏感：如果~/.ssh/authorized_keys对其他用户可写，SSH会直接忽略这个文件，认证就不可能成功。所以目录设置700，文件设置600，这是标准规定。很多人密钥配置后一直要求输密码，问题九成出在这里。
部署完后，在服务器本机测试一下是否能免密登录：
ssh -i ~/.ssh/id_ed25519 username@server_ip如果你能直接登录不提示输密码，就说明公钥部署成功。如果还是提示要密码，优先检查服务器的~/.ssh目录权限和服务端日志（后续章节详解）。
4.4 FileZilla导入私钥并验证
公钥部署到服务器后，接下来配置FileZilla，让它使用你的私钥进行认证。
打开FileZilla，菜单栏“编辑” → “设置”，在左侧导航栏找到“连接” → “SFTP”，然后点击“添加密钥文件”。在弹出的文件选择器里，找到本机的私钥文件（如果你用的是Windows默认路径，一般在用户目录的.ssh文件夹下，文件名是id_ed25519），导入。注意别选成.pub的公钥文件。
老版本的FileZilla会弹窗提示你“不支持当前的密钥格式，需要转换”。如果你遇到这个弹窗，意味着当前FileZilla版本太老，不能直接加载OpenSSH格式的私钥。解决办法是用PuTTY自带的puttygen工具把私钥转换成PPK格式，再重新导入。新版本FileZilla（3.58以上）已经原生支持OpenSSH私钥直接导入，不需要转换。
私钥导入完成后，回到站点管理器，把当前站点的“登录类型”从“正常”改成“密钥文件”。如果私钥已经导入，这里会有一个下拉列表，选中刚才导入的密钥文件。没出现的话，检查一下是否走错了设置页。
这时候再点“连接”，如果一切顺利，服务器就能直接进入工作目录，全程无密码。第一次连接时服务器主机密钥确认提示可能再次出现，正常情况点确认即可。
为了进一步确认“免密”是否彻底生效，断开当前连接，重新连接一次。全程只要不弹密码输入框，就说明密钥认证已在你实际使用的客户端上跑通了。
4.5 最终加固：禁用密码登录
密钥验证成功后，最后一个安全收尾动作是禁用服务器的密码登录。编辑服务端配置文件：
sudo nano /etc/ssh/sshd_config找到PasswordAuthentication这一行，把值从yes改成no。确认没有拼写错误后，执行配置重载：
sudo sshd -t sudo systemctl reload ssh这里必须强调一下操作顺序：一定要在密钥登录确认可用之后再禁用密码登录，否则一旦私钥有问题或FileZilla配置出错，密码登录也被关闭，你就被彻底锁在服务器外面了。如果服务器是云服务器，至少保留云厂商控制台里的远程登录或VNC入口（比如查看VNC终端），这是最后的应急通道，关键时刻能救命。
禁用密码登录后，再测试一下FileZilla连接是否正常。如果一切正常，恭喜你，这套免密密钥体系已经完整上线。
5. 常见问题与排查实录：我踩过的坑，你直接避开
配置SSH和SFTP的过程中，有几个问题几乎每个人都会遇到。这里列一张排查速查表，比对着操作能省很多时间。
5.1 问题速查表
| 症状 | 可能原因 | 解决办法 |
|---|---|---|
| FileZilla连接超时 | 服务器防火墙未放行22端口 | 检查服务器UFW状态、云安全组，确保22端口允许外部访问；网络本身不通则检查IP和路由 |
| 密码正确但登录失败 | AllowUsers限制了用户，或PAM配置问题 | 检查sshd_config里的AllowUsers是否包含该用户，必要时查看/var/log/auth.log日志 |
| 密钥部署后仍需密码 | authorized_keys文件权限过宽 | 检查~/.ssh目录为700，authorized_keys为600，然后重载SSH服务 |
| FileZilla报错“找不到密钥文件” | 私钥路径配置错误或私钥格式不支持 | 确认私钥路径正确；老版本FileZilla需要将OpenSSH密钥转换为PPK格式 |
| 连接被服务器立即关闭 | 服务端配置了MaxSessions过小，或IP被Fail2Ban封禁 | 检查MaxSessions参数，查看fail2ban-client status sshd封禁列表 |
| 登录后看不到某些目录 | 用户无权限访问该目录 | 检查用户对目标目录是否有执行和读取权限，必要时sudo usermod -aG groupname username加入权限组 |
| 中文文件名乱码 | 字符集设置错误 | 站点管理器 → 字符集 → 强制使用UTF-8，或根据服务器实际字符集选择对应编码 |
5.2 查日志比什么都重要
遇到SSH相关疑难杂症，第一原则是查服务器日志。SSH的认证日志通常记录在/var/log/auth.log里，这是Linux下排查认证类问题最有力的工具：
sudo tail -f /var/log/auth.log然后从你本机重新发起一次SSH连接，日志里会出现对应的认证记录。比如看到Authentication refused: bad ownership or modes for directory，那就是目录权限问题；看到Failed password for invalid user，那就是用户名错误或该用户被禁止登录；看到Connection closed by authenticating user，可能是密钥有问题或者私钥公钥不匹配。
日志信息是英文的，但不难读，关键字就那么几个：refused、failed、invalid user、connection closed。看多了自然就驾轻就熟了。
5.3 一个很容易忽略的细节：私钥文件权限
前面讲了服务器端authorized_keys的权限，但客户端私钥文件的权限同样不能忽视。如果你在Linux/macOS上用命令行调试，私钥文件权限太宽松（比如644）会被OpenSSH直接拒绝使用：
chmod 600 ~/.ssh/id_ed25519Windows用户则注意在文件属性里，尽量把私钥文件访问权限限制在当前用户。否则系统里其他用户如果能够读取这份私钥，配合暴力破解，等于把你的服务器也暴露了。
5.4 改端口后别忘了同步配置
有朋友为了减少扫描攻击，把SSH端口从22改成了2022。结果FileZilla连不上，排查了半天，发现是云服务商安全组只放行了22端口，而本地的FileZilla站点配置里端口也还是默认的22。所以如果你改了服务端端口，记住要同步做两件事：
- 修改服务器防火墙放行新端口：
sudo ufw allow 2022/tcp - FileZilla站点配置里，把端口改成一致的端口值
顺带一提，如果你用密钥认证的时候还改了SSH端口，FileZilla的SFTP设置页里也要在“端口”栏填上对应端口，别只改了服务器和防火墙。
5.5 备份与回退方案
最后聊一个实际操作中非常重要的点：任何SSH配置修改都应该带着“可回退”的心态去做。
建议在首次修改sshd_config之前备份原文件：
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak后续如果配置改崩了，可以用备份恢复：
sudo cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config sudo systemctl reload ssh我自己的习惯是每次改动前都做一次备份，备份文件名带上日期，比如sshd_config.bak.20250601，这样一段时间后能追溯是哪一天的改动出问题。SSH配置出问题导致的无法登录，几乎是运维场景里最常见的“自锁”事故，备份和回退就是你救命的保险绳。
6. 实操过程总结与个人经验
整套配置走下来，核心就几步：装好SSH服务，让FileZilla能用密码连上；生成ed25519密钥对；把公钥放到服务器的authorized_keys；FileZilla换成密钥登录；最后才考虑关闭密码登录。这个顺序别弄反，任何一步跳着走，都会在后头埋坑。
我在实际项目里管理服务器时，一个常用的习惯是给每台服务器单独生成一对密钥，私钥按服务器名区分文件名保存，比如web-server-prod、database-server-backup这套命名风格。不同服务器用不同密钥，即使某台服务器的私钥泄露了，其他服务器不受影响。如果你只有一台服务器，用默认的id_ed25519就行；服务器多了以后，这个习惯能省很多事。
最后再分享一个小技巧：把FileZilla的站点管理器配置做一个导出备份。菜单栏“文件” → “导出”，可以导出包含所有站点配置的XML文件，也可以勾选导出密码。重装系统后导入一下，所有服务器配置又全部回来了。这个操作比对着文档重新录一遍节约的时间不是一点半点。
如果你手里有几台服务器一直在用密码登录，我真心建议抽个下午把这套密钥配置走一遍。一次性投入的时间换来的是一劳永逸的免密体验，还有断掉密码爆破这条路带来的安全感。没有哪套方案是绝对完美的，但从实用性、投入产出比和安全性来看，SFTP加密钥认证，至今仍是我给身边人的第一默认推荐。
