One thing went wrong: the use of
sudo with that command. The
-R switch tells
chmod to recursively set the permissions to that directory, which is, in every case, a non-recommended action (should we call it: heresy) if you don't know what are you doing (once this happened to me, I didn't issue the command but a faulty GUI made it, and my system went wire).
It was only file permissions. Then why does the whole system seems completely blown up?
GNU/Linux is very sensitive to file permissions, as it was built with stability and security in mind. Same applies to most programs run in GNU/Linux (i.e.
apache2 drops root privileges and uses
www-data, or similar user, and your
700 permission wouldn't allow it to read/write it own files).
Why is it that no login passwords are working now?
As you already mention, login passwords are stored in a file in
/etc/passwd and only root (I assume you didn't change that) can read it, but the login prompt (or GUI login) uses a non-privilege account, hence it cannot read the file.
But how did changing permissions jeopardize everything?
Same as said above, Linux is very sensitive to file permissions. Some programs even check the permissions of their configuration files and if they are not expected they won't run at all.
How can I revert my etc directory to its earlier state?
If you use a RPM-based distro, this can be done using the
rpm --setperms command, it would be painfully reverting one by one the packages, on Debian-like system
apt-get --reinstall install is your friend. Other solutions may be available, but would need a working system for it.