本文談兩個很容易被忽視，又偶爾會突然蹦出來，給我們配置服務器造成困擾的權限管理問題。

1、太寬的權限

有些服務對權限的要求會是一個區間，小了不行，大了也不行。如果這個文件被賦予的權限不夠，那么肯定不能使用；但是，如果這個文件被賦予的權限太多了，同樣不能正常使用。

舉例：

問題現象：test帳號使用key無法登錄某ssh服務器,而同機器下的test2帳號卻可以登錄。

查看文件權限：

test@client:~$ls-l~/.ssh/

-rw-------1testtest 16752010-03-2515:15id_rsa

查看了客戶端及服務器端的.ssh目錄下的公鑰與私鑰權限,可以看出,并沒有問題。

私鑰必須是600權限,而公鑰至少是644或者更嚴格的權限,這都符合,但依然無法登錄。

test@server:~$ls-la~|grep-w.ssh

drwxr-xr-x2testtest4.0K12-2316:59.ssh

查看了服務器端的.ssh目錄權限,是755,也是沒問題的,ssh服務器要求在使用key登錄時.ssh目錄的權限必須是其他用戶不可寫。

一開始實在想不明為啥test2帳號使用key可以登錄,test帳號使用key無法登錄,ssh_config和sshd_config。

在檢查了多遍后確實沒有問題,最后在服務器端對比兩個帳號的不同時,發現了可疑的地方。

$ls-l/home/

drwxrwxrwx 3testtest4096 2009-12-31 17:31test

drwxr-xr-x 6 test2 test2 4096 2010-03-23 15:59test2

兩個帳號的home目錄權限不同,test帳號是777,test2帳號是755,會不會是這里不同導致的?在服務器端把test目錄修改成755后,解決問題。

原因解釋：

ssh服務器的key方式登錄對權限要求嚴格。對于客戶端:私鑰必須為600權限或者更嚴格權限(400),一旦其他用戶可讀,私鑰就不起作用(如640),表現為系統認為不存在私鑰。

對于服務器端:要求必須公鑰其他用戶不可寫,一旦其他用戶可寫(如660),就無法用key登錄,表現為:Permission denied(publickey)。

同時要求.ssh目錄其他用戶不可寫,一旦其他用戶可寫(如770),就無法使用key登錄,表現為:Permission denied(publickey)。

不僅.ssh目錄，更上層的目錄的權限同樣會有影響。

home中用戶目錄的可寫,表示其他用戶對.ssh子目錄也有改寫的權限(刪除或重命令),也就導致ssh判斷.ssh為其他用戶可寫,拒絕使用key登錄。

2、悄悄啟動的selinux

如果你配置某項服務，但是不論怎么定義配置文件，有些端口始終不能打開，或者文件無法訪問到，那么這時你要小心是selinux在搗鬼。

舉例：

問題現象：配置apache上的目錄可以訪問，卻始終提示你沒有權限。

apache上的配置：

Alias/hello.html/web/hello.html

<Directory/web>

Order deny,allow

Allow from all

</Directory>

怎么查都沒有問題，文件權限也對，這時可以考慮查一下selinux的權限。

#ls-Z/web/

-rw-r--r--.root root unconfined_u:object_r:admin_home_t:s0hello.html

原來/web目錄不能被apache內建的用戶訪問。

原因解釋：

默認情況下，selinux限制了apache可以訪問的目錄，默認僅能在/var/www/下面讀寫文件。這也難怪，我們只配置apache和文件權限沒有任何作用了。

要想實現對/web/目錄下的文件讀取，必須修改selinux的配置。

其實不止是文件權限，包括服務可以使用的端口、消息接口等，selinux都有默認限制。如果你配置服務遇到莫名其妙的問題，看一下selinux吧