為了方便操作，一般我都是使用root登錄管理vps。在這至高無上的權限面前，一個不慎就會發生各種各樣的悲劇。前兩天，原本打算執行 chmod -R 777 ./* ，結果手滑打少了一個.。雖然及時按 ctrl + c 終止命令，但悲劇已經發生。
在 rm -rf / 面前，上面的誤操作其實還是可以挽救的。下面就說一下如何最大程度恢復原來正確的權限。
最重要的一點：
執行命令後千萬不要關閉當前窗口！
因為這個時候新建一個Terminal，已經不能通過ssh連上這台vps了。因此首先需要修復SSH的相關權限。
在一台正常的Linux主機上查看SSH相關文件的正確權限，執行下面的操作：
cd /etc
chmod 644 passwd group shadow
chmod 400 gshadow
cd ssh
chmod 600 moduli ssh_host_dsa_key ssh_host_key ssh_host_rsa_key
chmod 644 ssh_config ssh_host_dsa_key.pub ssh_host_key.pub ssh_host_rsa_key.pub
chmod 640 sshd_config
嘗試登錄SSH，發現已經正常，但不能切換到root賬號。
$ su - root
su: cannot set groups: Operation not permitted
查閱相關資料後發現，su必須有s權限才能預讀取root的相關配置，於是執行下面的命令，讓su的owner權限加上s：
chmod u+s `which su`
完成後就可以以root身份進入系統了。
完成上面的步驟，只是掃清了以root進入系統的障礙，以防當前窗口關閉後不能重新登錄。下面進行其余文件的權限修復。
找一台盡量干淨的Linux機器，把上面的權限導出：
getfacl -R / > ./linux.chmod.bak
然後通過ftp或者scp命令傳到目標機器上：
scp linux.chmod.bak [email protected]:/root/
在目標機器上導入權限文件：
setfacl --restore=/root/linux.chmod.bak
導入完成後需要重啟機器才能生效。這時機器基本就恢復正常了，起碼在系統功能上沒有問題。
為了保險起見，我們在導入權限文件之前，可以把前面修復SSH的方法寫成腳本然後在 rc.local 中延時執行。這樣就算出問題需要強制重啟，我們還能通過SSH登錄回來。
把內容寫到 /root/tmp.sh 裡面：
cat /root/tmp.sh
cd /etc
chmod 644 passwd group shadow
chmod 400 gshadow
cd ssh
chmod 600 moduli ssh_host_dsa_key ssh_host_key ssh_host_rsa_key
chmod 644 ssh_config ssh_host_dsa_key.pub ssh_host_key.pub ssh_host_rsa_key.pub
chmod 640 sshd_config
chmod u+s `which su`
然後把腳本放到開機啟動：
echo '/root/sh/sshtmp.sh &' >> /etc/rc.local
接下來就可以放心的導入權限文件然後reboot了。
重啟後如果一切正常，記得到 /etc/rc.local 中去掉腳本。
由於我們導入的是干淨的Linux權限列表，所以我們只是把系統原有的文件進行權限修復。至於安裝的程序和放在vps上的文件，暫時還沒想好怎麼修復。難道就只有重裝了麼！？
在血的教訓面前，以後不能輕易就用root了... (╯‵□′)╯︵┻━┻