57

I have over 20 years experience in Un*x, and I have been using scp for immemorial times. scpis over SSH, therefore I consider it as secure as the latter. Now, in my company, where I recently took up a job, the Security Officer says that scp should not be used, because it is unsafe and obsolete. sftp should be favoured over it (yet over SSH too...)

I don't immediately agree with this, based on the infrastructure underneath scp, and based on how popular and trusted scp is in the professional community, and among my other colleagues from my ex-companies. I don't want to change my mind just because some CSO said it.

  • This said, is there here a subject?
  • Is scp suddenly the blacksheep?
  • Is is just a mere security expert debates in higher spheres?
  • Or is scp just good to use?
  • 30
    They are probably referring the what was written in the release announcement for OpenSSH 8.0 when CVE-2019-6111 was fixed in scp: "The scp protocol is outdated, inflexible and not readily fixed. We recommend the use of more modern protocols like sftp and rsync for file transfer instead." openssh.com/txt/release-8.0 I'm not writing this as an answer as I can't say anything useful about the technical bits or the implications. – Kusalananda Mar 5 '20 at 12:40
  • 2
    It also depends whether you/they mean SCP and SFTP protocols in general, or scp and sftp clients from OpenSSH package. – Martin Prikryl Mar 5 '20 at 13:20
  • 8
    Both scp and sftp work over a ssh channel, so they're just as secure as the ssh channel (in fact, both could be made to work over any reliable channel, but they're usually run over ssh). Neither of them is making the security of the channel or of the ssh infrastructure stronger or weaker. All the security theater is about someone connecting to a rogue server via scp, and the server being able to overwrite some of user's files if they used a glob (eg. scp foo:dir/*.txt ~ resulting in .bashrc being overwritten). – mosvy Mar 5 '20 at 13:26
  • 1
    Notice that the "fix" for CVE-2019-6111 doesn't have any effect when -r is used, so it's mostly a feel-good change. – mosvy Mar 5 '20 at 13:26
  • 10
    Depends which one. SCP-173 is very unsafe. SCP-294 seems to be pretty safe if used correctly. – user253751 Mar 6 '20 at 14:32
36

It's marginally "unsafe"

It was marginally "unsafe" before the addition of scp -T in OpenSSH 8.0 and it still is marginally "unsafe" when using scp -r.

Like other answers have stated, claims that scp is unsafe come from the client's previous inability to verify that it's receiving what it requested. The reason why scp couldn't verify is because the request is made using shell code running in the server's environment (with the server's state).

For example, let's say that the server's shell is set to zsh with extended glob, and I have my project directories set as zsh dynamic named directories for quick access. If I want to get a file from Rails project foo, I could get it with:

scp server:~foo/config/database.yml .

zsh on my server expands ~foo to ~/work-for/client/$client_name/foo.

If I want to get the server's 10 newest regular files, I could do:

scp server:'*(.oc[1,10])' .

If the server has plain bash, I could do:

scp server:'$(ls -t | head -10)' .

If I wanted to get the files that contained a pattern foo in their content, I could do:

scp server:'$(grep -l foo *)' .

There's just no way for the scp client to verify these kinds of requests that use shell code. However, it is a concern that it enables a malicious server to respond to:

scp -r server:foo/ ~

with overwriting .ssh/authorized_keys. In the eyes of scp, foo/ is server shell code that will evaluate to who knows what.

Enter scp -T:

-T Disable strict filename checking. By default when copying files from a remote host to a local directory scp checks that the received filenames match those requested on the command-line to prevent the remote end from sending unexpected or unwanted files. Because of differences in how various operating systems and shells interpret filename wildcards, these checks may cause wanted files to be rejected. This option disables these checks at the expense of fully trusting that the server will not send unexpected filenames.

To summarize, the previous default behavior of scp was moved to -T, and now the default is to check what's being received, using the provided argument as a simple pattern, when one's not doing a recursive copy. I believe it recognizes simple globs and escapes (looking at the source, it uses fnmatch(3) for the matching, with flags set to 0). In other words, it behaves more predictably when you're not looking to take advantage of its unique ability to specify files by shell code.

So now, if you don't use -T and you don't use -r, the only way to overwrite stuff like .bashrc is to ask for it explicitly. If you want to use shell code, you'd have to use -T at the expense of trusting the server:

scp -T server:'*(.oc[1,10])' .

So now you get the safety in the simple, non-recursive cases without completely giving up the unique ability that makes scp more useful than other utilities like sftp or rsync.

Can scp be replaced by sftp?

sftp can't specify the files it wants with shell code. It only accepts actual file paths. It's more limited that way. If you only needed scp for simple filepaths, then yes. However, if you want the added power of being able to specify the files from a simple command with server-side shell code (albeit at the expense of having to trust your server), then I think your only choice is scp.

Why the quotes around "unsafe"?

It was unsafe, but only when you wouldn't trust the server to not be compromised. In my case, and perhaps for the majority of people, we use scp with servers that we completely trust in other ways anyways. In particular, I use it to login from my laptop to my desktop or vice versa. If we can't trust our own devices, then what can we trust? That's why I think calling it just plain unsafe is hyperbolic. It's not comparable to how we call telnet unsafe, for instance.

I still appreciate the change to requiring -T, though. It is safer. Also, it's certainly true that for those people that don't need the features enabled by -T, there really isn't much advantage in using scp over sftp or rsync.

  • @mosvy I thought I had tried it before, but I guess not. I've deleted the mention of quoting support. Do you have any source on -r turning off the filename check? That's something that's not as simple to check as the quoting thing. I can't see why support for -r filename checking couldn't have been added either. – JoL Mar 7 '20 at 8:30
  • @mosvy Nevermind. I can confirm by seeing that it lets me use extended glob on files when using -r. I still wonder why -r couldn't be supported. – JoL Mar 7 '20 at 8:48
  • You can check my demo -- you can modify the perl script to experiment with different behaviours from an assumed rogue remote scp. As to -r, I couldn't figure out any way the file checking could be supported with -r (and apparently, neither the openssh devs did). Of course, they could've added an extra option to set a pattern of accepted paths (independent of the pattern used for the source argument, and of the other arguments used with scp). But they did not. – mosvy Mar 7 '20 at 9:36
  • 1
    @mosvy What do you mean a pattern independent of the source argument? Why wouldn't the source argument work as the pattern? If the pattern is foo/, couldn't scp match the name of the received directory and accept all files that go under it on match? – JoL Mar 7 '20 at 9:41
  • 1
    It's brace_expand which generates the list of patterns the file names will matched against. If there are no patterns, no check will be done. – mosvy Mar 7 '20 at 16:22
21

The way I read it is, "it depends".

According to CVE-2019-6111

However, the scp client only performs cursory validation of the object name returned (only directory traversal attacks are prevented). A malicious scp server (or Man-in-The-Middle attacker) can overwrite arbitrary files in the scp client target directory. If recursive operation (-r) is performed, the server can manipulate subdirectories as well (for example, to overwrite the .ssh/authorized_keys file).

So if scp goes between hosts on your premises (datacenter), it is likely (but not certain) than no MITM attack can be performed.

However, if you fetch business files from a customer/partner over the world wild web, you should rely on sftp, or better, ftps. (At least, ensure that the scp client and ssh server have proper versions)

  • 1
    "or better ftps" - It's kind of peripheral to the question, but if your suggesting ftps is better, it might be worth a brief mention of why (and/or link explaining it). – Ian D. Scott Mar 5 '20 at 23:58
  • 6
    I would not consider ftps to be better. I would trust ssh over ssl/tls considering the history of vulnerabilities between the two – slebetman Mar 6 '20 at 0:20
  • 7
    . . . but that CVE has been fixed. If your premise is that we should act as though all past security issues are still in effect, then I don't see how you can recommend any other software, either. (Are you really saying that sftp and ftps have never had any potential security issues?) – ruakh Mar 6 '20 at 4:36
  • 4
    @slebetman History of bugs is a red herring. In many cases, more bugs are found in a particular protocol or system because it's a larger target because it's used more and gets them identified more often. You didn't address my main point, which is that in SSH, most people use it and blindly type "y" the first time they SSH into systems across the WAN without checking the fingerprint. TLS has an infrastructure of checking certificates automatically, which improves security. – Greg Schmit Mar 6 '20 at 6:12
  • 3
    @slebetman It's precisely because SSH was developed for sysadmins that it wasn't hardened against human error in the way that TLS was. And sysadmins make human errors (like blindly typing "y" when prompted to check the key fingerprint) all the time. – Greg Schmit Mar 6 '20 at 6:14
6

I'd say a lot of Unix commands become unsafe if you consider a MITM on SSH possible. A malicious sudo could steal your password, a malicious communication client could read your mails/instant messages, etc.

Saying that replacing scp with sftp when talking to a compromised server will somehow rectify the situation is very optimistic to say the least. Whatever damage scp can do to your local files can also be done from a binary file, shell script, Python file, Makefile, etc., and a rogue sftp will happily serve you these.

In short, if you don't pay attention to which servers you SSH into, there's a high risk for you to be screwed no matter which tools you use, and using sftp instead of scp will be only marginally safer.

This isn't to say that switching to sftp is a bad idea: if it's a superior tool for the task at hand, then you have a good reason to switch, which is, incidentally, not related to security.

4

There's a lot of confusion about the new OpenSSH changes to scp made in response to CVE-2019-6111, and how safe they're supposed to make everything.

Their purpose is to prevent a rogue server used as source for the files from sending other filenames than requested, and overwrite random files on the local machine.

But they have no effect when the -r option is used. Using -r implies -T.

While perfectly logical, many people would fail to realize it, and they will be lulled in a sense of complacency by always expecting scp to check the filenames. Until they meet the hard truth, one day. The "security" offered by this is no better than alias rm='rm -i'.

Since it can be pretty convoluted to set up a rogue ssh/scp server just for testing, you can use the -S program option of scp (which directs it to use another program than ssh to set up the channel) to verify my claim.

Here I'm using a small executable script ssh_from_hell, which, no matter what asked for, always sends a lolcats.lol file:

$ chmod 755 ssh_from_hell
$ scp -S ./ssh_from_hell user@host:foo.txt .
protocol error: filename does not match request
    # OK, as expected

$ scp -S ./ssh_from_hell -r user@host:foo/ .
lolcats.lol                                   100%   12    62.0KB/s   00:00
$ cat lolcats.lol
LOL LOL LOL


$ cat ssh_from_hell
#! /usr/bin/perl
use strict;

$|=1;   # autoflush
sub readack { local $/=\1; <STDIN> }
sub ack { print "\0" }
my $data = join '', <DATA>;

readack;
printf "C%04o %lld %s\n", 0666, length($data), "lolcats.lol";
readack;
print $data;
ack;

__DATA__
LOL LOL LOL

Another infelicity brough about by the new changes is the fact that you can no longer quote the remote filename, instead of

scp 'user@host:"a file with spaces and * love *.txt"' .

you should use

scp 'user@host:a\ file\ with\ spaces\ and\ \*\ love\ \*.txt' .

However, some influential developers apparently love braces, so they have also added an ad-hoc pattern matching implementation with braces support to scp -- they could've probably used glob(3) with GLOB_ALTDIRFUNC|GLOB_BRACE, but it's always more fun to write new code. Anyways and fwiw, notice that the brace expansion implementation in scp is almost csh-like ie. {{foo}} will expand to foo:

$ scp -S ./ssh_from_hell 'user@host:{{lolcats.lol}}' .
lolcats.lol                                   100%   12    61.6KB/s   00:00

Yet not exactly the same as that from csh, perl and glob(3):

$ scp -S ./ssh_from_hell 'user@host:lolcats{}.lol' .
protocol error: filename does not match request

And also buggy:

$ scp -S ./ssh_from_hell 'user@host:lolcats{,}.lol' .
protocol error: filename does not match request
3

man scp

scp copies files between hosts on a network. It uses ssh(1) for data transfer, and uses the same authentication and provides the same security as ssh(1). Unlike rcp(1), scp will ask for passwords or passphrases if they are needed for authentication.

You asked is scp unsafe? It can be, just like anything else not set up and used properly.

Man in the middle (MITM) vulnerability, you know that initial popup you get the first time ssh'ing to somewhere, the one you ignore and just click ok on...

the server's host key is not cached in the registry. you have no guarantee that the server is the computer you think it is. The server's ssh fingerprint is blablabla.

It is not SSH's (or scp's) fault. It is yours for not using the protocol properly.

Once you have established the ssh server your connecting to is who it's supposed to be, then it is a simple matter of (in my opinion) of using SSH protocol 2 and AES-256 cipher. That is the bulk of your security; if you don't tailor your sshd_conf (and the client ssh_config) and leave it defaulted then that's on you.

here's an except of an sshd_config you can ponder over

Protocol                                     2
Ciphers                                      aes256-ctr
MACs                                         hmac-sha2-512,hmac-sha2-256
# MACs                                       hmac-sha1
PermitRootLogin                              no
AuthorizedKeysFile                           .ssh/authorized_keys  {set this up}
IgnoreRhosts                                 yes
IgnoreUserKnownHosts                         yes
StrictModes                                  yes
UsePAM                                       yes

according to CVE-2019-6111

the scp client only performs cursory validation of the object name returned (only directory traversal attacks are prevented). A malicious scp server (or Man-in-The-Middle attacker) can overwrite arbitrary files in the scp client target directory. If recursive operation (-r) is performed, the server can manipulate subdirectories as well (for example, to overwrite the .ssh/authorized_keys file).

that is taken out of context. Don't connect to a malicious ssh server in the first place. Don't blame SSH for someone exploiting the protocol setting up their ssh server to overwrite arbitrary files in the scp client target directory. Make use of the server/client keys to establish the SSH connection properly in the first place and there's no MITM malicious server.

scp, which is ssh, is safe. Saying scp is not safe is inherently saying ssh should not be used because ssh is unsafe and that is not true.

SSH = secure shell

scp = secure copy over SSH

ftp = file transfer protocol

sftp = SSH ftp

ftps = ftp over TLS/SSL

Should scp be replaced by sftp?

when you can't be bothered by with the server's host key/fingerprint and just click ok, ask yourself how then is that ok with sftp (connecting to a server you have no guarantee is who you think it is).

once the SSH communication tunnel is established between two points, properly, the semantics of communication within be it secure copy or the file transfer protocol is trivial at that point. scp, which is ssh, is safe. Saying scp is not safe is inherently saying ssh should not be used because ssh is unsafe. And that is not true. If I call you on the phone, and you cause bad things to happen on my end, that's not the phone company's fault.

"The scp protocol is outdated, inflexible and not readily fixed. We recommend the use of more modern protocols like sftp and rsync for file transfer instead."

pleeeasssee.... rsync performs no encryption on its own, and you run into the same problem of no guarantee who you connect to is who you think it is. But in this insinuation rsync gets a pass? Careful of where you take recommendations from.

  • Just because you know you're connecting to the server (or receiving a connection from the client) you think you are doesn't mean that the software on your end mediating and acting on traffic coming/going over that connection does only the precise things you intend it to. The biggest advantage of sftp is that it's built around a simple, clear specification. That makes reading and auditing code easier. – Charles Duffy Mar 6 '20 at 0:30
  • 3
    In any of these (sftp, scp, rsync), the authentication and encryption layers are unrelated to how operations and their results are serialized onto the wire -- you could run the sftp protocol over an unencrypted serial line if you wanted to, or the scp protocol as well. (Do the out-of-the-box clients make that easy? No, but that doesn't meat it couldn't be done). Which is to say -- I don't see the valid complaints as being about authentication and encryption in any of these cases. Minimizing implementation complexity to have code that can be comprehensively audited is key. – Charles Duffy Mar 6 '20 at 0:31
  • @CharlesDuffy "Do the out-of-the-box clients make that easy?" Yes, they do. Just use the -S ssh-like-program option. – mosvy Mar 6 '20 at 8:02
  • 3
    "rsync performs no encryption on its own" -- What are you talking about? rsync uses ssh by default to connect to the server. – JoL Mar 6 '20 at 17:34
  • 3
    I also have to disagree with the idea that restricting the servers ability on what they can do with the client does not contribute to added security. You can say that scp is safe because ssh is safe, but it's not like safety is a black or white thing. scp is safer than scp -T. That's fact. – JoL Mar 6 '20 at 17:39
-3

They are not correct you are!

sftp is a derivative of ssh. I think he meant to not use FTP and use sftp.

SCP and sftp are running on top of SSH for the most part so if they want you to not use SCP they shouldn't want you to use SSH either (or sftp for that matter). Both sftp and scp allow secure file transfers, encrypting passwords and transferred data.

sftp can do some things that scp cannot but not security related as far as I know

Also SCP is faster than sftp is it uses a faster algorithms.

Links that show sftp is a derivative of ssh.

https://www.linux.com/tutorials/transfer-files-securely-sftp/

https://www.goanywhere.com/blog/are-ssh-and-sftp-the-same https://www.technology.pitt.edu/security/secure-shell-ssh-and-sftp

  • 2
    Correct. Except that 1) SFTP is not a derivative of SCP. The protocols are completely different. 2) There are specifics of the SCP protocol what make its implementations more prone to some security bugs (see the comment by @Kusalananda). – Martin Prikryl Mar 5 '20 at 12:50
  • 2
    "SFTP is a derivative of scp." -- have a source/reference/further explanation on that? "SFTP can do some things that scp cannot" -- well, I don't doubt that, but it would be useful to mention at least some of those things. "Also SCP is faster than sftp is it uses a faster algorithms." -- Citation needed. – ilkkachu Mar 5 '20 at 13:02
  • 2
    scp is a derivative of rcp. Neither has any code relationship to sftp, beyond both scp and sftp depending on the underlying ssh transport. – user4556274 Mar 5 '20 at 13:18
  • @ilkkachu "> SCP is faster than sftp -- Citation needed" Here you go. sftp implements another layer of blocking/packets that should be acknoledged on top of that of the channel it runs over. You have sftp over ssh over tcp, each doing its own send/ack thing. Just add a bit latency to the mix. – mosvy Mar 5 '20 at 13:54
  • I did make a mistake. I meant sftp is built on ssh. And I still stand by my comments. It has been corrected and some links to prove my point. – Mark Stewart Mar 5 '20 at 21:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.