☰

ユーザーが自分の .ssh フォルダーをいじるのを防ぐにはどうすればよいですか?

tag-icon • tag-icon permissions ssh-keys
ユーザーが自分の .ssh フォルダーをいじるのを防ぐにはどうすればよいですか?

私は、ユーザーが秘密/公開キーベースの認証を使用して SSH 経由でログインする RedHat サーバーを管理しています。

誤ってコンテンツを変更したり削除したり、chmodしたりすることを防ぎたいのです。~/.sshフォルダ。彼らの中には、すでに自分のホームフォルダ全体を再帰的に 777 chmode 化している人もいます。「この方が同僚とファイルを共有するのが簡単だから」という理由で、自ら足を撃ち抜いてしまった人もいます。

これを実現する方法をご存知ですか? できれば標準の Linux 権限システムを使用します。

答え1

簡単に答えると、それはできません。

SSHは権限に関して非常にうるさいので、見た目が気に入らないファイルは扱いません。さらに、ユーザーはssh_config解析されます前にシステム全体の設定。

そうは言っても、5月ファイルを別の場所に置いて、そのディレクトリを各ユーザーの読み取り専用ファイルシステムとしてマウントすることが可能です$HOME/.ssh。(可能ですが、ssh や関連ツールがこれをどのように処理するかはわかりません)。

すでに自分のホームフォルダ全体を再帰的に777-chmodedしている人もいる

そうなると、セキュリティとトレーニングの問題がさらに大きくなります。

答え2

ユーザー自身の無知や無能さからユーザーを保護するのは困難です。

ただし、ユーザーにどの程度自己管理を許可する必要があるか、また管理者がどの程度ユーザーに代わって管理するかに応じて、ホーム ディレクトリ以外の別の場所でキーを検索するように sshd を構成することができます~/.ssh/authorized_keys。

承認されたキーコマンド

比較的複雑な解決策は、/etc/ssh/sshd_config AuthorizedKeysCommand このディレクティブは、authorized_keys ファイルに依存せずに、ユーザーの公開鍵の検索に使用するプログラムを指定します。例:

  • 1つのLDAPディレクトリ

  • 1つのデータベース

  • （些細な）ウェブサービス

  • または、ユーザー名が 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_keysルート所有にすることです。

ルート所有の .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、ユーザーはそれらの権限を変更したり削除したりすることはできません。また、自分の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ルートであっても、いかなる方法でも変更できません。ルートがこれらのファイルを更新する必要がある場合は、chattr -iまずそれらを実行する必要があります。属性を確認するには、を使用しますlsattr。

このアプローチはよりシンプルですが、柔軟性は低くなります。また、ファイルシステムのサポートも必要です。少なくとも ext2/3/4、XFS、btrfs ではサポートされていると思います。

Posix ACL ですか?

また、POSIX ACL について(アクセス制御リスト) を使用すると、より細かい制御が可能になります。私はそれらにあまり詳しくないので、ここで役立つかどうかはわかりません。

厳密モード

注記：強くお勧めしませんが、完全性のために提供されています。

OpenSSH サーバー設定ディレクティブがあると呼ばれStrictModes、SSH が権限をどの程度厳しく扱うかを決定します。

ログインを受け入れる前に、sshd がユーザーのファイルとホーム ディレクトリのファイル モードと所有権をチェックするかどうかを指定します。初心者は誤ってディレクトリまたはファイルをワールド ライト可能のままにしておくことがあるため、これは通常望ましいことです。デフォルトは ですyes。

このオプションを無効にすると、所有権と権限の設定方法の自由度が高まります。ただし、SSH はデフォルトで厳格に設定されていますが、それには理由があります。ユーザーが SSH ファイルを 777-chmod することは、セキュリティ上のリスクとなります。

答え4

毎晩 cron ジョブを実行して権限を修正します。

ファイルの削除は少し難しくなります。cron のバックアップから失われたファイルを復元することもできます。ただし、奇妙なエッジケースが発生する可能性があるようです... スクリプトで提供できる以上のインテリジェンスが必要になる場合があります。小さなことから始めて、復元機能に慎重に機能を追加します。

関連情報