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.

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

What makes it a better drop in replacement?

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

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?

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.

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

signed -confused

My guess would be mounting an NTFS partition - with ntfs-3g it will load everything as 777 just by default, since it can’t translate the permissions.

I've seen users who have every file set to 777. They do it to "avoid permissions issues"

Well, everybody has 1777 as /tmp (with the sticky bit).

  $ ll -d /tmp
  drwxrwxrwt. 20 root root 4096 Mar  3 12:19 /tmp
  $ mkdir mytmp
  $ chmod 1777 mytmp
  $ ll -d mytmp
  drwxrwxrwt. 1 luser lgroup 0 Mar  3 12:19 mytmp

[dead]

Using './*' would have avoided this in most shells because ordinary globbing excludes dotfiles, so .ssh and authorized_keys are not matched. In my experience scp is brittle for bulk syncs, so I run rsync -a --exclude='.ssh' --dry-run ./ user@host:~/target to verify before I commit the changes. I keep an out of band recovery path, like a temporary deploy key, a nonprivileged rescue user, or console access, as the only reliable way to avoid being locked out at 3AM.

Yes, since it would’ve copied the globbed files, rather than the current directory itself.

> the remote terminal management console didn't support pasting and the default config only gave you like 30s to login

I would have used AutoHotkey or something similar in such a scenario.

Also a gentle reminder that backups without periodic drills are just binary blobs. I had an instance where for some reason my Borg backups where corrupted. Only caught them with periodic drills.

It's not supposed to do that unless it's newly creating the destination, or you supplied the -p flag to preserve permissions... that's what the entire issue is about; it's a bug that was fixed in 10.3.

I suspect you're hitting the page where they're running https://iocaine.madhouse-project.org/

Perhaps you got bot flagged or something