SFTP Port Alternatives

SFTP, which is often mistaken as an abbreviation for “Secure File Transfer Protocol,” truly represents SSH File Transfer Protocol. SFTP was developed in in the early days of the internet and is detailed in this SFTP RFC Specification. The SFTP protocol was known originally as simple FTP (File Transfer Protocol). The FTP protocol supports file transfer over TCP port 21 with TCP port 22 used for SFTP and port 990 used for TLS/SSL Implicit encryption. SFTP is a basic file transfer protocol and although it can be quite fast due to its simplicity, additional features such a file sharing, collaboration, authentication, and single sign-on are not defined for the protocol.

Over time the FTP Protocol has been updated to add encryption (SFTP), support TLS/SSL encryption and improve firewall/security issues – for example RFC 1579 (February 1994) enables Firewall-Friendly FTP (passive mode), RFC 2228 (June 1997) proposes security extensions, RFC 2428 (September 1998) adds support for IPv6 and defines a new type of passive mode.[8].


SFTP NAT and firewall traversal issues

Typically, internet service providers block SFTP Ports to prevent issues with security and malware by preventing file access over SFTP ports. SFTP Requires ports 22 or 990 to be open, which is prone to malware including the likes of infamous offenders like Wannacry, Sasser, Nimda, Petya/NotPetya, and more. If STFP Ports are open, an infected computer will search its Windows network for Server shares accepting traffic on TCP ports 22 or 990 indicating the system is configured to run SFTP. While modern Web Application Firewalls (WAFS) can be tuned to monitor HTTP traffic, SFTP traffic is not as easily monitored.

SFTP transfers data by responding from the server to the client after a PORT command has been sent. This is a problem for firewalls which do not allow connections from the internet inbound toward internal hosts. This is a particular issue with Microsoft IIS which responds with a random port.

The two approaches to solve this issue are to either set the SFTP server to use the PASV command or to use an application level gateway to alternate the port values.

SFTP Port Remote Access

To facilitate remote access to files, businesses have often granted users access using SFTP servers. This provides some level of remote access, however the support costs of training users and deploying SFTP client software is extensive. In addition, SFTP is not easily integrated into existing file servers and Active Directory to present a unified file sharing experience. When accessing files remotely user expect to easily access their existing home drives and department shares over a standard mapped drive that fully support file locking, Office, and other applications. STFP was never designed for file sharing or collaboration.

SFTP Port vs HTTP/s

HTTP port 443 is an updated protocol that essentially fixes the bugs in SFTP that made it inconvenient to use for many small transfers.

SFTP uses a stateful control connection which maintains a current working directory and each transfer requires a secondary connection through which the actual data is transferred. In “passive” mode this additional connection is from client to server, whereas in the default “active” mode this connection is from server to client. This SFTP port change when in active mode, and random port numbers for all transfers, is why firewalls and NAT gateways have such a hard time with SFTP.

Setting up an SFTP control connection can be quite slow as compared to HTTP due to the round-trip delays of sending all of the required commands while waiting for a reply so typically the connection is held it open for multiple file transfers rather than dropped and re-established each time.

HTTP in comparison is stateless and multiplexes control and data over a single connection from client to server on well-known port numbers, which easily passes through NAT gateways and is simple for firewalls to manage and scan for security vulnerabilities.

Why might SFTP fall short as a complete file transfer solution as file transfer volumes increase?

As the volume of file transfers grows, the limitations of SFTP as a complete file transfer solution become apparent. The increasing demands for onboarding more partners, scaling infrastructure, and resolving technical issues can push the capabilities of SFTP to their limits, potentially overwhelming IT teams. Additionally, the need for heightened security measures, strict control over file transactions, and robust visibility to comply with security and governance standards may exceed what SFTP alone can offer.

To address these challenges effectively, organizations may find that managed file transfer (MFT) solutions offer a more comprehensive approach. Utilizing a cloud-based service like Thru, which harnesses various protocols such as SFTP among others, can provide enhanced end-to-end security measures, precise tracking mechanisms, detailed logs, and long-term retention settings. Moreover, MFT solutions like Thru can offer increased availability to ensure that file transfer operations remain seamless even as volumes continue to increase.

How does an SFTP server authenticate with a client?

To authenticate with a client, an SFTP server initiates a three-way TCP handshake to establish a connection. This process ensures that the server and client both have access to the correct port (usually 22) in the transport layer. Following this verification, the server uses SSH key pair authentication to validate the client’s identity. The SSH key pair consists of a public key (shared between the two parties) and a private key (known only to the authorized client). Once the SSH authentication is successfully completed, the file transfer takes place over an encrypted channel, with data packaged into individual packets. These packets are transmitted and reassembled at the receiving end to reconstruct the original file securely.

SFTP Port Alternative

SFTP protocol has been around since 1980 as a mechanism for transferring files. Enterprises will rightfully remain cautious when allowing or considering the support costs of direct SFTP port access to any internal resource from external networks over the FTP/SFTP protocol.

In the meantime, MyWorkDrive already converts Windows based file shares into secure file shares that can be accessed securely anywhere using TCP https/SSL port 443 over highly encrypted RSA 4096 and TLS 1.2 FIPS compliant protocols without the security or training concerns of SFTP.

MyWorkDrive SFTP port alternative supports remote workers with our secure Web Brower based access, Windows Mapped Drive, and Mobile clients.

Need help planning your SFTP alternative? Book a call and we’ll be happy to assist you in planning your deployment.

Daniel, Founder of MyWorkDrive.com, has worked in various technology management roles serving enterprises, government and education in the San Francisco bay area since 1992. Daniel is certified in Microsoft Technologies and writes about information technology, security and strategy and has been awarded US Patent #9985930 in Remote Access Networking