Transfering files

Some information may be available at TOOGAM's software archive: section on transfering files.

Sometimes a single file may be transferred (such as when a file is attached to an E-Mail), or a heirarchy of files and/or folders (such as a folder with subfolders, perhaps shared via SMB or a website).

[#fxfrfsys]: Remote filesystems

This may be the most convenient approach for regular use of transfering many files. For details, see the filesystems provided over networking. Examples include “Server Message Block” (“SMB”) (and the very related “Common Internet File System” (“CIFS”)) and Network File System (“NFS”), both of which have historically had implementations built into many popular operating systems.

File sharing sites

This section is about data that is being “shared”. That term “share” may refer to an intent of potentially having a large number of people being able to access the data, or the possibility of people accessing it at any random time. Another possible meaning is that authorized individuals can access the data at essentially any time. This means that the method of obtaining data is generally available at any time (rather than a file transfer that requires manual intervention by an administrator).

Sharing with the public
Web transfers (HTTP(S): The World Wide Web)

The section on Web transfers covers the basic technology of providing static files over the web.

For more elaborate websites that support other types of content, see websites.

Web clients
Web browsers

Some creators of operating systems are the same organizations that have released web browsers. Such operating systems are likely to come bundled with a web browser provided by that software make. Examples include Google Chrome being bundled with Chromium/ChromeOS, Apple's Safari being bundled with Mac OS X, and Microsoft's Internet Explorer being included with Microsoft Windows (perhaps starting with Windows 98). The next most popular web browser would likely be the code behind Iceweasel, which is based on Mozilla Firefox. Some operating systems may come with others: OpenBSD FAQ: What is included with OpenBSD (FAQ 1.8) will list Lynx (runnable using lynx). Other web browser software is available from TOOGAM's Software Archive: page about Web Browsers.

(See the section on Web transfers for more details.)

Software designed to get (even if it doesn't render) a file

Curl, wget, etc.

(See the section on Web transfers for more details.)

Web servers

e.g. Nginx, Apache, IIS, etc.

(See the section on Web transfers for more details.)

Server-side code
Server-side code (e.g. CGI and/or langauges such as PERL, PHP, Ruby, ASP(.NET), etc.)

(See the section on Web transfers for more details.)

Topics may include:

Common Gateway Interface (“CGI”)

(Perhaps see: Multi-Server Project Tutorial: CGI in OpenBSD httpd.)

FastCGI

(Perhaps see: Multi-Server Project Tutorial: CGI in OpenBSD httpd.)

Perl

(Also known as PERL.)

Some (currently limited/small) amount of information may be available in the section about Perl.

PHP

The name initially stood for “Personal Home Page”, although many people now use the phrase, “PHP: Hypertext Preprocessor”.

(Further details are not here, at this time.)

Ruby (on Rails)
...
ASP(X)(.NET)
...
Securing some data

e.g., password-protected web content

(This section is not currently elaborated upon.)

distributed fileservers (torrents)
[#bittoren]: BitTorrent
overview

Using the “BitTorrent” protocol is an effective way to spread bandwidth usage. This can be effective in reducing how much stress is experienced by a relatively small number of sites.

BitTorrent may be particularly attractive for people sharing large amounts of data. In BitTorrent's early years, the software became known as a tool that was effectively being used to spread commercial software. (A key reason for this is that commercial software was often notably larger than much of the freely distributable software that was common at the time.) BitTorrent's early years were marred by a reputation of being a tool used commonly, and perhaps primarily, for “piracy” (spreading certain data in violation of certain laws).

However, the truth is that the BitTorrent protocol, or variations, has been used by quite a few legitimate organizations. For example, some free operating systems (quite noticeably Debian, but also others including NetBSD) have been known to use this. World of WarCraft's internal patching system used a custom variation of BitTorrent.

The remaining challenge with BitTorrent is that the protocol was designed to use incoming IP connections, but such connections will frequently fail due to the protection of a firewall and/or usage of a NAT (network address translation) technology which doesn't direct incoming connections to the system that would respond to them. This means that many people may have a harder time getting their networks to provide BitTorrent data that is helpful for others, even though they can typically retrieve useful BitTorrent data much easier. This means people find it easier to take than to give. Unfortunately for larger communities, people who take and who do not give are using resources and not being helpful in return, which creates a situation which largely offsets the benfits of BitTorrent's design.

Downloading torrent software

Wikipedia: Comparison of BitTorrent clients.

Torrent clients for Microsoft Windows

See: TOOGAM's software achive: file transfers.

Torrent clients for Unix command line

Like the Microsoft Windows platform, there are multiple BitTorrent clients, including BitTornado (MIT license, uses Python).

For command-line usage, there is:

rTorrent
rTorrent (GPL). rTorrent downloads (*.tar.gz source code). Arch Wiki: rTorrent provides details, including a “session” option and a directory to be watched for new torrents, and key bindings.
Transmission
transmission-cli. Transmission is available on numerous Unix-like platforms (though its download page does not include an offering for Microsoft Windows). There are various versions of Transmission, including one for a terminal/console. That version supports command line parmaeters.

Transmission's license specifies GPLv2, GPLv3, or later, plus permission to link to OpenSSL, and says “Some of Transmission's source files have more permissive licenses.” Wikipedia's article on “Transmission (BitTorrent client)” identifies license as “GNU GPL, MIT License”.

For OpenBSD, the “main” package includes the command line client, and the “daemon” client.

aria2
aria2 (aria2 uses GPLv2).
mktorrent
Used to create torrent files
Others
Unix.StackExchange.com question about torrents via command line mention Deluge (GPL), ctorrent, and lftp (GPLv3+)
Jigdo

Wikipedia's article for Jigdo states, “unlike BitTorrent, Jigdo uses a client-server model, not peer-to-peer”. However, multiple mirror sites can be used to obtain pieces of a file. GPLv2+. Used by Debian to distribute the operating system (in addition to other methods: BitTorrent, or direct HTTP download (of ISO files)).

Secure file transfer

[#secftp]: Secure standards with “FTP” as part of the name
[#ftpsecnm]: Potential for term confusion

(Note for those who may have hyperlinked straight to this section of the website: This is part of the section about Secure standards with “FTP” as part of the name. That broader section does have some additional details about the protocols.)

Overview

The following is generally accepted/recognized: One name that is used to describe secure file transfers is SFTP. The protocol/implementation described by that name is different than the implementation/protocol described by the term FTPS.

There are at least three distinct implementations.

(The protocol that seems to have the widest support among people using security software is the one described in the section about SFTP.)

There is also a term called “Secure FTP”, which might or might not be the same as either of the above two protocols.

The result is ambiguous use of terms. Fortunately, some terms do have some definitions which are more common, and so those may be embraced. However, realize that some people have used terms in different ways, and so there can be some solid reasoning backing up some of the other ways that the terms get used.

Documented use of terms : cause for confusion

Having ambiguity with technical standards can be a sad state of affairs which can be difficult to accept. However, the claim is indeed being made that there is a bit of ambiguity. One thing that might help the acceptability of this ambiguity is to see some solid documentation about the ways that different usages of these terms have been considered to be proper usage. So, a hefty use of documentation is hereby in order, and is hereby provided.

Reason(s) for confusion related to the term “SFTP”

There are at least two distinct protocols that have used the abbreviation “SFTP”.

SSH File Transfer Protocol

Wikipedia's page for “SSH File Transfer Protocol” refers to a protocol that is (unsurprisingly, considering the name of the Wikipedia page) called SSH File Transfer Protocol, and which is documented by Internet Draft for SSH File Transfer Protocol (Draft #13). The same Wikipedia page says that this protocol is also known as “Secure File Transfer Protocol, Secure FTP, or SFTP”. (However, the term “Secure FTP” may be a bit more ambiguous.)

This is implemented by a program in OpenSSH, as documented by OpenBSD's manual page for sftp: “See Also” section. That documentation section refers to another document, which is by “T. Ylonen and S. Lehtinen”, and which is “SSH File Transfer Protocol, draft-ietf-secsh-filexfer-00.txt, January 2001, work in progress material.”

This is probably the protocol that has been supported more broadly than any other SFTP or FTPS protocol.

Simple File Transfer Protocol

The term SFTP most commonly refers to a file transfer protocol that implements security. There is also an older, unrelated protocol called Simple File Transfer Protocol defined by RFC 913: Simple File Transfer Protocol (which does refer to the documented protocol using the abbreviation of SFTP). Wikidedia's page for File Transfer Protocol: section titled “Derivatives”, subsection called “Simple File Transfer Protocol” notes that Simple File Transfer Protocol “was never widely accepted on the Internet, and is now assigned Historic status by the IETF.”.

[#ftpsname]: Reasons for confusion related to the term “FTPS”

The short summary: It seems that FTPS most commonly refers to an implementation of FTP secured with TLS. (The acronym FTPS is based on the idea of the phrase “FTP over SSL”, but the latest SSL has a new name of TLS.)

IANA has reserved some TCP and UDP ports so that those ports may be used with a standard called “ftps”. (As IANA tends to lowercase protocol names in their list of port assignments, this may safely be presumed to be the same thing as FTPS.)

A distracting idea: The descriptions that IANA uses for those ports make it sound like the standard is referring to implementing FTP tunnelled over an SSH connection. However, such a situation might not even need even one new port number (as the ports for SSH and FTP would be used). Therefore, IANA reserving ports for that purpose seems unlikely.

The long story, with evidence: Section 6 of Internet Draft document: “Secure FTP over SSL says “This port number (for ftps) is being requested form the IANA.” Wikipedia's page on FTPS: “Background” section says “An official IANA port was registered shortly thereafter.” Therefore, it seems likely that the IANA port (# 990) was related to that Internet Draft. That Internet Draft is related to the implementation documented by the standard for “FTP secured with SSL/TLS”. So, if that Internet Draft is indeed related to both the TCP port that IANA reserves for FTPS, and that Internet Draft is also related to “FTP secured with SSL/TLS”, then that does indicate that the abbreviation (as recognized by IANA) is related to “FTP secured with SSL/TLS”.

However, this conclusion does seem to be made from a couple of unsubstantiated leaps/guesses. Namely, that the Internet Draft is indeed related to either of thse implementations.

[#secftpnm]: Examples of confusion over the term “Secure FTP”

Wikipedia's page on FTPS refers to Wikipedia's page on FTP over SSH in a hyperlink called “Secure FTP”, and this hyperlinked term is described as “the practice of tunneling FTP through an SSH connection.” In contrast, Wikipedia's article on SSH File Transfer Protocol says that protocol “also” has a name of “Secure File Transfer Protocol”. Those two different Wikipedia pages were about two different protocols. Apparently both of those protocols are sometimes being referred to by the name of “Secure FTP”. So, it seems that the term Secure FTP is, unfortunately, ambiguous.

To further add to the confusion (but document things thoroughly) : The Internet Draft document: “Secure FTP over SSL is titled “Secure FTP over SSL”. However, that probably is meant for the word “Secure” to be an adjective or the “FTP over SSL” phrase, not trying to indicate that the protocol is called “Secure FTP”. (The article was likely written before people tried to use a phrase called “Secure FTP” as the name of a protocol.) Wikipedia's page about FTPS seems to be about the protocol related to that Internet Draft, and specifically says that this protocol is “different from Secure FTP”.

(Note: this small section is a part of the larger section on: Secure standards with “FTP” as part of the name: Potential for term confusion.)

[#ftpscmnm]: Simplifying things: Identifying some of the most common usage of the names

It seems the terms are just a mess. Most definitive answers may have some contrary solid information. However, that state just leaves things rather unworkable.

Decisions can be made, but all subsequent conclusions are really only as valid as those decisions. Therefore, there may be some worth in knowing the level of validity behind any decisions that are made. The section documenting that naming confusion is fairly long. This creator/founder of ][Cyber Pillar][ has reached some preliminary conclusions, summarized below. These definitions of the terms seem to be what is most consistent with the most commonly seen usage. However, know that technical documentation may (perhaps very legitimately) vary from some or any/all of these conclusions.

SFTP
Secure File Transfer Protocol, as implemented by OpenSSH and PSFTP
FTPS
FTP extensions to support TLS within the FTP protocol as eventually defined by RFC 4217: Securing FTP with TLS
FTP over SSH

FTP traffic routed through an SSH tunnel. This is an implementation that is totally different than either the SFTP implementation or the FTPS implementations that have just been described.

Secure FTP
Potentially any of the previous implementations
[#sftp]: “SFTP” (e.g. “Secure File Transfer Protocol”)

The protocol described in this section appears to be the protocol most commonly referred to when the term “SFTP” is used. This is the protocol supported by OpenSSH, WinSCP, and some other options. However, this is not the only protocol that has been known to use that name. (Further discussion is in the section on “Secure FTP” name confusion potential.)

SFTP support in Microsoft Windows

At the time of this writing, there are no (known) implementations that come bundled with a Microsoft Windows operating system. Downloading software from a third party is required.

Command line approaches
cURL

curl documentation provides some details about some site-specific commands (for FTP and SFTP).

cURL provides support for multiple protocols, and is documented on the web section: subsection about cURL.

curl documentation provides some details about some site-specific commands (for FTP and SFTP).

Winscp.com

The program WinSCP may be more well known for its graphical interface provided by Winscp.exe, but there is also a command line interface made available using a file called Winscp.com. This software allows the user to connect, and then interact with the server, similar to a common/standard command line FTP client.

PuTTY's PSFTP
...
OpenSSH

The OpenSSH software may come with SFTP software. Starting with OpenSSH 6.3, support for -a allows file resuming.

For the SFTP server, check the sshd_config file for a line that says “Subsystem”, and make sure that it is not commented out. e.g. (as found in OpenBSD)

Subsystem sftp /usr/libexec/sftp-server
[#ftps]: FTPS

Clearly true information: IANA's list of assigned port numbers identifies TCP and UDP ports 990 for ftps and describes these as describes these ports as “ftp protocol, control, over TLS/SSL”. Similarly, TCP and UDP ports 989 are reserved for ftps-data, and are described as “ftp protocol, data, over TLS/SSL” These use of multiple ports (and, even more specifically, having the “data” port having a number which is one less than the number associated with the “control” port) is similar to what is implemented by the unsecured, standard, traditional, old FTP implementations.

Technical information

To provide technical information about the protocol named FTPS, the first step is to figure out which protocol is being referred to when the term FTPS is being used. So the potential for naming confusion related to the name “FTPS” needs to be addressed.

If the recommended names for these various “secure” transfer protocols are accepted, then the section about FTP secured with TLS/SSL has the technical details related to that implementation.

[#ftptls]: FTP secured with TLS/SSL

This is documented by RFC 4217: Securing FTP with TLS. That RFC is credited to one of the authors of an older Internet Draft, which is discussed further in the section about a protocol named FTPS. Given the common authorship, it would seem that those documents are related.

After a brief review, it appears this is related to extensions to the old FTP protocol, and that these extensions add TLS support. However, rather than considering that the old FTP protocol finally supports security, most people refer to implementing these extensions as a new protocol called FTPS.

FTPS Variations

There is implicit or FTPES (explicit).

Implicit

WinSCP calls “TLS/SSL Implicit encryption” IETF RFC 4217 “Securing FTP with TLS” Draft 07, Appendix A: “Deprecated SSL negotiation mechanisms” section “ i) Implicit SSL protection of the FTP session” says, “This approach is not favoured by the IETF and should not be used for new FTP-TLS implementations.” This is from Draft 7 of that RFC, and such text doesn't show up in Draft 8 or the final version of the RFC, although Wikipedia's article on FTPS, section named “Methods of invoking security”, sub-section named “Implicit” does say Implicit “is considered an earlier, deprecated method of negotiating TLS/SSL for FTP.”

Reviewing documentation on these protocols has found that most documents described implicit as being more secure than explicit (or, at least “more strict”, e.g. quoting https://www.ftptoday.com/blog/explicit-ftps-vs-implicit-ftps-what-you-need-to-know. For instance, WinSCP.net documentation on FTPS states, “In Explicit Mode, the client has full control over what areas of the connection are to be encrypted.”

Explicit (a.k.a. FTPES or FTPeS)

It seems that multiple places document FTPES being described as “File Transfer Protocol Explicit SSL/TLS Secure”. This includes Wikipedia's article on FTPS, section named “Methods of invoking security”, sub-section named “Explicit”.

Wikipedia's article on FTPS, section named “Methods of invoking security”, sub-section named “Explicit” refers to IETF RFC 2228 and IETF RFC 4217.

WinSCP.net documentation on FTPS states, “In Explicit Mode, the client has full control over what areas of the connection are to be encrypted.”

Commentary on the abbreviation

Neither IETF RFC 4217 nor anywhere else seems to clearly identify itself as the authoritative source that determined the meaning of this abbreviation. However, the author of this text searched for and did not find any apparently authoritative resource which originated this acronym. Perhaps this is just a convention. Perhaps it stands for “File Transfer Protocol with Explicit SSL/TLS Security” Whether the letter S stands for “SSL/TLS”, or “Security”, or “Secure” (like HTTPS) may be left up to differing interpretations.

Sometimes people write the abbreviation as FTPeS with a lowercase e, while sometimes the abbreviation is written in all capital letters. Multiple sources have indicated that it stands for “Explicit File Transfer Protocol Secure” (perhaps similar to how ISO is intended as an abbreviation for “Organisation internationale de normalisation” in French, translated to English as “International Organization for Standardization”, neither of which neatly translates to an acronym of ISO). There doesn't seem to be a centralized source that clearly identifies the most correct way to write the abbreviation, or precisely what each letter is meant to stand for.

WinSCP calls this “TLS/SSL Explicit encryption”.

Sample usage:
[#lftptls]: Using lftp with TLS

The following text represents a supposedly more secure approach. (However, this wasn't able to be fully tested in a fully secure way prior to the writing of this text.)

FTPSRV=example.com
echo -n | openssl s_client -connect ${FTPSRV}:21 -starttls ftp | head -$( echo -n | openssl s_client -connect ${FTPSRV}:21 -starttls ftp | nl | grep -i -- "-----END CERTIFICATE-----" | cut -f 1 | xargs ) | tail -22 | tee -a ftps-${FTPSRV}.crt
ls -l ftps-${FTPSRV}.crt
 cp ftps-${FTPSRV}.crt /etc/ssh/certs/
lftp ftp://${FTPSRV} -e "set ssl:ca-file \"/etc/ssl/certs/ftps-${FTPSRV}.crt\";set ftps:initial-prot \"\"; set ftp:ssl-force true; set ftp:ssl-protect-data true; set ssl:verify-certificate no;open -u USERNAME;dir;quit;"
  • Customize the part that says “example.com”
  • Customize the part that says “USERNAME”
  • Some alternate documentation ended up showing "false" instead of "no". Customize as appropriate if needed.
  • If this works, it runs the "dir" command, and then quits lftp. You may change that. e.g., if you remove "quit", then lftp will remain connected and be left in an interactive mode. The referenced answer at https://serverfault.com/questions/411970/how-to-avoid-lftp-certificate-verification-error and some of the other answers had commands for doing some mirroring.
  • This is largely based on: Philippe Gachoud's answer to a question by “patrick” on ServerFault.com, but including some pieces found from other answers provided on that web same web page.
  • Note that the “ssl:verify-certificate no” is probably undesirable in most cases. However, it may be necessary if the FTPS server is actually handing out an expired certificate. In the case used to initially document that answer, using “ssl:verify-certificate no” was needed due to an invalid certificate (because the server's certificate was expired). In better cases, a server porbably provides a better certificate and so this check may be more desired. (Viewing the “man page” for lftp didn't seem to reveal a way to just ignore the expiration date and apply other checks.)

The insecure way:
$ FTPSRV=example.com
 $ lftp ftp://${FTPSRV} -e "set ssl:verify-certificate no;open -u USERNAME;dir;quit;"

Note, it is highly advised to NOT specify a password on a shell's command line. (It is typically considered fine to include that a command line that is within a program like lftp. Just don't use a command line parameter coming from the shell as the method to give the password to the lftp program.) Do keep that in mind before applying any of the advise in the following hyperlink.

user240137's question at SuperUser.com, titled “Simple command to connect to FTPS server on Linux command line” may also have some discussion/examples (which should be subject to the advise from the prior paragraph).

ftp-ssl

mentioned by answer (to a question by a generic username, user240137) provided by a SuperUser.com account named “loved.by.Jesus”

Like Using lftp with TLS (described earlier/above), there are very many systems which probably do not have this command readily available, although presumably a system administrator may be able to add it...

Using WinSCP with FTPS (TLS)

This can be done using the command line executable, or the GUI version. The GUI version of WinSCP calls this “TLS/SSL Explicit encryption”

Using WinSCP with the command line

Martin Prikryl's answer to s10v10s's SuperUser.com question indicates the program can make a script file.

WinSCP.net Forum: “Command line syntax for FTP ImplicitTLS” provided an example. (The forum topic seemed to be asking about implicit FTPS but due to the -explicittls parameter, that answer didn't seem to directly accurately answer the question.) The example was roughly something like this:

"C:\Program Files (x86)\WinSCP\WinSCP.com" /command "option batch on" "option confirm off" "open -explicittls ftps://myname:password@example.org:21" "cd /pub" "synchronize local c:\files" "exit"
  • It is recommended not to specify the password like this. Instead, the program can specify that interactively, or use a specified host key file. General advice is to have a habit of never include passwords on a command line that passes a command for the operating system to run.
  • The rest of that also can be customized a bit...
Connecting with the WinSCP GUI
A guide...

This is a slight adaptation of a guide which was written (and may use phrases like “I” or “my” to refer to the author).

Getting WinSCP

Okay, now I presume you have WinSCP, which is obtainable from either https://sf.net/projects/winscp/files/latest/download or, (likely with a green download button) found at the web page at the https://winscp.net/eng/download.php URL.

WinSCP GUI Site Setup

Upon starting WinSCP, it might show a dialog box titled "Login". If you don't see that, you can use the "_S_ession" menu's first option, "_N_ew Session...", to make that appear.

In the left frame, WinSCP will show "New Site", possibly followed by other "sites" saved from earlier times.

For WinSCP, the term "Site" refers to a collection of settings which identify a "Host name" to connect to, and other details about how to log in.

For now, let's just create a new site, so make sure that "New Site".

The first thing to change is the "_F_ile protocol". If the goal is to be using FTPS then we do not want to specify SFTP. We want to specify FTP (even though we will be using a variation known as FTPS).

Once "FTP" is chosen, an "_E_ncryption" option will appear, and by default it will problematically be set to "No encryption". Instead, we will want to make sure this is set to the correct value:

  • In many cases, the preferred value is "TLS/SSL Explicit Encryption".
    • (By doing the above, we will be using what is called FTPeS, also known as "FTP explicit secure".)
  • In some ohter cases, using “TLS/SSL Implicit Encryption” may work better.
  • (A server might support only one of those options, or both. So, you might only be able to be successful with just one of those options when connecting to a specific server.)

For the host name, enter then ame of the

  • What the login username looks like can vary.
    • In many cases, this might be a short name, commonly less than nine characters long, and very possibly all lowercase.
    • If you are connecting in with an account created by cPanel, then this "_U_ser name" ends with an @ followed by a domain name, so it looks like a common Internet E-Mail address. However, this is simply an FTP login account, and there might or might not be an E-Mail address which looks the same.)
      • Warning: the cPanel software has been known to set enable an account holder to set an FTP(S) Account's password to a value that is not accepted by the FTP(S) server! (That may even happen with server-generated randomish passwords.) The only solution is to choose a different password. (Something with just letters and numbers, while less secure, may work. Further details might someday get added to cPanel account holder's guide.)
      • Note: The part after the @ would need to be one of the “domain names” supported by the cPanel account. This might NOT match the “domain name” that the FTP(S) software uses to create the connection. So, if you are provided with a specific FTP login name which has an @ followed by a domain name, it is recommended to make sure to use that account login detail, exactly as provided.
  • Also enter the password.

    • On the "Save" button, I usually like to use the little drop-down arrow. If we are using the "New site" option in the left frame, then there might not even be a "Save As" option. If we are modifying the values of a different site, we could choose either "Save As" to save to a new site name, or use "Save" to change the existing site name.

    This brings up a new dialog box, called "Save session as site". It doesn't really matter what you set this to. Whatever you set this to is what the "Site" will look like in the left frame of the "Login" window.

    (The default "_S_ite name" will show the "_U_ser name" from earlier, followed by an @, followed by the "_H_ost name" from earlier. So, if the user name is something like me@example.com and you are logging into a host name of example.com then the default "_S_ite name" could look something like "me@example.com@example.com".)

    For "_F_older", you can typically just safely leave that set to the default value, which is "".

    There is also a checkbox named "Save _p_assword (not recommended)". If you are confident in your computer's security and so you are sure that it is sufficiently safe, you can place a checkmark in that checkbox.

    Remember the name of the site that you are choosing to use to save these settings. (That is, remember it well enough that you can pick it out from a list which may also have previously-saved sites.)

    Click "OK".

    WinSCP GUI Site Connection

    In the left frame, choose the name of the site that you just created.

    Choose the desired site.

    Upon trying to connect, if FTPS is used, you may see a certificate. You can verify who the certificate is validated by, and what computer name(s) the certificate was issued for. Most importantly, though, WinSCP will show the TLS/SSL certificate's encryption “fingerprint” information, which may look something like:

    • “SHA-256: 01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef
      SHA-1: 01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef:01:23:45:67”

    So, choose one of the following:

    • YES = connect, and store this certificate, which will be good until the certificate renews.
    • NO = connect, but do not store this certificate.
    • Cancel = Do not connect.
    Transferring

    [ info may get added here later... ]

    Using curl

    Using curl might sound great, as that program may be rather widely available. Unfortunately, there may be some downside(s) to trying to use curl with FTPS.

    The biggest one is simply this: curl can support multiple protocols, and a person who creates a curl executable file may have some easy opportunity to select/impact which protocols will be supported by that file. So, some copies of curl will probably NOT support FTPS, even though there are some other copies of curl that do include the program's standard code for handling FTPS.

    https://everything.curl.dev/ftp/ftps discusses curl's support for FTPS.

    The general curl source code may support multiple encryption libraries (even if a specific curl executable might only support a smaller number, such as just one). https://everything.curl.dev/usingcurl/scpsftp covers SFTP and this might be similar...

    If memory serves correctly, there might also have been some limited support for certain functionality (like only some command line options being supported) which may have affected some usefulness (or at least ease of use). If that was indeed ever true, it might have just been with older versions. (Such limitations were, as recalled, documented.) (Then again, such memory is so vague at the time of this writing, it might have been referring to SFTP or perhaps SCP.)

    AUTH SSL

    Part of IETF RFC 4217 “Securing FTP with TLS” Draft 07, Appendix A: “Deprecated SSL negotiation mechanisms” section “ ii) Protection using the 'AUTH SSL' command” says, “This approach is in direct disagreement with [RFC-2228] which requires the PROT command to be issued and so should not be used in new implementations”. This is from Draft 7 of that RFC, and such text doesn't show up in Draft 8 or the final version of the RFC, although one may be able to understand why this approach is disfavored when there are alternatives and this approach conflicted with an earlier standard without apparent beneficial reason.

    [#ftpssh]: FTP/SSH

    “FTP over SSH” refers to routing FTP traffic through an SSH tunnel. For details, see tunneling traffic.

    [#securftp]: Secure FTP

    See: Confusion regarding the name “Secure FTP”. For information about the protocols this may refer to (or similar protocols), see Secure standards with “FTP” as part of the name.

    [#scp]: SCP (“Secure Copy”)

    This protocol has no bright development future, as noted by Wayback Machine @ Archive.org's cache from February 4, 2016: OpenSSH FAQ about adding features to scp, which had this to say:

    "scp is not standardized. The closest thing it has to a specification is "what rcp does". Since the same command is used on both ends of the connection, adding features or options risks breaking interoperability with other implementations.

    New features are more likely in sftp, since the protocol is standardized (well, a draft standard), extensible, and the client and server are decoupled.”

    (The words “a draft standard” were a hyperlink to what can how be seen via Wayback Machine @ Archive.org: IETF page on Secure Shell including a draft visible via Wayback Machine @ Archive.org's draft for Secure Shell Working Group's Internet-Draft for SSH File Transfer Protocol - see also SSH File Transfer Protocol draft-ietf-secsh-filexfer-13.txt as hosted by tools.ietf.org)

    On Microsoft Windows, one of the popular programs for transferring files with SCP is pscp from the PuTTY software suite. PuTTY: links states, “We don't know of a reference for the SCP protocol (which is basically BSD rcp).”

    However, despite SCP having a very bleak outlook for a future, SCP has one quite nice thing going for it, which is that the server for this protocol is basically just built into OpenSSH. (It might be true that SCP really does not need any special support other than the basic functionality of SSH? If so, perhaps other SSH implementations are also compatible with SCP?) So installing an SSH server for remote access can/does end up providing support for SCP clients.

    Historically, the advantage of being supported by OpenSSH servers was more significant, because OpenSSH would not support SFTP by default. That default has now been changed, so SCP no longer has that as a noteworthy advantage over SFTP when people are using recent versions of the OpenSSH software.

    Server support

    This protocol is supported by OpenSSH. With some versions of OpenSSH, the SCP protocol may be enabled by default, while support for SFTP requires a simple change to a configuration text file. With newer versions, this may be even less of an issue because SFTP support may be enabled by default.

    Client-side support

    If the client comes bundled with OpenSSH, then there may be a scp command built in. Otherwise, this protocol is commonly supported by software that supports SFTP. (See details about the SFTP protocol for details.) As a quick summary for Microsoft Windows, available options include the command line program called cURL may be an option. (Simply modify the instructions in the section on using SFTP in cURL so that SCP is specified instead of SCP.) WinSCP (both the command line WinSCP.com file, and the graphical interface provided by WinSCP.exe). PuTTY's command line program PSFTP may not support SCP is an exception to the generalizing of SFTP-supporting software also supporting SCP, but there is also a downloadable command line program called PSCP which is distributed by the same software developers.

    Actually, Wikipedia's “Talk” page referring to SSH File Transfer Protocol: Comment “I don't understand...” has some fairly informative commentary (despite the title of the initial comment). Some details about SCP are mentioned in that commentary.

    Sending data over pipes

    See: grawity's answer to astrogrog's superuser.com question about transferring files. (The capital letters B and C are meant to refer to names of systems.)

    Files transferred over Shell (“FISH”)

    Based on reading Wikipedia's article on FISH, the article indicates that FISH uses an SSH server or an RSH server, but does not need anything beyond just a server that is supporting one of those protocols. (In contrast, SFTP has historically needed support to be added, as it was disabled by default in OpenSSH. Now it is typically enabled in OpenSSH. The SCP protocol has typically been enabled by default in OpenSSH. However, other SSH servers might not have SCP supported by default. FISH can use a special FISH server for better/faster performance, but also works even if the SSH server is not supporting any additional/add-on code beyond what is required for an SSH connection.)

    In other words, a client may be a bit more elaborate/complex by supporting FISH, with the benefit that there is less required from the server.

    Wikipedia's article on the FISH protocol: section called “Implementatations” lists some options. Also, OpenSUSE's Reference: Details about service location protocol (“SLP”) also mentions fish.

    [#ftp]: File Transfer Protocol (“FTP”)

    The popularity of using FTP to transfer files has declined, probably for three major reasons: there is another popular alternative (using HTTP and/or HTTPS), FTP lacks security/privacy/encryption, and FTP can be rather unpleasant in modern scenarios because of the need to deal with incoming FTP connections being made to the client. (This issue with incoming FTP connections commonly ends up being an issue when when using NAT.) These are basically unfixable using the old FTP standards.

    Regarding the latter two causes just given for FTP's loss of popularity, there is no particular reason why technology could not solve those problems. In fact, newer alternatives do exist. However, newer styles of communications do not fit the old specifications called FTP. People can communicate with encryption, but if they do, it is not FTP that is being used. Rather, it is some updated alternative variant. Newer approaches have been given new names (e.g. SFTP and FTPS, which use the same older acronym... There is also SCP).

    For anyone wanting to know more about FTP, here are some resources that may help:

    Major security issues

    Many people know that passwords sent over FTP are sent in plaintext. There are other security issues as well, as documented by D.J. Bernstein's page about FTP security problems (which probably discusses hijacking the session, gaining whatever rights an already logged in user has?) Also, the files being transferred are generally unencrypted. Also, the connection for FTP commands are sent in cleartext, so people can see the commands to change a current directory or create or obtain a file. Also, the protocol is rather incompatible with easy filewall access.

    Understanding the firewalling issues

    OpenBSD PF's guide about Issues FTP discusses these.

    RFC 1579 - Firewall-Friendly FTP discusses some recommendations for helping compatability for FTP clients that are behind a “packet filter” (which is probably more commonly referred to as a “firewall”). However, the basic recommendation is to use the “PASV” command instead of the “PORT” style transfers. All this really accomplishes is to simply shift the burden of knowledge of the FTP protocol to any firewall that is protecting the FTP server. That may be significant and useful, but even this solution does involve having at least one side needing to have special configured support for FTP's rather uncommon behavior and requirements regarding connections.

    The solution: RFC 3022 page 2 says, “Address translation is application independent and often accompanied by application specific gateways (ALGs) to perform payload monitoring and alterations.  FTP is the most popular ALG resident on NAT devices.” (RFC 3022 (NAT) section 4.4: “FTP support” further discusses handling for this protocol. The RFC uses the term ALG: a term that is probably more common is a “proxy”.

    Setting up
    Perhaps see: OpenBSD FAQ 10: Guide to setting up Anonymous FTP.
    File listing formats

    The format used for a file list may vary among different FTP sites. There are multiple such formats used. (This might (or might not?) be compliant with standards as defined by RFCs, but either way, isn't necessarily entirely uncomon.

    The home page for Uwe Ohse's FTPCopy mentions an EPLF format, and “the traditional listing format (/bin/ls)”.

    Available commands

    FTP is designed around the concept of a client sending commands to the server.

    RFC 2428 added the “EPRT” and “EPSV” commands. These protocol extensions that operate similar to the previous “PORT” and “PASV” commands, but may be more flexible in environments where IPv4 is not being used (such as environments that are using IPv6).

    site-specific commands

    In some (rather newer and uncommon) cases, FTP servers may provide some commands that weren't initially part of the recognized set of FTP commands. This can be accomplished in a way that is compatible with the FTP protocol by using an FTP command called “SITE”. This allows the FTP site (a.k.a. the FTP server) to have site-specific commands.

    If there is any one “SITE”-specific command that is most universally recognized, it might be “HELP” (which would be sent by the client as “SITE HELP”). That may provide a list of what site-specific commands are supported by the FTP server. As another example that has actually been seen, a client might send a command like “SITE SEARCH somefile.*” to try to perform a search for a certain filename. The FTP protocol is rather flexible in that FTP client software will often support sending such commands, and even to receive a response, even if the FTP client has no special understanding of what the server will be doing in response to the command.

    There is no real restriction regarding what the FTP server should do upon receiving such a command. For example, the FTP server could, at least in theory, respond to a certain recognized “SITE”-specific by rebooting the FTP server. FTP commands supported by ProFTPD show that changing (ldquo;group” and “ownership”) security settings for a file may be implemented. Naturally, some of these types of commands may be things that would always be desired to be available to all authenticated users. The FTP just facilitates the idea of the FTP client sending such a command to a server, but does not specify how the server responds. So, it would be up to the FTP server to decide whether the response involves taking any specific action.

    For example, command line FTP software may recognize a “QUOT” command (which is a case-insensitive abbreviation of the word “quote”, which may also be recognized as the same command), or perhaps some other command such as “literal”. (These are commands entered into the FTP client, not commands sent over the network.) This style of command may be supported by a number of clients, including graphical programs. By letting the FTP client know that using such a command is desired, and then providing any additional needed information, may cause the clieent to send desired information to the FTP server (even if the FTP client does not understand what the specific command is intended to do). The FTP clients then pass along any additional information by using the standard FTP command called “SITE”.

    curl's --disable-eprt command line offers some flexibility for the program, and documentation which states, &dlquo; EPRT and LPRT are extensions to the original FTP protocol, and may not work on all servers, but they enable more functionality in a better way than the traditional PORT command.”

    Server reply codes

    The format of the reply codes is discussed by RFC 959 (“FTP”) page 37 and page 38. The previous page starts the topic (at the start of section 4.2) and later pages show some specific meanings of specific numbers.

    [#rsync]: rsync

    This software can connect to various remote systems, including (but not limited to) remote systems that run rsync as a server (specifically listening to rsync traffic).

    rsync has lots of options.

    Although rsync might not have a lot of built-in security, security can be applied. Eddified's comment to astrogrog's superuser.com question about transferring files shows how. (The capital letters B and C are meant to refer to names of systems.)

    [#rcp]: rcp

    Generally considered to be inferior to scp because of the same privacy/encryption/authentication concerns that lead to SSH being considred superior to rlogin/rsh

    Windows XP may come with RCP Microsoft documentation on XP: Rcp command, though it seems Vista does not.

    [#tftp]: Trivial File Transfer Protcol (“TFTP”)

    The first T stands for “Trivial”. This protocol may be fairly simple technology, and be fairly easy for a software programmer to support. In practice, this protocol may often be found used in embedded scenarios, such as being used as part of the PXE process supported by BIOS chips. Specialized hardware devices that can connect to the network (e.g. a router made by Cisco) have been known to support using TFTP to upload and download files that store configuration settings, and also files that contain firmware versions. (This may, in some cases, be a way to effectively update the device's firmware.)

    Details on the protocol are available by IETF STD 33: The TFTP Protocol (RFC 1350: The TFTP Protocol (Revision 2). That updates RFC 783 which itself updated January 29, 1980's Internet Experimental Note 133: The TFTP Protocol.

    TOOGAM's Software Archive: File Transfer Protocols says, “A TFTP client may come with some versions of Microsoft Windows. Be sure to use the -i switch for files that padding shouldn't be used on.”

    This protocol is widely considered to be very simple in nature, lacking features that may be found in other protocols. However, even this protocol was an enhancement of an earlier protocol, called EFTP. (Wikipedia's page on EFTP contains a bit of details about that older protocol.)

    Implementations

    Check if the operating system already has a TFTP server bundled in. (Unix users: run “man tftp”, “man tftp” or “apropos tftp”.)

    Options for multiple platforms
    Open TFTP

    “MultiThreaded TFTP Server” which is “Open Source Freeware” and for “Windows/Unix”

    Open TFTP main page, or better, Open TFTP Server project page, which notes a license of GPLv2.

    Options for just Microsoft Windows
    Microsoft's software

    Microsoft Windows may have a feature called “TFTP Client”. Ocenon Consulting information about Microsoft's TFTP server notes \I386\TFTPD.EX_ on the installation CD of Win2KPro, Win2KSvr, XP, Windows Server 2003. The file may be extracted with:

    extract \I386\TFTPD.EX_ %SystemRoot%\system32\dllcache

    Ocenon Consulting's information provides details about setting up registry entries to control access, and creating a service which specifies a directory name.

    Philippe Jounin's Tftpd32/Tftpd64

    Supports IPv6, TFTP, DHCP, DNS, SNTP, Syslog. Tftpd history notes this has been open Source since June 2008.

    SolarWinds
    SolarWinds Free TFTP, SFTP, and SCP server
    Cisco IOS built-in TFTP server
    conf t
     tftp-server ?

    According to Cisco Product Tech Note: Copying data from one router to another, “Note: The options given above for the tftp-server command may vary for different platforms.” The above command may show a list of devices that TFTP may serve data from. One option may be a full file pathname, such as:

    conf t
     tftp-server flash:/c2500-js-l.122-10b

    Ashish Shirkar's support forum Document Source K11044112: How to configure a Cisco router as TFTP server notes, “The router is not a fully functional TFTP server. It can only serve files for download. You cannot use this feature to upload files into the serving router”.

    Others

    Wikipedia's article for Trivial File Transfer Protocol: section called “Known TFTP implementations”

    Remote Access Software

    Some remote access software may provide an interface for copying files to a remote system. Details may be in the section about remote access software: handling remote files.

    Drive sharing

    Sharing a data object, as in sharing a hardware device, (rather than sharing a filesystem volume or objects found on filesystem volumes), is covered by remote access: sharing objects.

    Comm port protocols

    Older computers could often be connected using a “null modem” cable, or a similar device. Networking hadn't yet exploded in popularity like it did later as TCP/IP over Ethernet became a new standard, but there was some software for this.

    Serial port/line/cable
    Bi-directional

    One feature that a BBS could offer its users was having the BBS offer files to download. To do that, the BBS had to have files to offer. A SysOp (“system operator”), which is a person who had administrative control over the BBS (and typically ran the hardware for the BBS, and owned the BBS) could try to acquire new files by encouraging people to upload files, which might be doable by placing some sort of limits upon users but providing less restrictive limits when people uploaded files. (Such restrictions commonly involved an ability to download files, or limitations involving how much time a user could perform a certain activity like using up one of the BBS's phone lines, and theoretically could involve other restrictions such as access to posting messages in certain locations, or access to certain programs that could be run by the computer that is running the BBS software.)

    Being able to have a user download a file and also get credit for uploading a file, at the same time, was attractive for some users (who got the benefit of having a restriction become more relaxed) and attractive to SysOps (who wanted to increase the amount of data offered for other usrs to download). Compared to downloading and then uploading, a bi-directional transfer allowed the phone connection to be ended sooner, which was nice in a day and age when connecting to a BBS caused a phone line to be used up until the connection was finished, resulting in the phone to be unavailable for voice calls (for the user) or other incoming connections (for the BBS) as long as the connection remained active.

    The one protocol that offered this feature and started to gain some popularity was HS/Link. Soon after that, Internet access started to become more popular, and bi-directional protocols became less important because people could just use multiple connections that each used data transfers that were mostly single-directional.

    HS/Link

    Previously Shareware, and later Open Source, this allowed bi-directional transfers. The “registered” version of the Shareware product allowed a person to start a chat session, so people could communicate.

    For some reason, this software would occasionally be rather difficult to set up, especially to get bi-directional transfers working. However, once bi-directional transfers were working, the obvious time savings of allowing files to be transfered in both directions simultaneously was typically worth the setup time. After this protocol became popular, BBS's started to check for uploaded files after a person downloaded files.

    [#zmodem]: Z-Modem

    When users called a public Bulliten Board System (“BBS”), this was the most popular protocol. Not only were there multiple implementations, but it supported features including resuming file transfers that were previously interrupted.

    The protocol was sometimes spelled as Z-Modem, and other times as ZModem. Like XModem and YModem, all-uppercase variations were also commonly seen, or having just the first letter uppercase, and occasionally all-lowercase variations have also been seen. Having a hyphen after the first character of the name was a style more commonly seen with Z-Modem than with XModem or YModem.

    Rumors have existed that some implementations may have included backdoors. (This rumor may have been spread the most about SZModem. Whether that is because SZModem had an internal command shell, which may have frightened people, or because of truth, has not been verified by the author of this text (at the time of this writing).) lrzsz web page notes about older Unix ZModem source code: “Security was not an issue to the author. The ability to let the receiver execute any command the sender tells him is nothing more then a really large security hole (as large as running older sendmail versions). Hackers dreams came true.” A lot of programs may have used at least some shared source code, and programs using Z-Modem may have especially been likely to use some of the older free code provided by Chuck A. Forsberg and/or his organization, Omen Technology.

    Details about some implementations are available at TOOGAM's softare archive: file transfer protocols.

    [#ymodem]: YModem
    Why YModem was considered nice

    YModem-G could feature transfers that go faster than ZModem. This “compressed” data stream's faster speed simply came from removing some data integrity checking and flow control features, according to details provided by Wikipedia's page on YMODEM.

    Other than that, the only advantage to using any YModem instead of ZModem is only if YModem was an available option when ZModem was not. If ZModem was an available option, the slight speed advantage that could be obtained with YModem-G was the only compelling reason to prefer any variation of YModem over the newer ZModem.

    Disadvantages

    Wikipedia's page on YMODEM makes the claim that there was “was a large number of mutually incompatible YMODEMs.” (Also, more information is available on that page.)

    Portland State University's “The Guide”: Information on XModem, YModem, and ZModem states, “Some communication software programs, most notably Procomm Plus 1.x, also list Xmodem-1K as Ymodem. Procomm Plus 2.0 no longer refers to Xmodem-1K as Ymodem.” So there was some reason that users could have a certain amount of confusion between exactly what consistuted XModem and what constitued YModem. Wikipedia's page on YMODEM indicates that the key advantage of “The original YMODEM” is “that it sent the file's name, size, and timestamp in a regular XMODEM block, "block 0", before actually transferring the file.”

    [#xmodem]: XModem

    Unlike many other protocols, XModem does not transmit the filename. Therefore, the receiver must specify what filename to store the received file. XModem may also be guilty of padding a received file, so the received file may be larger (in order to make the resulting filesize equal to the boundary of a pre-defined block size).

    MS KB 114778: “Windows NT Terminal Supports XModem-1K Protocol shows this was supported by Windows Terminal.

    Kermit

    Historically recognized by Info-Zip as being more well ported than UnZip, this software may have been popular on some older platforms such as VMS. City College of San Francisco's page on HyperTerminal provides some brief instructions: at a C-Kermit> prompt, type “set file type binary” (or, if preferred and if concepts of translating text formats between Unix and MS-DOS is understood, perhaps use “set file type text”). Then, use a command of “receive” or “send filename”.

    Most of these, and other protocols, are discussed in more detail on TOOGAM's page about file transfer protocols. The page provides details about implementations that are compatible with DOS. Many protocols were also available for other operating systems. For Z-Modem, Y-Modem, and X-Modem (also commonly written as ZModem, YModem, and XModem) variations, a cross-platform option includes lrzsz.

    Parallel port
    DOS

    Microsoft's InterSvr could connect with Microsoft's InterLnk program. This software came bundled with MS-DOS 6 as well as a downloadable package meant for users of Windows 95. (Information on obtaining that package may be on TOOGAM's Software Archive: page related to MS-DOS.)