-4

I made a total mistake here. Anyway I ran chmod -R 777 /* and immediately regretted my decision.

I had to boot into single user mode to and ran chmod -R 755 /etc/* in order to login to the server.

The only problem is ssh now and obvious security issues.

How do I get SSH working again?

Greenonline
  • 215
  • 2
  • 5
  • 13
Lylo
  • 101
  • 1
  • 3
  • Your only description of the problem is that SSH is "broken". It's not even clear if it's the server or the client that's broken or in what way it, whatever it is, is broken. – David Schwartz Aug 19 '15 at 08:13
  • It's server side all the clients cannot connect. The error message i get is `Connection closed by remote host` – Lylo Aug 19 '15 at 08:16
  • 6
    I'm voting to close this question because the Related section on the right of the page, this [cannonical Q&A](http://serverfault.com/questions/364677/why-is-chmod-r-777-destructive) and [search](http://serverfault.com/search?q=chmod+-R+%2F+777) all contain relevant information. As an aside you have bigger problems than ssh but you can find out what by reading the links I provide. Be prepare to reach for your backups. – user9517 Aug 19 '15 at 08:17
  • 4
    ssh sees 755 as a big security hole (it is) so it refuses to run. ssh is not your only problem. a re-install is needed now or reach for a *full* backup. – Skaperen Aug 19 '15 at 10:03
  • 3
    I agree with Skaperen, a complete re-install of your OS is required due to the fact you have overwritten all of the permissions pretty much disabling programs that require certain permissions. [This link may help you](http://serverfault.com/questions/364677/why-is-chmod-r-777-destructive?lq=1) – KeirDavis Aug 19 '15 at 10:05
  • getting ssh to work for now might allow one last backup before the reinstall. i'd try `chmod -R 700 /home/*/.ssh` and see if that lets an ssh client in. but a re-install or careful *full* backup restore is still needed. – Skaperen Aug 19 '15 at 10:13
  • If you did something like that, I think you don't need to reinstall your OS, http://serverfault.com/questions/378074/recovering-from-bad-chown-command/378076#378076 I did the same in a virtual server and everything works. – c4f4t0r Aug 19 '15 at 12:42

1 Answers1

-1

Couple of thoughts, assuming restore from backup is not an option:

  1. Check /home directory permissions. Everything underneath that should be 700 to make ssh happy (technically only required underneath your specific directory, but safer to just make that done across the board).

  2. Also make sure /root is 700.

  3. /tmp is special, you might want to do this: https://unix.stackexchange.com/questions/71622/what-are-common-rights-for-tmp-i-unintentionnally-set-it-all-public-recursive (not related to ssh particularly but just something that is not like other things you'll encounter).

  4. Consider installing a clean CentOS image somewhere and do the venerable stare and compare to get things back to normal. Or do it the easier way: https://superuser.com/questions/200681/how-to-display-only-permissions-and-file-names-using-ls-command - run on each image (yours and the new/clean one) and diff the outputs for any major anomalies.

Good luck!

-Mary

Community
  • 1
Mary
  • 565
  • 5
  • 10
  • Folks, I'm aware that the "right" answer is to restore from backup because of ALL THE SECURITEEZ R GONEZZZ! But that's not the question being asked here. They are asking what, specifically, he or she did that borked ssh. Most likely, they need to get back into the server in order to do anything...like, say, run their backup client to restore their server to a previous state. – Mary Aug 26 '15 at 15:41