共計 1704 個字符，預計需要花費 5 分鐘才能閱讀完成。

丸趣 TV 小編給大家分享一下容易被忽視的 Linux 安全權限配置問題有哪些，希望大家閱讀完這篇文章之后都有所收獲，下面讓我們一起去探討吧！

1、太寬的權限

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

舉例：

問題現(xiàn)象：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。

在檢查了多遍后確實沒有問題,*** 在服務器端對比兩個帳號的不同時, 發(fā)現(xiàn)了可疑的地方。

$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), 表現(xiàn)為系統(tǒng)認為不存在私鑰。

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

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

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

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

2、悄悄啟動的 selinux

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

舉例：

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

apache 上的配置：

Alias/hello.html/web/hello.html Order deny,allow Allow from all

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

#ls-Z/web/ -rw-r--r--.root root unconfined_u:object_r:admin_home_t:s0hello.html

原來 /web 目錄不能被 apache 內(nèi)建的用戶訪問。

原因解釋：

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

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

其實不止是文件權限，包括服務可以使用的端口、消息接口等，selinux 都有默認限制。

看完了這篇文章，相信你對“容易被忽視的 Linux 安全權限配置問題有哪些”有了一定的了解，如果想了解更多相關知識，歡迎關注丸趣 TV 行業(yè)資訊頻道，感謝各位的閱讀！