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).
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.
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.
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.
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!)
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.
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.
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.
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.
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.
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.
> 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.)
22 comments
[ 2.7 ms ] story [ 41.7 ms ] thread<bleep> that nonsense!
but also... who has a dir with 777 permissions? Is that something people do nowadays?
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:
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.
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!)
Script all the things. double-check your scripts... always be backing up.
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.
If you still have some access (console, password login, another sudo user), this usually fixes it:
(optional, if the user needs sudo) 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
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.)