从理论上它们提供的安全性 FTPS 和 SFTP 是相似的。在实践中，您有以下优点和缺点：

• 使用 FTPS 客户端应用程序通常无法正确验证证书，这实际上意味着中间人是可能的。而使用 SFTP，用户只需跳过有关主机密钥的信息并接受任何内容，因此结果是相同的。
• 但是具有更多知识的用户和管理员可以正确使用 SSH 密钥并将它们也用于身份验证，这使得 SFTP 与使用密码相比更容易使用。如果密码完全被禁止，那么这也更安全，因为暴力密码攻击不再可能。
• FTP 使用动态端口进行数据连接，并且有关这些端口的信息在带内传输。当涉及到防火墙、NAT 或类似的东西时，这使得已经是普通的 FTP（没有 TLS）成为一场噩梦。使用 FTPS (FTP+TLS)，情况会变得更糟，因为防火墙上的控制连接帮助程序应用程序无法再找出需要打开的端口。这意味着要通过 FTPS，您需要打开大量不利于安全性的端口（*）。SFTP 要好得多，因为它只使用一个连接来进行控制和数据。
• FTP(S) 服务器通常提供匿名访问，而 SFTP 服务器通常不提供。一些 FTP(S) 服务器还提供伪用户，即来自同一数据库或类似数据库的用户，这些用户不是系统上的真实用户。如果您只有适当的用户，这并不重要。
• SFTP 使用 SSH 协议，您必须正确配置系统以仅允许 SFTP 访问，而不允许 SSH（终端）访问甚至 SSH 转发。使用 FTP 这更容易，因为 FTP 无论如何只能进行文件传输。

(*) 一些评论并不认为开放大量端口对安全性不利。因此，让我更详细地解释一下：

• FTP 使用单独的 TCP 连接进行数据传输。用于这些连接的端口是动态的，并且有关这些端口的信息在控制连接内进行交换。不知道当前正在使用哪些端口的防火墙只能允许有时可能会使用 FTP 的较宽端口范围。
• 这些端口需要允许从外部到内部的访问，因为在 FTP 被动模式下，客户端连接到服务器上的某个动态端口（即与服务器端防火墙相关），而对于 FTP 主动模式，服务器连接到客户端上的某个动态端口（相关用于客户端防火墙）。
• 为从外部到内部的无限制访问开放大量端口并不是人们通常认为的保护内部的限制性防火墙。这更像是在门上有一个大洞，窃贼可能会进入房子。
• 为了解决这个问题，大多数防火墙都为 FTP 使用“助手”，它们会查看 FTP 控制连接以确定需要为下一个数据连接打开哪些端口。一个例子是 iptables 的 ip_conntrack_ftp。不幸的是，使用 FTPS，控制连接（通常）是加密的，因此这些助手是盲目的，无法动态打开所需的端口。这意味着要么 FTP 不工作，要么需要一直打开大量端口。

系统管理员提出了一个有效点。 （但他的人际交往能力可能需要工作）

SSH 是一个复杂的协议，openssh 实现了很多功能。所有这些功能都提供了攻击向量，很难确定这些向量中没有一个是可利用的。

即使 openssh 没有错误（它不是），了解关闭不需要的功能的所有正确可能性，以及了解这些选项如何交互本身也需要付出巨大的努力。这些交互可能会因版本而异。

例如，考虑以下sshd_config代码片段，其目的是将某些用户限制为仅限 SFTP（我们甚至考虑将他们锁定到他们的主目录）：

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp

果然：

% ssh somehost
This service allows sftp connections only.
Connection to somehost closed.

可是等等...

ssh -N -L 9000:localhost:80 somehost

糟糕，我现在已将端口 80 转发somehost到主机上的端口 9000。这意味着我们可以连接到端口 80，somehost就好像我们来自本地主机一样。对端口 80 来说可能没什么大不了的，但是只在 localhost 上侦听的服务呢，例如管理服务或数据库呢？

这只是 TCP 转发。至少，SSH 还允许 X11 转发和 SSH-agent 转发，我什至不知道这两者的含义。

我们确实经常使用 ssh/sftp，因为就我们的情况而言，优势大于这些风险。但这是一个合理的担忧，不应掉以轻心。对于仅 sftp 就足够的用例，我们最终得到了这个：

Match Group sftponly
    ChrootDirectory %h
    X11Forwarding no
    AllowTcpForwarding no
    AllowAgentForwarding no
    ForceCommand internal-sftp

我们希望这足以确保仅sftp 访问，但我们不能完全确定。（欢迎提出建议；）

这两种协议都有优点和缺点，正如这篇比较文章中很好地解释的那样。

这就是说，由于该问题专门针对安全性，因此在选择在某些特定条件下最佳协议时应考虑一些因素。

FTPS和FTPES使用 SSL 或 TLS 来加密控制/数据连接。这些安全通道的主要优点是它们使用 X.509 证书，其中包含比简单密钥对（主机名、电子邮件地址、组织名称、ISSUER (CA)...）更多的信息，因此是更容易验证。但：

• SSL 1.0 , SSL 2.0 : 很久以前弃用 (不安全)
• SSL 3.0：最近因 POODLE 而被弃用
• TLS 1.0：不再接受 PCI 合规性
• TLS 1.1：缺少 TLS 1.2 的一些扩展，并且客户端支持有限，没有理由使用它
• TLS 1.2：当前标准，到目前为止被认为是安全/安全的

以上仅涵盖通道加密协议，然后是有关 FTP 协议本身的安全考虑。例如，SITE命令已被反复用于实施攻击，协议本身的固有设计需要在防火墙上打开和 NAT 多个端口（这可能成为管理的噩梦）。此外，大多数防火墙无法正确地对 FTP 数据连接进行 NAT，除非客户端请求并且服务器允许CCC（清除控制通道）通过运行未加密的控制连接来破坏部分安全性。

另一方面，我们有SFTP，它是SSH 的子系统。这里的主要挑战是 SSH 密钥“只是密钥”，它们不是由 CA 颁发的，并且其中不包含颁发者声明或密钥链，因此 SSH 服务器密钥必须得到客户端的明确信任。

有人可能会争辩说，将 SSH 服务器配置为仅允许 SFTP（无 shell、无命令、无转发隧道、无 X11）可能很困难。这实际上取决于：如果您正在运行 Linux 和 OpenSSH，这可能是真的，但是那里有大量的 SSH/SFTP 服务器使这种配置变得轻而易举，所以我不一定会将其列为潜在缺陷，除非 - 正如我所说 - 使用 Linux/OpenSSH。

然而，SFTP 的几个显着的附带优势包括：

• ECDSA 密钥交换：521 位 ECDS(X) 密钥在安全性方面相当于 15,360 位 RSA 密钥，签名计算所需 CPU 周期减少 9 倍
• 固有的前向保密性：SSH 协议可以在会话中重新协商实际的通道加密密钥，并提供固有的前向保密性，这与任何需要额外配置工作来完成此任务的启用 SSL/TLS 的服务器相反

所以，最终选择真的取决于你们，但是系统管理员所做的论点是公然无效的，如果有一个配置良好的现有 SFTP 服务器（如解释的那样），那么就没有理由（尤其是没有安全性-相关原因）切换到 FTPS（或 FTPES）。

许多人提出了关于两种协议之间差异的有效观点。但我认为就您的目的而言，问题实际上是“SFTP 足够安全吗？” 而不是“哪个更安全”？正如你所说，除了安全之外，你还有其他顾虑。

事实证明，这是一个难以解决的问题。SSH 已被广泛使用和广泛研究。没有已知的协议设计缺陷。但是，安全漏洞通常与协议无关，而与实现有关。毕竟，SMTP 本身并不“不安全”，而且设计相对简单，但 16 年前，常见的 SendMail 应用程序是软件安全性实施不善的典型代表之一，而且漏洞百出。

关键是，即使协议设计良好且简单，实现也可能是复杂的老鼠巢，添加功能和安全噩梦。

所以我认为这更多是关于选择一个好的实现而不是一个好的协议。两种协议都很好，两种实现都可能实现得很差。

我对 FTPS 并不完全熟悉，所以我不知道是否有任何受人尊敬的实现。然而，对于 SSH，OpenSSH 通常被认为是高质量的，并且从一开始就考虑到了安全性（特权分离等）。