it-swarm-ja.com

sshとホームディレクトリのアクセス許可

~/.sshが700に設定されている場合でも、ユーザーのホームディレクトリがグループアクセス可能である場合、sshdは公開鍵認証の受け入れを拒否しますか? ~/.sshの権限が受け入れられる場合、~の権限が重要なのはなぜですか?

5

その理由は、ホームディレクトリが他の誰かによって書き込み可能である場合、悪意のあるユーザーが~/.sshを作成し、必要なキーを追加して、そのアクセス許可を700に変更できるためだと思います。

すでに~/.sshをお持ちの場合でも、名前を別の名前に変更して、新しいものを作成することができます。

ただし、最近のシステムでは、chownがスーパーユーザーに対してのみ機能するため、このようなトリックは通常不可能です。これは常に当てはまるとは限りません。

以前のバージョンのUNIXでは、すべてのユーザーがchownコマンドを実行して、所有しているファイルの所有権をシステム上の他のユーザーの所有権に変更できました。 ( http://www.diablotin.com/librairie/networking/puis/ch05_07.htm

Chmodがいずれかの方法で動作するかどうかは、 libcコンパイルオプション に依存します。セキュリティのために、OpenSSHサーバーは少し偏執的です。

6
aland

これを修正するには、安全でないルートに移動して、すでに述べたようにStrictModes no/etc/ssh/sshd_configを設定するか、複雑な方法ですべてのユーザーのsshキーをにアクセス可能なディレクトリに保存します。ルートのみ。後者の手順は次のとおりです。

  1. 新しいキーを保持するディレクトリを作成します。ここでは/usr/share/sshkeysを使用します。これは最適な場所ではないかもしれませんが、頭の中で考えられる最高の場所です。

    Sudo mkdir /usr/share/sshkeys
    
  2. /etc/ssh/sshd_configを編集して行を含めます

    AuthorizedKeysFile /usr/share/sshkeys/%u
    
  3. 古い認証済みキーファイルをユーザー(ここでは「exampleuser」と呼びます)から新しいディレクトリにコピーします

    mv /home/exampleuser/.ssh/authorized_keys /usr/share/sshkeys/exampleuser
    
  4. (オプションですが、exampleuserは通常の方法でキーを追加できることを期待しているため、推奨されます)新しいキーファイルを古いキーファイルの場所にリンクし、ユーザーに新しいキーファイルへのアクセスを許可します

    Sudo chown exampleuser /usr/share/sshkeys/exampleuser
    Sudo chmod 600 /usr/share/sshkeys/exampleuser
    ln -s /usr/share/sshkeys/exampleuser /home/exampleuser/.ssh/authorized_keys
    
  5. Sshデーモンを再起動します

    Sudo service sshd restart
    
6
con-f-use