0

For reasons I am too embarrassed to share, I ran this command as root on a remote server:

chmod a+r -R /etc

Once I logged out of the SSH session, I was not able to SSH back in:

$ ssh myusername@<HOST>
Connection closed by <HOST> Port 22

Now, I realize the chmod above was a huge mistake. However, it seems like it should have just added read permissions on everything, not removed any permissions, right? My question: how exactly did this break SSH?

(Also, in case anyone finds this from having made a similar error, I restored /etc default permissions using this answer, but I was very lucky to have an SSH connection still open elsewhere to do so.)

cheryllium
  • 111
  • 3
  • sshd expects certain permissions on its config file as well as on the user's ~/.ssh folder and filles for security reasons. It will refuse connections if those requirements are not met. You should find a very explicit message about that n your logs. – Zeitounator Apr 23 '21 at 05:56

2 Answers2

1

You changed permissions recursively for everything under /etc. The majority of your software keeps essential files under this directory.

In many cases, changing the permissions of files needed by your software can cause the software not to work as intended.

You probably broke a lot more than ssh. You will probably need to reinstall the operating system since there is not a simple way to undo the damage this command would cause: permissions are not the same for every file under this directory.

Nmath
  • 12,333
  • Yes, I know these things. Your answer doesn't answer my question. I'm asking why adding a read permission is able to cause such problems. I would really appreciate a deeper understanding and that's why I'm asking this question. I am not looking for advice or to "fix" anything. – cheryllium Apr 23 '21 at 04:25
  • You added read permissions for all users on all files. Not all of the files under /etc are supposed to have read access for all users. – Nmath Apr 23 '21 at 04:28
  • I appreciate that you're trying to help, but that still does not answer my question at all. – cheryllium Apr 23 '21 at 04:32
  • I'm sorry it's not a more detailed explanation, but it does provide the cause of the problem and offer the path to solutions; you either need to restore all of the permissions to their correct values, or reinstall the OS, which is usually faster for problems caused by destructive recursive commands – Nmath Apr 23 '21 at 04:36
  • 1
    I already clarified I'm not looking for solutions. That said, if you want to point out specific problems with the solution I ended up using, I did link it so you could leave a comment there. Fwiw, your answer doesn't explain the cause of the problem, it simply speculates. I know for certain the problem was caused by the permission change, my question here is specifically to do with SSH and how adding read permissions would cause the connection to fail. I'll edit my question to make this clearer, thanks. – cheryllium Apr 23 '21 at 04:46
  • If you know what caused the problem and you know the solution, then what is the purpose of this post? My answer is not speculation, you just said you know this command was the cause. There probably isn't a single file, since you changed permissions of everything. You have all of the actionable information. Is this a rant in disguise? – Nmath Apr 23 '21 at 04:50
  • I'm genuinely baffled why you think this is a rant, when a much more obvious explanation is simply that I'm curious. Usually, when a program fails due to improper permissions, it's because they are too restrictive. I've very rarely encountered programs failing to execute correctly because permissions on something were too permissive. So I am just curious about the thing that I did, that's all. – cheryllium Apr 23 '21 at 05:00
  • Welp, I can't figure out a good way to word my edit, so I gave up on that haha. I feel like if someone is inclined to read it like a passive-aggressive rant, it can always be read that way no matter how I say it. I mean it though, I genuinely am just seeking a more in-depth understanding, for its own sake. Maybe I misunderstood the purpose of this forum, sorry. – cheryllium Apr 23 '21 at 05:14
  • No it's ok, I hope someone can chime in with a more detailed explanation. If I am to speculate, my guess that it is probably not just one single file that's problematic and it would probably have affected more than just ssh. – Nmath Apr 23 '21 at 05:23
  • Thank you. No hard feelings. If you were also curious, someone did chime in with another answer. I learned sshd will explicitly check permissions on the private keys and bail if they are too permissive. It's good to know that sshd will explicitly check for that, though in hindsight it seems obvious that it would, lol! – cheryllium Apr 23 '21 at 15:20
1

SSH is picky about key permissions. Private keys shouldn't be readable by anybody except the user, and that includes the host keys for sshd, which bailed when it couldn't find a sufficiently secure host key. An example log from my system, after doing sudo chmod o+r /etc/ssh/*key:

Apr 23 15:59:31 muru sshd[21516]: error: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Apr 23 15:59:31 muru sshd[21516]: error: @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
Apr 23 15:59:31 muru sshd[21516]: error: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Apr 23 15:59:31 muru sshd[21516]: error: Permissions 0604 for '/etc/ssh/ssh_host_ed25519_key' are too open.
Apr 23 15:59:31 muru sshd[21516]: error: It is required that your private key files are NOT accessible by others.
Apr 23 15:59:31 muru sshd[21516]: error: This private key will be ignored.
Apr 23 15:59:31 muru sshd[21516]: sshd: no hostkeys available -- exiting.
muru
  • 197,895
  • 55
  • 485
  • 740
  • Thank you! Makes sense and I'm glad to know sshd will detect and bail on this security flaw. For future visitors: I confirmed the solution I used (in my link) did restore those permissions (chmod 400 /etc/ssh/ssh*key) – cheryllium Apr 23 '21 at 15:14