SCP vs. SFTP

From my expeditions into the internet I’ve found that there is much confusion around Secure Copy (SCP) and related protocols like Secure File Transfer Protocol (SFTP). There are plenty of forum posts and search queries of the type “Which is more secure, SCP or SFTP?” The short answer is: SFTP is preferred, though SCP can be fine. Sounds like there is more to it? Well there is, and to understand the answer better let’s first touch on how files were transferred through the early internet.

Original Network File Transfer Programs

When computer networking and the internet were young there was little to no focus on, and no need for, robust security. Therefore commands like rcp and ftp were just fine, even though they are woefully insecure by today’s standards. The habits that users formed using these commands were difficult to banish. Today we must worry about (and write extensive articles about) which command is the most secure, lest we ever forget the lesson of putting security second.

In the late 1990s security was eventually added to the older network file transfer commands - new scp and sftp commands were created. These commands rely on SSH connections for security, but otherwise utilize the original protocols to be effective. While these commands continue to be maintained through the OpenSSH package, it’s doubly true that the commands are based on much older commands and that both incorporate SSH. Therefore, as far as the security of the connection is concerned: SCP and SFTP are equally secure.

Another Contender, FTPS

But they were all of them deceived, for another command was made…

…but seriously, another variation of secure FTP service was made, FTP over SSL. It’s fine choice for those who want to use it, though an argument can be made that SFTP is superior in environments that are already capable of SSH. FTPS requires the use of ports 989 and 990, and must have an X.509 certificate (from a public certificate authority). Meanwhile SFTP uses your existing port 22 (because it runs over SSH’s port) and utilizes SSH’s configured certification method. Adding FTPS to your environment that already has SSH configured means extra work configuring firewalls and certification, when you could just piggyback on SSH.

Who is SSHFS?

Some may know of yet another command, sshfs. This command is for connecting to a remote host’s file system using SSH, allowing you to create a mount point or “mapping” to access the remote file system locally. In actuality sshfs runs over SFTP, so the security of the command and other considerations are the same as those for SFTP.

So how does SFTP work out to be the “preferred” method?

No surprise, this recommendation comes with a slight caveat. Before OpenSSH version 9 scp was still based on the original rcp command, which had some limitations I’ll discuss below, but which ultimately meant that scp was not as performant for some operations and had many vulnerabilities that couldn’t be mitigated without breaking command functionality. The caveat is that in OpenSSH version 9 a change was made to completely retool scp so that it now uses sftp in the backend. So now, scp is sftp, and this concludes the argument over which is better.

But why was old scp abandonded? Though the underlying SSH connection was just as secure in scp as it was insftp there were other flaws that could be exploited maliciously. Typically only by authorized users though.

In one scenario an scp connection would request a file from a remote host, but would not check the filename of the file returned by the remote host, which would see scp accept any file from the remote host. scp was later fixed to check the filenames of the files it would receive, but at that time OpenSSH noted that scp was “outdated, inflexible and not readily fixed”.

In another scenario, requesting a filename that includes single quotes and a section in backticks would result in the ability to execute arbitrary code included within the backtick section on the remote host.

So, in short, OpenSSH understood the codebase of sftp to be more robust and wished to support it over the work required to fix scp (which would also likely break it).

Windows SSH/SCP and GUI Utilities

Since I prefer to run Windows as my everyday driver, and management host, I’ve certainly needed SCP-like functionality between my Windows environment and my Unix-like servers from time to time. What to do since SSH has historically been Unix-only? Well, ever since Windows 10 version 1809/Windows Server 2019, Windows has included support for OpenSSH (including SSH, SCP, and SFTP). Therefore, you can initiate an ‘ssh’, ‘scp’, or ‘sftp’ session directly from Powershell (or Command Prompt, should you choose).

WinSCP

However my preferred utility for managing SCP connections from my Windows host is WinSCP. This GUI utility provides excellent file transfer management, over an SCP or SFTP connection (and some others too). The software also provides an SSH client direct from the GUI. It uses the features of SSH and your chosen protocol to show directory listings in the GUI, and can also keep directories automatically synced while the connection is active. Connection properties can also be saved so that remote hosts can be revisited quickly in future.

Rsync

And lest we forget, there is also rsync, which is an extremely capable tool, though somewhat to it’s own detriment. Many users complain that Rsync’s options are too complex for daily use, requiring such a verbose command specification that issuing an rsync command with sane behavior constraints may require up to 6 or more command line switches. Most are appreciative of the simpler command syntax of ‘scp’ and even ‘sftp’ for daily use, over that of rsync.

References

I leaned a lot from the following articles as I researched for this summary: