<bleep> that nonsense!
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
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.
Too many burned fingers to not do this little dance almost every other time.
Actually, I lied, I just use rsync like an insane person.
but also... who has a dir with 777 permissions? Is that something people do nowadays?
Script all the things. double-check your scripts... always be backing up.
signed -confused
I would have used AutoHotkey or something similar in such a scenario.
$ 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 mytmpI 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.
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])' .
scp -TO desktop:'$(ls -t downloads/* | head -1)' .
scp -TO desktop:'~foo/config/database.yml' config/
scp -TO desktop:'$FOO_DIR/config/database.yml' config/
scp -TOr malicious:foo/ .
> 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.
What makes it a better drop in replacement?
Wouldn't tar do the exact same thing to that file's permissions?
-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.
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.
Here's an interesting bug I ran into recently: After transferring some files to my server via scp, I couldn't log in via SSH anymore - my key was rejected by sshd.
user@host: Permission denied (publickey).
The thing is, as luck would have it, I had previously set up a WebDAV server on the same machine - I've been using it for a number of things, for example as a makeshift synchronization solution for my KeePass database - and since it was just sshd acting up and everything else still worked fine, I could still access the entire file system via WebDAV.
My first thought was that some application had overwritten my authorized_keys file. Forgejo used to do this in the past every time it was updated, but I believe they fixed this. I certainly haven't had that issue for quite a while now. And sure enough, my key was still in there.
I tried creating a new key, putting it into authorized_keys and logging in using that, but to no avail. I tried logging in from a different machine - still nothing. I temporarily modified the sshd configuration to allow logging in via a password again, which worked flawlessly, but of course this was a workaround and not a solution. A reboot didn't help either (but I thought I might as well).
Luckily, when I say "server", what I really mean is a single-board computer sitting in my own four walls. So eventually, I gave in, took out the SD card and put it into my machine. I thought I'd run fsck for good measure, but it didn't report any issues. (And I hoped it wouldn't, the card is barely a few months old after all!)
But then I noticed something odd while cd'ing and ls'ing my way around the file system: The file system permissions of my home directory were set to rwxrwxrwx (777). I was certain that I didn't make this change - not least because ls helpfully highlighted the respective entry with a green background, something I no doubt would've noticed in the past.
If you're using SSH yourself, you may have run into a curious issue in the past: sshd telling you that the permissions of your private key file are too open. OpenSSH will refuse to use a key to connect to any server if said file is readable by any user but yourself:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "id_ed25519": bad permissions
user@host: Permission denied (publickey).
Well, it seems like there's a similar check on the server as well. As soon as I reverted the permissions of my home directory to rwx------ (700), everything went back to normal. And sure enough, between thousands of authentication failures from bots and scrapers, there was a revealing line in the OpenSSH logs:
sshd-session: Authentication refused: bad ownership or modes for directory /home/user
Alright, problem solved. But why did the permissions of my home directory change all of a sudden?
Well, let's replicate what happened right before all of this went down: the SCP file transfer. The exact command I used at the time (save for the redacted hostname) was:
$ scp -r . host:
This transfers everything in the current local directory to my home directory on the server. Another part that's going to be of importance is that, for reasons, the directory I wanted to transfer had the permissions of rwxrwxrwx (777). Can you tell where this is going already?
First, let's create the directory, as well as some sample files to transfer:
$ mkdir local_directory
$ chmod 777 local_directory
$ cd local_directory
$ touch test_file_1 test_file_2 test_file_3
Next is the destination directory. We could also use the home directory again, but I'm not going to take any more risks:
$ ssh host mkdir remote_directory
$ ssh host chmod 700 remote_directory
The moment of truth:
$ ssh host ls -ld remote_directory | cut -d " " -f 1
drwx------
$ scp -r . host:remote_directory
test_file_1 100% 0 0.0KB/s 00:00
test_file_2 100% 0 0.0KB/s 00:00
test_file_3 100% 0 0.0KB/s 00:00
$ ssh host ls -ld remote_directory | cut -d " " -f 1
drwxrwxrwx
It seems that OpenSSH's scp modifies the permissions of the transferred files and directories to match their local counterparts. This makes sense, except it also does so if the target directory already exists!
So, in short: When I transferred the files within a directory with the permissions of rwxrwxrwx (777) to my server, scp modified the permissions of the target (and, in this case, home) directory to match. Then, when I tried to log in via SSH, sshd determined that these permissions were too broad, too open to other users, to continue in a safe manner, and rejected my key.
I reported my findings to OpenSSH's bug tracker. Within hours, a fix was pushed, and the author told me that it's going to be included in the next release, 10.3. Kudos to them for such a quick response!
Links of interest: