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

hrmtst93837 2 hours ago | parent | next [-]

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.

	▲	Biganon 2 hours ago \| parent [-]
		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.

▲

malicka 5 hours ago | parent | prev [-]

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