FTP is built on a client-server model architecture using separate control and data connections between the client and the server. FTP users may authenticate themselves with a clear-text sign-in protocol, normally in the form of a username and password, but can connect anonymously if the server is configured to allow it. For secure transmission that protects the username and password, and encrypts the content, FTP is often secured with SSL/TLS (FTPS) or replaced with SSH File Transfer Protocol (SFTP).
The first FTP client applications were command-line programs developed before operating systems had graphical user interfaces, and are still shipped with most Windows, Unix, and Linux operating systems. Many FTP clients and automation utilities have since been developed for desktops, servers, mobile devices, and hardware, and FTP has been incorporated into productivity applications, such as HTML editors.
The original specification for the File Transfer Protocol was written by Abhay Bhushan and published as RFC 114 on 16 April 1971. Until 1980, FTP ran on NCP, the predecessor of TCP/IP. The protocol was later replaced by a TCP/IP version, RFC 765 (June 1980) and RFC 959 (October 1985), the current specification. Several proposed standards amend RFC 959, 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.
FTP may run in active or passive mode, which determines how the data connection is established. In both cases, the client creates a TCP control connection from a random, usually an unprivileged, port N to the FTP server command port 21.
The server responds over the control connection with three-digit status codes in ASCII with an optional text message. For example, "200" (or "200 OK") means that the last command was successful. The numbers represent the code for the response and the optional text represents a human-readable explanation or request (e.g. <Need account for storing file>). An ongoing transfer of file data over the data connection can be aborted using an interrupt message sent over the control connection.
FTP login uses normal username and password scheme for granting access. The username is sent to the server using the USER command, and the password is sent using the PASS command. This sequence is unencrypted "on the wire", so may be vulnerable to a network sniffing attack. If the information provided by the client is accepted by the server, the server will send a greeting to the client and the session will commence. If the server supports it, users may log in without providing login credentials, but the same server may authorize only limited access for such sessions.
A host that provides an FTP service may provide anonymous FTP access. Users typically log into the service with an 'anonymous' (lower-case and case-sensitive in some FTP servers) account when prompted for user name. Although users are commonly asked to send their email address instead of a password, no verification is actually performed on the supplied data. Many FTP hosts whose purpose is to provide software updates will allow anonymous logins.
FTP normally transfers data by having the server connect back to the client, after the PORT command is sent by the client. This is problematic for both NATs and firewalls, which do not allow connections from the Internet towards internal hosts. For NATs, an additional complication is that the representation of the IP addresses and port number in the PORT command refer to the internal host's IP address and port, rather than the public IP address and port of the NAT.
There are two approaches to solve this problem. One is that the FTP client and FTP server use the PASV command, which causes the data connection to be established from the FTP client to the server. This is widely used by modern FTP clients. Another approach is for the NAT to alter the values of the PORT command, using an application-level gateway for this purpose.
HTTP essentially fixes the bugs in FTP that made it inconvenient to use for many small ephemeral transfers as are typical in web pages.
FTP has a stateful control connection which maintains a current working directory and other flags, and each transfer requires a secondary connection through which the data are transferred. In "passive" mode this secondary connection is from client to server, whereas in the default "active" mode this connection is from server to client. This apparent role reversal when in active mode, and random port numbers for all transfers, is why firewalls and NAT gateways have such a hard time with FTP. HTTP is stateless and multiplexes control and data over a single connection from client to server on well-known port numbers, which trivially passes through NAT gateways and is simple for firewalls to manage.
Setting up an FTP control connection is quite slow due to the round-trip delays of sending all of the required commands and awaiting responses, so it is customary to bring up a control connection and hold it open for multiple file transfers rather than drop and re-establish the session afresh each time. In contrast, HTTP originally dropped the connection after each transfer because doing so was so cheap. While HTTP has subsequently gained the ability to reuse the TCP connection for multiple transfers, the conceptual model is still of independent requests rather than a session.
When FTP is transferring over the data connection, the control connection is idle. If the transfer takes too long, the firewall or NAT may decide that the control connection is dead and stop tracking it, effectively breaking the connection and confusing the download. The single HTTP connection is only idle between requests and it is normal and expected for such connections to be dropped after a time-out.
Most common web browsers can retrieve files hosted on FTP servers, although they may not support protocol extensions such as FTPS. When an FTP—rather than an HTTP—URL is supplied, the accessible contents on the remote server are presented in a manner that is similar to that used for other web content. A full-featured FTP client can be run within Firefox in the form of an extension called FireFTP.
For example, the URL ftp://public.ftp-servers.example.com/mydirectory/myfile.txt represents the file myfile.txt from the directory mydirectory on the server public.ftp-servers.example.com as an FTP resource. The URL ftp://user001:firstname.lastname@example.org/mydirectory/myfile.txt adds a specification of the username and password that must be used to access this resource.
More details on specifying a username and password may be found in the browsers' documentation (e.g., Firefox and Internet Explorer). By default, most web browsers use passive (PASV) mode, which more easily traverses end-user firewalls.
Some variation has existed in how different browsers treat path resolution in cases where there is a non-root home directory for a user.
FTP does not encrypt its traffic; all transmissions are in clear text, and usernames, passwords, commands and data can be read by anyone able to perform packet capture (sniffing) on the network. This problem is common to many of the Internet Protocol specifications (such as SMTP, Telnet, POP and IMAP) that were designed prior to the creation of encryption mechanisms such as TLS or SSL.
Common solutions to this problem include:
FTP over SSH is the practice of tunneling a normal FTP session over a Secure Shell connection. Because FTP uses multiple TCP connections (unusual for a TCP/IP protocol that is still in use), it is particularly difficult to tunnel over SSH. With many SSH clients, attempting to set up a tunnel for the control channel (the initial client-to-server connection on port 21) will protect only that channel; when data is transferred, the FTP software at either end sets up new TCP connections (data channels) and thus have no confidentiality or integrity protection.
Otherwise, it is necessary for the SSH client software to have specific knowledge of the FTP protocol, to monitor and rewrite FTP control channel messages and autonomously open new packet forwardings for FTP data channels. Software packages that support this mode include:
Explicit FTPS is an extension to the FTP standard that allows clients to request FTP sessions to be encrypted. This is done by sending the "AUTH TLS" command. The server has the option of allowing or denying connections that do not request TLS. This protocol extension is defined in RFC 4217. Implicit FTPS is an outdated standard for FTP that required the use of a SSL or TLS connection. It was specified to use different ports than plain FTP.
The SSH file transfer protocol (chronologically the second of the two protocols abbreviated SFTP) transfers files and has a similar command set for users, but uses the Secure Shell protocol (SSH) to transfer files. Unlike FTP, it encrypts both commands and data, preventing passwords and sensitive information from being transmitted openly over the network. It cannot interoperate with FTP software.
Trivial File Transfer Protocol (TFTP) is a simple, lock-step FTP that allows a client to get a file from or put a file onto a remote host. One of its primary uses is in the early stages of booting from a local area network, because TFTP is very simple to implement. TFTP lacks security and most of the advanced features offered by more robust file transfer protocols such as File Transfer Protocol. TFTP was first standardized in 1981 and the current specification for the protocol can be found in RFC 1350.
Simple File Transfer Protocol (the first protocol abbreviated SFTP), as defined by RFC 913, was proposed as an (unsecured) file transfer protocol with a level of complexity intermediate between TFTP and FTP. It was never widely accepted on the Internet, and is now assigned Historic status by the IETF. It runs through port 115, and often receives the initialism of SFTP. It has a command set of 11 commands and support three types of data transmission: ASCII, binary and continuous. For systems with a word size that is a multiple of 8 bits, the implementation of binary and continuous is the same. The protocol also supports login with user ID and password, hierarchical folders and file management (including rename, delete, upload, download, download with overwrite, and download with append).
Below is a summary of FTP reply codes that may be returned by an FTP server. These codes have been standardized in RFC 959 by the IETF. The reply code is a three-digit value. The first digit is used to indicate one of three possible outcomes — success, failure, or to indicate an error or incomplete reply:
The second digit defines the kind of error:
The third digit of the reply code is used to provide additional detail for each of the categories defined by the second digit.
Crax Commander, stylized CRAX, is a dual pane, orthodox file manager for macOS, written in the programming language Objective-C. The app is currently developed by Soft4U2 (Marcin Słowik) and is one of several replacement apps for Apple's Finder.
The program's look is similar to Finder, and it has many features and functions, so it is usable quickly as a replacement.The software uses the model of a dual-pane user interface, which is well-known from the domain of the Windows applications such as Total Commander. This approach assumes offering multi-tab browsing user interface with features enabling advanced search of files or folders, comparing files and folders, navigation in archive files, and a batch renaming tool with regular expression support. Such programs also include a built-in File Transfer Protocol (FTP) client, working with local and network drives, and a built-in file editor and viewer.Crax Commander improves productivity by offering user configurable keyboard shortcuts, built-in text editor with sync coloring, full user interface customizing including fonts and colors, archive support, and built in File Transfer Protocol (FTP), Server Message Block (SMB), Apple Filing Protocol (AFP), SSH File Transfer Protocol (SSH), and SSH File Transfer Protocol (sFTP).The program is available in demo and paid versions and provides many tools that will help users to manage files and folders while exploiting the dual-pane graphical user interface design.Comparison of file transfer protocols
This article lists communication protocols that are designed for file transfer over a telecommunications network.
Protocols for shared file systems—such as 9P and the Network File System—are beyond the scope of this article, as are file synchronization protocols.EFTP
EFTP was a very simple file transfer protocol developed as part of the PARC Universal Packet protocol suite at Xerox PARC in the late 1970s. It was part of the inspiration for the Trivial File Transfer Protocol (TFTP) in the TCP/IP suite.
As with its descendant, TFTP, it did not use the reliable byte stream protocol of the suite (Byte Stream Protocol in the case of PUP); rather, it ran directly on top of the basic internetwork layer. (An early version of EFTP ran on top of bare Ethernet packets.) Also, like TFTP, it was a simple lock-step protocol; there was only ever one packet outstanding at any time, and every packet received by either party caused one packet to be sent in reply (until the termination of the transfer). Unlike TFTP, it made no provisions for sending the file-name as part of transfers, so it could only be used either in places that didn't need a file name (as with spooling), or in conjunction with another protocol that provided the file-name (as in booting).
Since EFTP was so simple, it was easy to implement in a very small amount of memory, an important consideration at that time. It was used for booting Xerox Altos over the Ethernet, and also to send files to the print spoolers of laser printers.
Various expansions of the initialism EFTP have been given, including Easy File Transfer Protocol, Ether File Transfer Protocol, and Experimental File Transfer Protocol.FTAM
FTAM, ISO standard 8571, is the OSI application layer protocol for file transfer, access and management.
The goal of FTAM is to combine into a single protocol both file transfer, similar in concept to the Internet FTP, as well as remote access to open files, similar to NFS. However, like the other OSI protocols, FTAM has not been widely adopted, and the TCP/IP based Internet has become the dominant global network.
The FTAM protocol was used in the German banking sector to transfer clearing information. The Banking Communication Standard (BCS) over FTAM access (short BCS-FTAM) was standardized in the DFÜ-Abkommen (EDI-agreement) enacted in Germany on 15 March 1995. The BCS-FTAM transmission protocol was supposed to be replaced by the Electronic Banking Internet Communication Standard (EBICS) in 2010. The obligatory support for BCS over FTAM was ceased in December 2010.
RFC 1415 provides an FTP-FTAM gateway specification but attempts to define an Internet-scale file transfer protocol have instead focused on Server message block, NFS or Andrew File System as models.FTPFS
FTPFS refers to file systems that support access to a File Transfer Protocol (FTP) server through standard file system application programming interfaces (APIs).
The ftpfs command in Plan 9 was originated by Dennis Ritchie and was included in the first release of the system (1992). It arranged for a remote file system reachable via FTP to appear as part of the local file system.
In Linux systems, FTPFS was initially implemented as a Linux kernel module that allows the user to mount a FTP server onto the local filesystem but it was never seen as the perfect way to do it. By 2003, it has been converted to use LUFS, and later to FUSE. Now it is called CurlFtpFS because it uses the universal libcurl for FTP transactions and is becoming part of the major Linux distributions. There also exists LftpFS for smart mirroring of FTP sites.
In Mac OS X, a read-only FTP file system is included that can be used either via the GUI (with ⌘ Command+K) or the command line (mount_ftp). The read-only limitation is noted in the man page for mount_ftp (on an OS X system, in Terminal.app, see "man mount_ftp"). However, the free application Macfusion includes a working implementation of FTPFS. Additionally, OS X Fuse is reported to enable this but the method to do so is undocumented (as of March 4, 2013) either via various obvious man page (e.g. sshfs) or in the OS X Fuse wiki.
For Windows XP, Windows 7 and other Windows operating systems, this functionality is partially provided by the "Network Places"/"Network Location" shell facility; a network place is a link to either an FTP server or a WebDAV server and can be accessed in Windows Explorer as just another network filesystem. This does not provide transparent access through the lowest-level Win32 file system APIs, however. Such functionality can be provided by third party programs such as WebDrive and FTPDrive.FTPS
FTPS (also known as FTPES, FTP-SSL, and FTP Secure) is an extension to the commonly used File Transfer Protocol (FTP) that adds support for the Transport Layer Security (TLS) and, formerly, the Secure Sockets Layer (SSL, which is now prohibited by RFC7568) cryptographic protocols.
FTPS should not be confused with the SSH File Transfer Protocol (SFTP), a secure file transfer subsystem for the Secure Shell (SSH) protocol with which it is not compatible. It is also different from FTP over SSH, which is the practice of tunneling FTP through an SSH connection.FTP bounce attack
FTP bounce attack is an exploit of the FTP protocol whereby an attacker is able to use the PORT command to request access to ports indirectly through the use of the victim machine as a middle man for the request.This technique can be used to port scan hosts discreetly, and to access specific ports that the attacker cannot access through a direct connection, for example with the nmap port scanner.Nearly all modern FTP server programs are configured by default to refuse PORT commands that would connect to any host but the originating host, thwarting FTP bounce attacks.File transfer
File transfer is the transmission of a computer file through a communication channel from one computer system to another. Typically, file transfer is mediated by a communications protocol. In the history of computing, a large number of file transfer protocols have been designed for different contexts.List of FTP commands
Below is a list of FTP commands that may be sent to an FTP server, including all commands that are standardized in RFC 959 by the IETF. All commands below are RFC 959 based unless stated otherwise. Note that most command-line FTP clients present their own set of commands to users. For example, GET is the common user command to download a file instead of the raw command RETR.List of FTP server return codes
FTP server return codes always have three digits, and each digit has a special meaning. The first digit denotes whether the response is good, bad or incomplete:
The second digit is a grouping digit and encodes the following information:
Below is a list of all known return codes that may be issued by an FTP server.Managed file transfer
Managed file transfer ("MFT") refers to a software or a service that manages the secure transfer of data from one computer to another through a network (e.g., the Internet). MFT software is marketed to corporate enterprises as an alternative to using ad-hoc file transfer solutions, such as FTP, HTTP and others.OFTP
The Odette File Transfer Protocol (OFTP) is a protocol created in 1986, used for EDI (Electronic Data Interchange) between two communications business partners. Its name comes from the Odette Organisation (the Organization for data exchange by teletransmission in Europe).
The ODETTE File Transfer Protocol (ODETTE-FTP) was defined in 1986 by working group four of the Organisation for Data Exchange by Tele-Transmission in Europe (ODETTE) to address the electronic data interchange (EDI) requirements of the European automotive industry. It was designed in the spirit of the Open System Interconnection (OSI) model utilising the Network Service provided by the CCITT X.25 recommendation.
OFTP 2 was written in 2007 by Data Interchange, as a specification for the secure transfer of business documents over the Internet, ISDN and X.25 networks. A description of OFTP 1.3 can be found in RFC 2204, whilst OFTP 2 is defined in RFC 5024.
OFTP 2 can work point-to-point or indirectly via a VAN (Value Added Network). A single OFTP 2 entity can make and receive calls, exchanging files in both directions. This means that OFTP 2 can work in a push or pull mode, as opposed to AS2, which can only work in a push mode.OFTP 2 can encrypt and digitally sign message data, request signed receipts and also offers high levels of data compression. All of these services are available when using OFTP 2 over TCP/IP, X.25/ISDN or native X.25. When used over a TCP/IP network such as the Internet, additional session level security is available by using OFTP 2 over TLS (Transport Layer Security).SSHFS
In computing, SSHFS (SSH Filesystem) is a filesystem client to mount and interact with directories and files located on a remote server or workstation over a normal ssh connection. The client interacts with the remote file system via the SSH File Transfer Protocol (SFTP), a network protocol providing file access, file transfer, and file management functionality over any reliable data stream that was designed as an extension of the Secure Shell protocol (SSH) version 2.0.
The current implementation of SSHFS using FUSE is a rewrite of an earlier version. The rewrite was done by Miklos Szeredi, who also wrote FUSE.SSH File Transfer Protocol
In computing, the SSH File Transfer Protocol (also Secure File Transfer Protocol, or SFTP) is a network protocol that provides file access, file transfer, and file management over any reliable data stream. It was designed by the Internet Engineering Task Force (IETF) as an extension of the Secure Shell protocol (SSH) version 2.0 to provide secure file transfer capabilities. The IETF Internet Draft states that, even though this protocol is described in the context of the SSH-2 protocol, it could be used in a number of different applications, such as secure file transfer over Transport Layer Security (TLS) and transfer of management information in VPN applications.
This protocol assumes that it is run over a secure channel, such as SSH, that the server has already authenticated the client, and that the identity of the client user is available to the protocol.Secure file transfer protocol
The term secure file transfer protocol or secure FTP may refer to:
Network protocolsSSH File Transfer Protocol — a file transfer protocol specifically developed by the IETF to run over secure shell connections
FTP over SSH, also known as "secure FTP" — the practice of using SSH to tunnel the older, well-known File Transfer Protocol (FTP)Computer programsSecure file transfer program, usually known as "sftp" — a well-known command-line program, common in Unix, for using SSH File Transfer Protocol
Secure FTP (software) — a software package, by Glub Tech, for using FTPS (traditional FTP over SSL/TLS)Trivial File Transfer Protocol
Trivial File Transfer Protocol (TFTP) is a simple lockstep File Transfer Protocol which allows a client to get a file from or put a file onto a remote host. One of its primary uses is in the early stages of nodes booting from a local area network. TFTP has been used for this application because it is very simple to implement.
TFTP was first standardized in 1981 and the current specification for the protocol can be found in RFC 1350.UFTP
The UDP-based File Transfer Protocol (UFTP) is a communication protocol designed to transfer files to multiple recipients. To accomplish this, UFTP multicasts the files to recipients via the User Datagram Protocol (UDP). The reference implementation of UFTP is open-source software distributed under the GNU General Public License for non-commercial use. The author of UFTP and its reference protocol is Dennis Bush.UFTP can perform effectively in a wide area network with high network delay, as well as in communication satellite transmissions.Bush published a pre-release version of UFTP on July 6, 2001. After two more intermediate releases, version 1.0 was published on December 17, 2002. He based UFTP on the Multicast File Transfer Protocol (MFTP), which was designed and developed at Starburst Communications. In 1997 and 1998, Starburst had submitted drafts of the MFTP specification to the Internet Engineering Task Force, with a view to promoting adoption of the protocol. Starburst later sold MFTP, along with their Omnicast file distribution software, to the Fantastic Corporation. Stratacache, a digital signage company in the United States, announced in February 2004 that they had purchased the property from Fantastic.ZMODEM
ZMODEM is a file transfer protocol developed by Chuck Forsberg in 1986, in a project funded by Telenet in order to improve file transfers on their X.25 network. In addition to dramatically improved performance compared to older protocols, ZMODEM also offered restartable transfers, auto-start by the sender, an expanded 32-bit CRC, and control character quoting supporting 8-bit clean transfers, allowing it to be used on networks that would not pass control characters. ZMODEM became extremely popular on bulletin board systems (BBS) in the early 1990s, displacing earlier protocols such as XMODEM and YMODEM.
Uniform Resource Identifier (URI) schemes