從理論上講，它們提供的安全性FTPS和SFTP是相似的。實際上，您具有以下優點和缺點：

• 使用FTPS的客戶端應用程序通常無法正確驗證證書，從而有效地意味著中間的人是可能的。相反，使用SFTP，用戶只需跳過有關主機密鑰的信息並接受任何內容，因此結果是相同的。
• 但是，具有更多知識的用戶和管理員可以正確使用SSH密鑰，並將其也用於身份驗證，這樣一來，與使用密碼相比，SFTP更加易於使用。而且，如果完全禁止使用密碼，那麼這也將更加安全，因為不再可能發生暴力密碼攻擊。
• FTP使用動態端口進行數據連接，並且有關這些端口的信息會通過帶內傳輸。當涉及防火牆，NAT或類似設備時，這使本已普通的FTP（無TLS）成為噩夢。使用FTPS（FTP + TLS）時，情況變得更糟，因為由於控制連接的加密，防火牆上的輔助應用程序無法再找出需要打開哪些端口。這意味著要通過FTPS，您需要打開各種各樣的端口，這對安全性（*）不利。 SFTP更好，因為它僅使用單個連接進行控制和數據。
• FTP（S）服務器通常提供匿名訪問，而SFTP服務器通常不提供匿名訪問。幾個FTP服務器還提供偽用戶，即從同一數據庫或類似數據庫獲取的用戶，而不是系統上的真實用戶。如果只有適當的用戶，則沒關係。
• 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（甚至將其鎖定到其主目錄）：

 匹配組sftponly ChrootDirectory％h ForceCommand internal-sftp  

並且足夠確定：

 ％ssh somehost此服務僅允許sftp連接。 sed。 

但是請稍候...

  ssh -N -L 9000：localhost：80 somehost  

糟糕，我現在已經將 somehost 上的端口80轉發到了主機上的9000端口，這意味著我們可以連接到 somehost 上的端口80，就像我們來自本地主機一樣。端口80沒什麼大不了的，但是僅 僅在localhost上偵聽的服務（例如管理服務或數據庫）呢？

那僅僅是TCP轉發。至少， SSH還允許X11轉發和SSH代理轉發，我什至都不知道這兩者的含義。

我們確實大量使用ssh / sftp，因為就我們的情況而言，優勢大於這些風險。但這是一個有效的關注點，我們不應該掉以輕心。對於僅sftp就足夠的用例，我們最終得出了以下結論：

 匹配組sftponly ChrootDirectory％h X11Forwarding否AllowTcpForwarding否AllowAgentForwarding否ForceCommand internal-sftp  

我們希望這足以確保 just 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（這可能成為管理噩夢） ）。此外，除非客戶端請求並且服務器允許 CCC （清除控制通道），否則大多數防火牆都無法正確地進行FTP FTP數據連接的NAT，這會通過運行未加密的控制連接來破壞部分安全性。 >

另一方面，我們有 SFTP ，它是SSH的子系統。此處的主要挑戰是SSH密鑰是“公正密鑰”，它們不是由CA頒發的，也沒有包含頒發者聲明或密鑰鏈，因此SSH服務器密鑰必須由客戶端明確信任。

有人可能會認為將SSH服務器配置為僅允許SFTP（無外殼，無命令，無轉發隧道，無X11）可能很困難。這實際上取決於：如果您正在運行Linux和OpenSSH，那也許是正確的，但是那裡有大量的SSH / SFTP服務器使這種配置變得輕而易舉，所以我不必將其列為潛在的缺陷，除非-就像我說的那樣-使用Linux / OpenSSH。

SFTP的兩個顯著優勢包括：

• ECDSA密鑰交換：在安全性方面，一個521位ECDS（X）密鑰等效於一個15360位RSA密鑰，並且簽名計算所需的CPU週期減少了9倍
• 固有的前饋保密 ：與任何需要額外配置工作才能完成此操作的啟用SSL / TLS的服務器相反，SSH協議可以在會話中重新協商實際的通道加密密鑰，並提供固有的前向保密性。 li>

因此，最終的選擇實際上取決於您，但是sysadmin所做的論點公然無效，並且是否存在現有的SFTP服務器。配置正確（如所述），則沒有理由（特別是沒有與安全相關的原因）切換到FTPS（或FTPES）。

許多人提出了關於兩種協議之間差異的有效觀點。但是我認為出於您的目的，問題實際上是“ SFTP是否足夠安全？”而不是“哪一個更安全”？如您所說，除了安全性之外，您還有其他問題。

事實證明這是一個很難解決的問題。 SSH已被廣泛使用和廣泛研究。沒有已知的協議設計缺陷。但是，安全漏洞通常與協議無關，而與實現無關。畢竟，SMTP本身並不是“不安全的”，並且設計相對簡單，但是16年前，Commendon SendMail應用程序是實現軟件安全性不佳的典型代表之一，並且在其中存在一個又一個漏洞。

關鍵是，即使協議設計合理且簡單，實現也可能是複雜性，附加功能和安全噩夢的巢穴。

所以我認為更多的是選擇一個好的實現而不是一個好的協議。兩種協議都很好，而且兩種實現方式都可能執行不佳。

我對FTPS並不完全熟悉，所以我不知道它是否有任何受人尊敬的實現。但是，對於SSH而言，OpenSSH通常被認為是高質量的，並且從一開始就考慮到安全性（特權分離等）。

就像您一樣，我認為兩者與我在網上尋找差異時幾乎一樣。

但是，在現實生活中，這是另一回事了。以下是我的經驗：

1. 對於我的NAS，我開啟了3個月的FTPS功能。防火牆設置還可以。我只需要打開FTP端口和FTPS傳輸使用的其他端口。到目前為止，還算不錯，沒什麼大不了的。

2. 三個月後，我想，嗯，我也可能同時啟用了SFTP協議，因為它更常見並且更容易實現管理。然後發生了一些有趣的事情。打開SFTP端口10分鐘後，我的NAS遭受了一些蠻力攻擊。嘗試輸入密碼失敗10次後，NAS會自動阻止攻擊IP，並通過電子郵件通知我。想像一下，如果攻擊者控制了數千台具有不同IP的計算機，那麼我的NAS將無法將其全部阻止。另外，如果我們公司的員工決定設置非常簡單的密碼，那麼使用暴力攻擊的人最終可能會進入我們的系統。

ol>

現在，我禁用了SFTP，攻擊停止了，我很高興沒有人嘗試進入我們的文件服務器。

否，SSH和SSL通常使用相同的密碼強度。例如：RSA和AES，但SSH可以使用DSA。但是ssh使用端口22，而FTP使用FTP和FTP數據使用端口21和22。在我看來，更好的可配置性是，您必須打開2個端口，這不僅考慮防火牆是不切實際的，而且還存在潛在的安全風險，因為您必須打開2個端口。

無論用哪種方式說話，答案都是直截了當的。服務器端工具由提供文件的人控制，並且如果知道所有安全功能，從理論上講是安全的。

用戶端方法與用戶相同。在這些日子裡，我們不懷疑兩者之間的關係。每個人都必須確保自己有足夠的能力保護自己。因此，用戶轉向了防火牆選項。

您為用戶選擇的任何選項都可以通過這種方式輕易地推翻。因此，我們不必擔心用戶（收件人）。在這個問題上，這種說法現在已經過時了。

您應該擔心的是您自己的證券。這意味著服務器端。您要控制發布的信息。它發布後，有多少關注不再是審慎的。超出那一點根本不是您的責任。結果只會影響到您。如果尚無相關數據，則沒有任何後果。

一個真正可控的解決方案是使用完全由您自己設計的具有加密功能的FTP源。不要依賴任何第三方。但這也是過時的，因為很難從頭到尾構建自己的庫。

基於您提供的術語不足，您需要一個簡單的ssh ftp。為此，您可以建議防火牆規則和iptables配置（如果在Linux中）。無論走哪種方式，您似乎都對所見即所得感到困惑。