☰

如何防止使用者弄亂自己的 .ssh 資料夾？

tag-icon • tag-icon permissions ssh-keys
如何防止使用者弄亂自己的 .ssh 資料夾？

我正在管理一個 RedHat 伺服器，用戶使用基於私鑰/公鑰的身份驗證透過 SSH 登入。

我想防止他們意外更改/刪除/chmoding 其內容〜/.ssh資料夾。他們中的一些人已經遞歸地對自己的整個主文件夾進行了 777-chmod ，因為“這樣更容易與同事共享文件”，結果搬起了石頭砸自己的腳。

知道我該如何實現這一目標嗎？最好有標準的Linux權限系統。

答案1

簡短的回答是你不能。

SSH 對權限非常挑剔，不會使用它不喜歡外觀的檔案。進一步，ssh_config解析用戶前系統範圍的配置。

話雖如此，它可能$HOME/.ssh可以將檔案放在其他位置並將目錄作為每個使用者的唯讀檔案系統安裝。 （這是可能的 - 但我不知道 ssh 和相關工具將如何處理這個問題）。

他們中的一些人已經遞歸地 777-chmoded 了他們自己的整個主資料夾

那麼你就會面臨更大的安全和訓練問題。

答案2

很難保護使用者免受自身無知和無能的影響。

但取決於您需要允許用戶管理自己的程度以及您為他們管理的程度：您可以將 sshd 配置為在其主目錄之外的替代位置以及~/.ssh/authorized_keys.

授權密鑰命令

一個相對複雜的解決方案是/etc/ssh/sshd_config AuthorizedKeysCommand 該指令不依賴authorized_keys文件，而是指定一個用於查找使用者公鑰的程序，例如：

  • ALDAP 目錄

  • A資料庫

  • 一個（簡單的）網路服務

  • 或者當您的使用者名稱與 Github 使用者名稱相同時，您可以允許使用者使用他們上傳到此處的金鑰對進行身份驗證：

    AuthorizedKeysCommand /usr/bin/curl https://github.com/%u.keys

如中所提到的這個答案;您需要為 AuthorizedKeysCommand 建立適當的 SELinux 策略，因為它會被預設策略阻止。

我喜歡這種方法，因為它可以解決圍繞授權金鑰管理的許多問題：它增加了集中管理，消除了當您想在ssh 中禁用密碼身份驗證時向伺服器獲取授權金鑰的先有雞還是先有蛋的問題。
它利用了公鑰並不是特別敏感的事實（與相關的私鑰不同），因此集中管理不會增加風險（恕我直言），甚至可能提高您的控制和報告能力。

授權密鑰文件

稍微不太複雜的是將密鑰儲存在其主目錄之外的目錄中。例如使用/etc/ssh/<username>（替換<username>為實際使用者名稱）。該目錄應具有 755 個權限並由使用者擁有。將authorized_keys文件移入其中。 authorized_keys 檔案仍應具有 644 個權限並由使用者擁有。

在/etc/ssh/sshd_config調整AuthorizedKeysFile環境

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

並重新啟動 ssh 守護程式

答案3

我能想到的最好的解決方案是製作.ssh並authorized_keysroot 擁有。

根擁有的 .ssh/authorized_keys

SSH 對權限很挑剔，但並非沒有道理。首先，它要求使用者本身俱有讀取權限authorized_keys（這需要對所有父目錄具有讀取權限）。其次，如果除使用者本身或 root 之外的任何使用者對/home、或 具有寫入存取權限.ssh，則它會拒絕存取authorized_keys。這不允許o+w, 和g+w對於其中有其他使用者的群組。

此設定適用於我，用戶可以登入：

drwxr-xr-x 19 root root 4096 Sep 22 11:24 /
drwxr-xr-x  3 root root 4096 Sep 22 11:19 /home/
drwx------ 14 test test 4096 Sep 22 11:44 /home/test/
drwxr-x---  2 root test 4096 Sep 22 11:42 /home/test/.ssh/
-rw-r--r--  1 root test   98 Sep 22 11:36 /home/test/.ssh/authorized_keys

由於.ssh和authorized_keys是 root 擁有的，因此使用者無法更改它們的權限或刪除它們。他們也無法編輯自己的authorized_keys文件。

如果您想允許使用者編輯其authorized_keys，您可以新增群組寫入權限。這要求該test組除自身之外沒有其他成員test：

-rw-rw-r--  1 root test   99 Sep 22 12:04 /home/test/.ssh/authorized_keys

無論採用哪種方法，使用者都無法再在 下建立自己的文件.ssh，因此您可能還需要為他們提供一些額外的文件。我想到的一些是：known_hosts、config和/id_rsa{.pub,}或其他關鍵類型。

替代方案：chattr

一些 Linux 檔案系統支持文件屬性，特別是一個不可變標誌。設定了不可變標誌的檔案/目錄無法刪除、修改或變更其權限。只有 root 可以設定/清除該標誌。

即使使用預設的所有權/權限，此命令也能解決問題：

# chattr +i ~test/.ssh/{authorized_keys,}

現在.ssh不能authorized_keys以任何方式修改，甚至不能透過 root 修改。如果 root 需要更新這些文件，您chattr -i首先需要它們。用於lsattr檢查屬性。

這種方法比較簡單，但靈活性較差。它還需要檔案系統支援；我相信至少 ext2/3/4、XFS 和 btrfs 都支援它。

Posix ACL？

還有Posix ACL（存取控制清單），允許更細粒度的控制。我對他們不太熟悉，我不確定他們是否有幫助。

嚴格模式

筆記：非常不鼓勵，但為了完整性而提供。

OpenSSH 伺服器有一個設定指令稱為StrictModes，它決定了 SSH 對權限的挑剔程度：

指定 sshd 在接受登入之前是否應檢查檔案模式以及使用者檔案和主目錄的所有權。這通常是可取的，因為新手有時會意外地將其目錄或檔案設定為全域可寫入。預設為yes.

如果停用該選項，您可以更自由地設定所有權和權限。然而，SSH 默認情況下是嚴格的，這是有充分理由的。用戶 777-chmodding 其 SSH 檔案存在安全風險。

答案4

每晚執行一個 cron 作業來修復權限。

刪除檔案有點困難。您也可以從 cron 備份中還原遺失的檔案。但是，似乎您可能會遇到奇怪的邊緣情況…可能需要比腳本所能提供的更多的智慧。我會從小處開始，謹慎地向恢復功能添加功能。

相關內容