Disable Your SSH access accidentally with scp

3/3/2026 at 6:30:10 PM

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.

by chasil

3/3/2026 at 8:23:38 PM

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.

by elevation

3/3/2026 at 9:43:02 PM

easy to remember, if you don't use trailing slashes ever, it will just work every time

by fsckboy

3/4/2026 at 12:11:22 AM

rsync -avz -e ssh /local/ftw/ user@foo:/ftw/

by 0ckpuppet

3/4/2026 at 10:52:34 AM

Why the `-e ssh` there?

At least for me, rsync (on Debian) knows by default to use ssh. :)

by justinclift

3/4/2026 at 1:32:28 AM

"I have a few observations about this article."

I have a few observations about this comment.

Generally use whatever works to do the job. Do think about security, so if you end up streaming stuff across the internet using scp really consider your life choices.

In reality, you will probably be copying stuff on or across local nets or across a VPN because port 22 is (of course) unavailable from !RFC1918(etc).

Use the tool for the job and don't pontificate (unless you know best!)

by gerdesj

3/4/2026 at 2:38:46 AM

I for one appreciate this genre of comment. It's these days kinda one of the only things still redeemable on this particular website. I dont have to agree with it or end up using it, but its always good to see.

You get rid of some (wannabe-)greybeard nerd sniping someone's technical blog about an obscure linux util? What would even be left here? Just B2B SaaS AI blah blah forever?

You wan't them to couch this in "great job! Use whatever your comfortable with!" Are we really at that point?

by beepbooptheory

3/4/2026 at 2:48:55 AM

Allow me to introduce you to the Berkeley R-Utilities:

https://en.wikipedia.org/wiki/Berkeley_r-commands

They do the job, quite well.

I suggest that you use them for all your production needs, exclusively!

by chasil

3/3/2026 at 9:13:25 PM

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

What makes it a better drop in replacement?

by eikenberry

3/3/2026 at 9:37:08 PM

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.

by chasil

3/3/2026 at 11:24:38 PM

> -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 a command line argument. 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 using another tool if you really, really need to.

by jolmg

3/4/2026 at 1:06:25 AM

Both pscp and psftp have -pwfile.

It is not reasonable to insist on keys for batch use.

Not at all.

by chasil

3/4/2026 at 1:17:47 AM

It's completely crazy to use passwords when you needn't. Passwords are a human readable shared secret, they were already obsolete when SSHv1 was invented last century.

From the outset SecSH (SSHv2, the thing you actually use today and if you're younger, likely the only thing you ever have used) has public key authentication as a Mandatory To Implement feature. Implementations where that doesn't work aren't even SSH, they're garbage.

by tialaramex

3/4/2026 at 2:57:52 AM

I am forced by external vendors and internal security to use password authentication for SFTP.

I do not have a choice!

This grew out of FTP less than a decade ago. Everyone has always known password auth; it cannot die.

Are you on the same planet as the rest of us?

by chasil

3/4/2026 at 6:25:51 AM

If our vendor required a password auth, I want three sandboxes between it and anything production. Its an explosion waiting to happen.

by shakna

3/4/2026 at 3:06:42 PM

It can die once we stop letting it keep living with this kind of defeatist attitude

by akerl_

3/3/2026 at 10:18:14 PM

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.

by jolmg

3/3/2026 at 8:57:16 PM

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

by extraduder_ire

3/3/2026 at 9:51:18 PM

Likely, but maintaining hard links is more of what I was thinking.

by chasil

3/3/2026 at 6:37:55 PM

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

signed -confused

by mistrial9

3/3/2026 at 9:24:18 PM

What would you use for remote mounting filesystems? I don't know of any that are simply superior (w/o caveats/tradeoffs).

by eikenberry

3/3/2026 at 9:48:24 PM

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.

by chasil

3/3/2026 at 8:22:55 PM

Why is it so self-evident that NFS is bad?

by gchamonlive

3/4/2026 at 6:30:46 AM

Security is optional in NFS 4, and practically non-existent before. The standard Linux NFS client does not implement security.

> The Linux NFS client does not yet support certain optional features of the NFS version 4 protocol, such as security negotiation, server referrals, and named attributes.

> man 5 nfs

by shakna

3/4/2026 at 11:44:27 AM

That only means that if you need these kinds of security guarantees you need to look for another solution. A bad software would be one that advertises security but in practice the implementation would be full of holes, for instance with Microsoft Active Directory: https://arstechnica.com/security/2025/12/microsoft-will-fina...

by gchamonlive

3/3/2026 at 11:02:56 PM

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?

by Onavo

3/4/2026 at 2:36:17 PM

KDE/Dolphin has support for sftp built in. If you have sshd on your server you can just open/bookmark sftp://host/path/ as a folder and use it normally. I get around 0.9Gbit/s on a 1Gbit/s link.

by ndriscoll

3/4/2026 at 12:36:54 AM

I don't know about saturating the link, Buy sshfs can mount remote dirs and then you can drag and drop

by biglost

3/4/2026 at 2:17:03 AM

rclone has a web gui https://rclone.org/gui/

by Frotag

3/4/2026 at 1:38:40 AM

CIFS/Samba has had a lot of effort put into it, so setup Tailscale and just use that, if you're after drag and drop.

by fragmede

3/3/2026 at 5:53:46 PM

This is a useful tip!

but also... who has a dir with 777 permissions? Is that something people do nowadays?

by procaryote

3/3/2026 at 6:54:00 PM

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.

by easterncalculus

3/3/2026 at 9:01:58 PM

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

by SoftTalker

3/4/2026 at 1:10:01 AM

Heh I can remember doing that, in the distant past.

by Retr0id

3/3/2026 at 6:20:49 PM

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

by chasil

3/4/2026 at 11:16:19 AM

Well, maybe not everybody

  $ ls -ld /tmp
  drwxrwx--x. 2 shell shell 40 Jan 15  2022 /tmp

edit: sorry, I should have added this is termux :)

by paffdragon

3/3/2026 at 10:37:45 PM

[dead]

by huflungdung

2/28/2026 at 6:16:34 AM

I assume using `./*` rather than `.` in the `scp` command would have worked around the issue?

by zahlman

3/3/2026 at 9:07:00 PM

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.

by hrmtst93837

3/3/2026 at 9:30:19 PM

The problem was not scp'ing the .ssh/ directory. The problem was scp'ing a directory whose permissions were 777, and "mapping" it (cannot find a better term) to a remote directory, which happened to be the home directory. The remote home directory therefore had its permissions changed to 777, which was deemed "too open" by openssh which refuses to use any file in it.

by Biganon

3/3/2026 at 6:10:22 PM

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

by malicka

3/3/2026 at 7:56:52 PM

You did not transfer the files within a directory. You transferred the directory itself, via `.`. That is why scp changed the permissions of your home directory itself; if you instead had transferred via `*` I am sure you would not have had this problem.

by LoganDark

3/3/2026 at 11:07:33 PM

While it wouldn't prevent the issue they described, I prefer to pull, rather than push. My thinking is, if you pull, you're still connected. If you push, as soon as the push finishes, you're locked out.

by nubinetwork

3/3/2026 at 7:15:53 PM

I accidentally nuked my hosted server's network stack with a config error... my bigger mistake was generating a massive random password for the root account... the remote terminal management console didn't support pasting and the default config only gave you like 30s to login.... not fun at all.

Script all the things. double-check your scripts... always be backing up.

by tracker1

3/3/2026 at 8:28:07 PM

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

by jonathanlydall

3/3/2026 at 8:25:53 PM

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.

by gchamonlive

3/3/2026 at 5:27:41 PM

It's nice to see people sharing their mistakes too.

by crest

3/3/2026 at 6:37:13 PM

Getting locked out of a server must be a cannonical experienc in the sysadmin journey, like checking the logs to see you are being attacked as soon as your online, or trying to build your own linux from scratch without bloat.

by TZubiri

3/3/2026 at 5:35:55 PM

Related: In my Bash logout script I have a chmod that fixes authorized_keys. It won't help with scp because that's non-interactive, but it has helped the other 999 times I've forgotten to clean up the mess I made during an ssh session.

by sowbug

3/3/2026 at 6:21:13 PM

Ah, file permissions. My old friend. Good thing this happened on a 'local' server and not a remote VPS.

by impure

3/4/2026 at 3:13:49 AM

> OpenSSH will refuse to use a key to connect to any server if said file is readable by any user but yourself

I actually think that this assumption is the problem. This assumes a certain problem that, in this example here, was not the real problem. So the whole assumption that openssh refuses a connection in this case, was the wrong assumption to make. This is a design mistake, IMO; I understand the rationale but I disagree with it leading to being unable to connect. I have had similar problems with assumptions before, e. g. "if you are the super-user, we do not allow you to start X; you must be a regular user and use sudo". This is IMO also the wrong design approach - the very idea to restrict what the superuser can do. KDE used to have added an extra #define macro to refuse to be started when the superuser tries to use KDE. This is also the wrong design abstraction - people writing the code not understanding the basic permission system in *nix. (It only were a few #defines in the C++ code, so people could just remove it then recompile the thing and it suddenly worked like pure magic. I had that in some KDE editor, I forgot which one; I think it was kate. Been many years by now.)

by shevy-java

3/3/2026 at 11:17:34 PM

Classic OpenSSH safety check: if /home/$user (or ~/.ssh) is too open, or ownership/modes are off, sshd will refuse pubkey auth. Annoying, but correct.

If you still have some access (console, password login, another sudo user), this usually fixes it:

    username=bob
    sudo chown "$username:$username" /home/$username
    sudo chmod 700 /home/$username

    sudo install -d -m 700 -o "$username" -g "$username" /home/$username/.ssh
    echo "ssh-ed25519 AAAA....insertyourpubkeyhere" | sudo tee /home/$username/.ssh/authorized_keys >/dev/null
    sudo chown "$username:$username" /home/$username/.ssh/authorized_keys
    sudo chmod 600 /home/$username/.ssh/authorized_keys

(optional, if the user needs sudo)

    echo "$username ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/$username >/dev/null
    sudo chmod 440 /etc/sudoers.d/$username

Not to shill too hard, but this exact "keys/perms/sudo drift" failure mode is why Userify exists (est. 2011): local accounts on every box + a tiny outbound-only agent that polls and overwrites desired state (keys, perms, sudo role). If scp/rsync/deploy steps clobber stuff, the next poll re-converges it (cloud default ~90s; self-host default ~10s; configurable). Removing a user also kills their sessions. No inbound ports to nodes, no PAM/NSS hooks, auditable.

Shim (old but readable): https://github.com/userify/shim/blob/master/shim.py#L308 (obligatory): https://userify.com

by jamiesonbecker

3/3/2026 at 7:34:00 PM

Done stupid stuff like this enough times that I just use tar, and also make a sandbox directory to receive it, to double-check whats going to happen, before un—tar’ing it again into the destination intended and/or do a manual move.

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.

by MomsAVoxell

3/4/2026 at 12:04:31 AM

rsync over ssh

by 0ckpuppet

3/3/2026 at 6:55:15 PM

[dead]

by rhier1

3/3/2026 at 4:49:52 PM

tl;dr: I you scp -r to your homedir, expect scp to copy not just files and directories but their permissions as well (which I think isn't all that surprising).

by roelschroeven

3/3/2026 at 5:28:44 PM

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.

by ranger_danger

3/3/2026 at 6:42:19 PM

I wouldn't even expect it on newly created stuff without the -p flag. Normal cp doesn't do it.

by Calzifer

3/3/2026 at 4:19:03 PM

When I load the site in my (slightly older) Firefox I just get some random junk and gibberish (markov chain generated nonsense?)

<bleep> that nonsense!

by binaryturtle

3/3/2026 at 6:25:33 PM

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

Perhaps you got bot flagged or something

by theblazehen

3/3/2026 at 9:01:37 PM

That URL gives me a 418 I'm a teapot error with no body. I'm guessing they don't like my VPN.

by extraduder_ire