File Transfer Protocol

The File Transfer Protocol (FTP) is a standard network protocol used for the transfer of computer files between a client and server on a computer network.

FTP is built on a client-server model architecture using separate control and data connections between the client and the server.[1] 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.[2][3] 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.

History of FTP servers

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.[2] 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.[4]

Protocol overview

Communication and data transfer

Passive FTP Verbindung
Illustration of starting a passive connection using port 21

FTP may run in active or passive mode, which determines how the data connection is established.[5] 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.

  • In active mode, the client starts listening for incoming data connections from the server on port M. It sends the FTP command PORT M to inform the server on which port it is listening. The server then initiates a data channel to the client from its port 20, the FTP server data port.
  • In situations where the client is behind a firewall and unable to accept incoming TCP connections, passive mode may be used. In this mode, the client uses the control connection to send a PASV command to the server and then receives a server IP address and server port number from the server,[5] which the client then uses to open a data connection from an arbitrary client port to the server IP address and server port number received.[6]

Both modes were updated in September 1998 to support IPv6. Further changes were introduced to the passive mode at that time, updating it to extended passive mode.[7]

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>).[1] An ongoing transfer of file data over the data connection can be aborted using an interrupt message sent over the control connection.

While transferring data over the network, four data representations can be used:[2][3][4]

  • ASCII mode: Used for text. Data is converted, if needed, from the sending host's character representation to "8-bit ASCII" before transmission, and (again, if necessary) to the receiving host's character representation. As a consequence, this mode is inappropriate for files that contain data other than plain text.
  • Image mode (commonly called Binary mode): The sending machine sends each file byte by byte, and the recipient stores the bytestream as it receives it. (Image mode support has been recommended for all implementations of FTP).
  • EBCDIC mode: Used for plain text between hosts using the EBCDIC character set.
  • Local mode: Allows two computers with identical setups to send data in a proprietary format without the need to convert it to ASCII.

For text files, different format control and record structure options are provided. These features were designed to facilitate files containing Telnet or ASA.

Data transfer can be done in any of three modes:[1][2]

  • Stream mode: Data is sent as a continuous stream, relieving FTP from doing any processing. Rather, all processing is left up to TCP. No End-of-file indicator is needed, unless the data is divided into records.
  • Block mode: FTP breaks the data into several blocks (block header, byte count, and data field) and then passes it on to TCP.[4]
  • Compressed mode: Data is compressed using a simple algorithm (usually run-length encoding).

Some FTP software also implements a DEFLATE-based compressed mode, sometimes called "Mode Z" after the command that enables it. This mode was described in an Internet Draft, but not standardized.[8]


FTP login uses normal username and password scheme for granting access.[2] The username is sent to the server using the USER command, and the password is sent using the PASS command.[2] This sequence is unencrypted "on the wire", so may be vulnerable to a network sniffing attack.[9] 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.[2] 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.[2]

Anonymous FTP

A host that provides an FTP service may provide anonymous FTP access.[2] 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,[3] no verification is actually performed on the supplied data.[10] Many FTP hosts whose purpose is to provide software updates will allow anonymous logins.[3]

NAT and firewall traversal

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.[11] 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.[11] 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.[11]

Differences from HTTP

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.

Web browser support

Most common web browsers can retrieve files hosted on FTP servers, although they may not support protocol extensions such as FTPS.[3][12] 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.


FTP URL syntax is described in RFC 1738, taking the form: ftp://[user[:password]@]host[:port]/url-path (the bracketed parts are optional).

For example, the URL represents the file myfile.txt from the directory mydirectory on the server as an FTP resource. The URL 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[13] and Internet Explorer[14]). 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.[15]


FTP was not designed to be a secure protocol, and has many security weaknesses.[16] In May 1999, the authors of RFC 2577 listed a vulnerability to the following problems:

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.[2][16] 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.[4]

Common solutions to this problem include:

  1. Using the secure versions of the insecure protocols, e.g., FTPS instead of FTP and TelnetS instead of Telnet.
  2. Using a different, more secure protocol that can handle the job, e.g. SSH File Transfer Protocol or Secure Copy Protocol.
  3. Using a secure tunnel such as Secure Shell (SSH) or virtual private network (VPN).

FTP over SSH

FTP over SSH is the practice of tunneling a normal FTP session over a Secure Shell connection.[16] 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.

SSH File Transfer Protocol

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

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

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).

FTP reply codes

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:

  • 2yz – Success reply
  • 4yz or 5yz – Failure reply
  • 1yz or 3yz – Error or Incomplete reply

The second digit defines the kind of error:

  • x0z – Syntax. These replies refer to syntax errors.
  • x1z – Information. Replies to requests for information.
  • x2z – Connections. Replies referring to the control and data connections.
  • x3z – Authentication and accounting. Replies for the login process and accounting procedures.
  • x4z – Not defined.
  • x5z – File system. These replies relay status codes from the server file system.

The third digit of the reply code is used to provide additional detail for each of the categories defined by the second digit.

FTP servers

Some popular open source and commercial FTP server implementations are:

See also


  1. ^ a b c Forouzan, B.A. (2000). TCP/IP: Protocol Suite (1st ed.). New Delhi, India: Tata McGraw-Hill Publishing Company Limited.
  2. ^ a b c d e f g h i j Kozierok, Charles M. (2005). "The TCP/IP Guide v3.0".
  3. ^ a b c d e Dean, Tamara (2010). Network+ Guide to Networks. Delmar. pp. 168–171.
  4. ^ a b c d Clark, M.P. (2003). Data Networks IP and the Internet (1st ed.). West Sussex, England: John Wiley & Sons Ltd.
  5. ^ a b "Active FTP vs. Passive FTP, a Definitive Explanation". Archived from the original on 4 May 2011.
  6. ^ RFC 959 (Standard) File Transfer Protocol (FTP). Postel, J. & Reynolds, J. (October 1985).
  7. ^ RFC 2428 (Proposed Standard) Extensions for IPv6, NAT, and Extended Passive Mode. Allman, M. & Metz, C. & Ostermann, S. (September 1998).
  8. ^ Preston, J. (January 2005). Deflate transmission mode for FTP. IETF. I-D draft-preston-ftpext-deflate-03.txt. Retrieved 27 January 2016.
  9. ^ Prince, Brian. "Should Organizations Retire FTP for Security?". Security Week. Security Week. Retrieved 14 September 2017.
  10. ^ RFC 1635 (Informational) How to Use Anonymous FTP. P. & Emtage, A. & Marine, A. (May 1994).
  11. ^ a b c Gleason, Mike (2005). "The File Transfer Protocol and Your Firewall/NAT".
  12. ^ Matthews, J. (2005). Computer Networking: Internet Protocols in Action (1st ed.). Danvers, MA: John Wiley & Sons Inc.
  13. ^ "Accessing FTP servers | How to | Firefox Help". 2012-09-05. Retrieved 2013-01-16.
  14. ^ "How to Enter FTP Site Password in Internet Explorer". 2011-09-23. Retrieved 2015-03-28. Written for IE versions 6 and earlier. Might work with newer versions.
  15. ^ Jukka “Yucca” Korpela (1997-09-18). "FTP URLs". "IT and communication" ( Retrieved 2016-01-06.
  16. ^ a b c "Securing FTP using SSH".
  17. ^ "Access using SSH keys & PCI DSS compliance".

Further reading

  • RFC 697 – CWD Command of FTP. July 1975.
  • RFC 959 – (Standard) File Transfer Protocol (FTP). J. Postel, J. Reynolds. October 1985.
  • RFC 1579 – (Informational) Firewall-Friendly FTP. February 1994.
  • RFC 1635 – (Informational) How to Use Anonymous FTP. May 1994.
  • RFC 1639 – FTP Operation Over Big Address Records (FOOBAR). June 1994.
  • RFC 1738 – Uniform Resource Locators (URL). December 1994.
  • RFC 2228 – (Proposed Standard) FTP Security Extensions. October 1997.
  • RFC 2389 – (Proposed Standard) Feature negotiation mechanism for the File Transfer Protocol. August 1998.
  • RFC 2428 – (Proposed Standard) Extensions for IPv6, NAT, and Extended passive mode. September 1998.
  • RFC 2577 – (Informational) FTP Security Considerations. May 1999.
  • RFC 2640 – (Proposed Standard) Internationalization of the File Transfer Protocol. July 1999.
  • RFC 3659 – (Proposed Standard) Extensions to FTP. P. Hethmon. March 2007.
  • RFC 5797 – (Proposed Standard) FTP Command and Extension Registry. March 2010.
  • RFC 7151 – (Proposed Standard) File Transfer Protocol HOST Command for Virtual Hosts. March 2014.
  • IANA FTP Commands and Extensions registry – The official registry of FTP Commands and Extensions

External links

CRAX Commander

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 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, 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 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, 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 (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.

Typically, MFT offers reporting (e.g., notification of successful file transfers), non-repudiation, auditability, global visibility, automation of file transfer-related activities and processes, end-to-end security, and performance metrics/monitoring. MFT applications are available as both on-premises licensed software packages and software-as-a-service ("SaaS"). MFT solutions are designed for enterprise implementations.

MFT applications are characterized by having all or most of the following features:

Support multiple file transfer protocols including PeSIT, FTP/S, OFTP, SFTP, SCP, AS2, and HTTP/S.

Securely transfer files over public and private networks using encrypted file transfer protocols.

Securely store files using multiple data encryption methods

Automate file transfer processes between trading partners and exchanges including detection and handling of failed file transfers.

Authenticate users against existing user repositories such as LDAP and Active Directory

Integrate to existing applications using documented APIs (application programming interfaces)

Generate detailed reports on user and file transfer activity.


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).


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.


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 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.


This page is based on a Wikipedia article written by authors (here).
Text is available under the CC BY-SA 3.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.