I have a few observations about this article.

Generally, try not to use SCP. It has been a crufty old program from the Berkeley R-Utilities, but newer OpenSSH releases have rewritten it to use the sftp-server server instead. There will be wildly different behavior between these implementations.

The backend SCP changes are documented here:

https://lwn.net/Articles/835962/

If you need something that SFTP cannot do, then use tar on both sides.

PuTTY has implemented their pscp to prefer the sftp-server for many years, in a long prediction of the eventual abandonment. Their pscp implementation is a better drop-in replacement than the OpenSSH solutions.

The allure of SCP is retry on failure, which is somewhat more difficult with SFTP:

  until scp source.txt user@target:dir/
  do echo target down; sleep 300
  done

Converting that to pscp is much easier than SFTP.

I also have an older rhel5 system where I am running tinysshd to use better SSH crypto. Due to upgrades, NFS is now squashing everything to nobody, so I had to disable precisely these checks to let users login with their authorized_keys. I can post the code if anybody is curious.

▲ an hour ago | parent | next [-]

[deleted]

▲ elevation 3 hours ago | parent | prev | next [-]

I occasionally use `scp` around my network and have for years. It works great and its simple interface is easy to remember. I don't want to sftp if I have to use tar on both sides. I might type rsync and but then I remember something about the trailing slash will cause the command to behave differently the second time. I just don't need yet another syntax I'll misremember. As long as scp is in my distro's repositories, I'll be using it.

	▲	fsckboy 2 hours ago \| parent [-]
		easy to remember, if you don't use trailing slashes ever, it will just work every time

▲ eikenberry 2 hours ago | parent | prev | next [-]

> Their pscp implementation is a better drop-in replacement than the OpenSSH solutions.

What makes it a better drop in replacement?

▲

chasil 2 hours ago | parent [-]

Several reasons.

-PuTTY pscp allows raw passwords on the command line, or from a file. OpenSSH is unreasonable in refusing to do this.

-Scripting can adapt to a .netrc easily; OpenSSH will never do this.

-Modern OpenSSH is a nightmare when using legacy crypto, while pscp is fluid. There is nothing wrong with hmac-md5, and no reason to refuse it. I will take PuTTY or dropbear in a heartbeat over these burned bridges and workarounds.

https://www.openssh.org/legacy.html

-pscp does not link to dozens of libraries as ssh/scp does, so it is easier to build with less dependency. The ldd output of ssh and scp on rhel9 is 23 libraries, while PuTTY is 3 [package obtained from EPEL].

-pscp strongly leans to SFTP on the backend and can be directed to use it exclusively, so there is no ambiguity.

-Using pscp with a retry on fail is much easier than sftp -b.

-The wacky cipher control on rhel8 does not impact the PuTTY tools.

That is an extensive list.

	▲	jolmg 12 minutes ago \| parent [-]
		> -PuTTY pscp allows raw passwords on the command line, or from a file. OpenSSH is unreasonable in refusing to do this. You can use `sshpass` to force it through the command line. However, arguments can be viewed by any process through `/proc`, `ps`, etc. It's pretty reasonable to not support exposure of the password like that, especially since you can force it through another tool if you really, really need to.

▲ extraduder_ire 3 hours ago | parent | prev | next [-]

>If you need something that SFTP cannot do, then use tar on both sides.

Wouldn't tar do the exact same thing to that file's permissions?

	▲	chasil 2 hours ago \| parent [-]
		Likely, but maintaining hard links is more of what I was thinking.

▲ Onavo 34 minutes ago | parent | prev | next [-]

What I want is to be able to drag and drop files in my remote server to and from my desktop as if it's an NFS/NAS. What's the best option for this that will fully saturate the link?

▲ jolmg an hour ago | parent | prev | next [-]

SCP protocol is fine and convenient as long as people understand that the remote file arguments are server-side shell code, and the consequences that implies.

You get the benefit of being able to e.g. get your last download off your desktop to your laptop like this:

  scp -TO desktop:'downloads/*(oc[1])' .

or this if you're on bash:

  scp -TO desktop:'$(ls -t downloads/* | head -1)' .

or pull a file from a very nested project dir for which you have setup dynamic directories (or shell variables if you're on bash):

  scp -TO desktop:'~foo/config/database.yml' config/

  scp -TO desktop:'$FOO_DIR/config/database.yml' config/

Just don't pull files from an SCP server that may be malicious. Use on trusted servers. If you do the following on your home dir:

  scp -TOr malicious:foo/ .

That may overwrite .ssh/authorized_keys, .zshrc, etc. because `foo/` is server-side shell code. The client can't say that `.zshrc` resulting from the evaluation of `foo/` doesn't make sense, because it might in the remote shell language.

> If you need something that SFTP cannot do, then use tar on both sides.

No reason to make things inconvenient between personal, trusted computers, just because there may be malicious servers out there where one has no reason to SCP.

Something else to note is that your suggestion of using `tar` like `ssh malicious 'tar c foo/' | tar x` faces basically the exact same problem. The server can be malicious and return .ssh/authorized_keys, .zshrc, etc. in the archive for `tar x` to overwrite locally basically exactly the same way. This goes with the point of this SE answer:

> 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. [...] 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. --- https://unix.stackexchange.com/questions/571293/is-scp-unsaf...

I think this whole problem with SCP just stems from not having properly documented this aspect in the manpage, so people expected it to just take filepaths.

▲ mistrial9 5 hours ago | parent | prev [-]

you sound so wise and produce excellent reference, but in the next breath you show NFS in use?

signed -confused

	▲	eikenberry 2 hours ago \| parent \| next [-]
		What would you use for remote mounting filesystems? I don't know of any that are simply superior (w/o caveats/tradeoffs).
	▲	gchamonlive 3 hours ago \| parent \| prev \| next [-]
		Why is it so self-evident that NFS is bad?
	▲	chasil 2 hours ago \| parent \| prev [-]
		I upvoted you, and yes, cleartext NFS is a concern. I had it wrapped in stunnel TLS, but I ripped that out recently as I am retiring and the new staff is simply not capable of maintaining that configuration. My users were yelling, and the patch to tinysshd to omit all permissions checks silenced the complaints. No, it's not pretty.