4 ms·
Disable Your SSH access accidentally with scp
- zahlman 8mo agoI assume using `./*` rather than `.` in the `scp` command would have worked around the issue?
- malicka 8mo agoYes, since it would’ve copied the globbed files, rather than the current directory itself.
- hrmtst93837 8mo ago[flagged]
- Biganon 8mo agoThe 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.
- binaryturtle 8mo agoWhen I load the site in my (slightly older) Firefox I just get some random junk and gibberish (markov chain generated nonsense?) <bleep> that nonsense!
- theblazehen 8mo agoI suspect you're hitting the page where they're running https://iocaine.madhouse-project.org/ https://iocaine.madhouse-project.org/ Perhaps you got bot flagged or something
- extraduder_ire 8mo agoThat URL gives me a 418 I'm a teapot error with no body. I'm guessing they don't like my VPN.
- roelschroeven 8mo agotl;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).
- ranger_danger 8mo agoIt'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.
- Calzifer 8mo agoI wouldn't even expect it on newly created stuff without the -p flag. Normal cp doesn't do it.
- crest 8mo agoIt's nice to see people sharing their mistakes too.
- sowbug 8mo agoRelated: 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.
- procaryote 8mo agoThis is a useful tip! but also... who has a dir with 777 permissions? Is that something people do nowadays?
- chasil 8mo agoWell, 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
- paffdragon 8mo agoWell, 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 :)
- easterncalculus 8mo agoMy 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.
- SoftTalker 8mo agoI've seen users who have every file set to 777. They do it to "avoid permissions issues"
- Retr0id 8mo agoHeh I can remember doing that, in the distant past.
- deleted 8mo ago[deleted]
- huflungdung 8mo ago[dead]
- impure 8mo agoAh, file permissions. My old friend. Good thing this happened on a 'local' server and not a remote VPS.
- chasil 8mo agoI 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/ 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.
- mistrial9 8mo agoyou sound so wise and produce excellent reference, but in the next breath you show NFS in use? signed -confused
- gchamonlive 8mo agoWhy is it so self-evident that NFS is bad?
- shakna 8mo agoSecurity 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
- gchamonlive 8mo ago
- TZubiri 8mo agoGetting 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.
- rhier1 8mo ago[dead]
- tracker1 8mo agoI 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.
- gchamonlive 8mo agoAlso 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.
- jonathanlydall 8mo ago> 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.
- MomsAVoxell 8mo agoDone 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.
- 0ckpuppet 8mo agorsync over ssh
- LoganDark 8mo agoYou 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.
- nubinetwork 8mo agoWhile 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.
- deleted 8mo ago[deleted]
- jamiesonbecker 8mo agoClassic 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 https://github.com/userify/shim/blob/master/shim.py#L308 (obligatory): https://userify.com https://userify.com
- shevy-java 8mo ago> 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.)