☰

RHEL 7（CentOS 7）セキュリティ/ ssh / sshd_config提案リクエスト

tag-icon • tag-icon centos rhel security sshd public-key-authentication
RHEL 7（CentOS 7）セキュリティ/ ssh / sshd_config提案リクエスト

私はシステム管理者ではなく、やや安全なWebサーバー（LAMPベース）を作成しようとしています。オペレーティングシステム7）。
初期のCentOS 7 Droplet設定に関するいくつかのチュートリアルを読んで、すべてがうまくいきました。

しかし、私が読んだ記事で読んだ基本概念のいくつかを理解するのが難しく、副作用について確信が持てないので、より資格のある人の意見が必要です。

ご意見ありがとうございました。

想像する：
Digital Oceanでcloud-init（userdata）を使用して新しいDropletを作成して設定しています。私が理解したように、cloud-initはsystem / rootとして実行され、次の設定、特にrootのssh_configを生成します。

  • そのユーザーのSSHキー（ssh-authorized-keys）に基づいて新しいユーザーを作成します（この場合は管理者と呼ばれます）。
  • Wheel グループにユーザーを追加し、sudo を設定します: ['ALL=(ALL) NOPASSWD:ALL']
  • /etc/ssh/sshd_config で root ログインを無効にします。
  • ユーザーが/etc/ssh/sshd_configで管理できるようにする
  • /etc/ssh/sshd_configでPasswordAuthentication noを設定する
  • /etc/ssh/sshd_config で PubkeyAuthentication yes と RSAAuthentication yes を設定します。
  • ファイアウォールの構成およびその他のタスクの実行

質問：

  1. 管理者権限でSSH経由でMy Dropletに接続した後、関連するsshd_configは空です。 Dropletを作成してcloudconfigを実行すると、cloud-initがsystem / rootとして実行されているようです。

    1.1 rootユーザー用のDropletを作成するのと同じ設定をここで設定する必要がありますか？ 1.2 それでは、複数のssh_configファイルのポイントは何ですか？

  2. cloud-initログファイルを見ると、ルートに対して公開/個人のRSSキーペアが生成されたことがわかります。
    rootユーザーに最初のSSHキーを提供しないことにしたので、関連するパスワードが私にメールで送信されました（単にテスト目的で）。
    ただし、新しく作成されたユーザーadminで/を実行すると、次のようにls -aなります。etc/ssh

    . moduli sshd_config ssh_host_dsa_key.pub ssh_host_ecdsa_key.pub ssh_host_rsa_key.pub .. ssh_config ssh_host_dsa_key ssh_host_ecdsa_key ssh_host_rsa_key

    たとえば、rootユーザー用に生成された同じSSHキーを含むssh_host_rsa_keyを見てください。

    2.1新しく作成されたadmin（rootではなく）というユーザーがsshフォルダにrootと同じキーを持つのはなぜですか？

    2.2私は彼をグループホイールに追加し、sudo：['ALL =（ALL）NOPASSWD：ALL']を追加しましたか？おすすめですか？

    2.3他のユーザーアカウントが破損する可能性があり、ハッカーを非常に幸運な人にするために必要なすべてのキーがある場合、sshを介したリモートログインでrootを無効にするのはなぜですか？ただ、ユーザーの名前を推測しにくくするのは目的ですか？

  3. 一部のタスクにはまだsudo / root権限が必要であることがわかっています。管理者としてログインすると、su root を使用して root に変更できます。

    3.1私は/etc/ssh/sshd_config（sshのみ）でrootログインを無効にしましたが、同じ権限を持つ新しいユーザー（管理者）を作成し、rootに簡単に切り替えることができるときに何ができるかを尋ねました。このパスワードは良いですか？それとも、セキュリティレベルを追加する二重認証のようなものはありますか？

    3.2。一方、管理者アカウント制御を正常に取得したハッカーがルートのSSHキー（上記の前のトピックを参照）を読みやすくしてセキュリティレベルを迂回できる場合は、これがどのように優れているかわかりません。

要約すると、読んでいるものは本当に気に入っていますが、ファイルシステムを見るとき、特にcloud-initを使用して作成したユーザーSSHフォルダでルートSSHキー（個人とパブリック）を見つけた後、少し心配です。何か誤解をしていることについて。

ところで：これは私のcloud-initスクリプトです。

#cloud-config

# log all cloud-init process output (info & errors) to a logfile
output: {all: ">> /var/log/cloud-init-output.log"}

# final_message written to log when cloud-init processes are finished
final_message: "System boot (via cloud-init) is COMPLETE, after $UPTIME seconds. Finished at $TIMESTAMP"

package_upgrade: true

users:
  - name: admin
    groups: wheel
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    shell: /bin/bash
    ssh-authorized-keys:
      - ssh-dss AAAABBBBBCCCCDDDD...
runcmd:
  - sed -i -e 's/#Protocol 2/Protocol 2/g' /etc/ssh/sshd_config
  - sed -i -e 's/#LoginGraceTime 2m/LoginGraceTime 2m/g' /etc/ssh/sshd_config
  - sed -i -e 's/#PermitRootLogin yes/PermitRootLogin no/g' /etc/ssh/sshd_config
  - sed -i -e 's/PasswordAuthentication yes/PasswordAuthentication no/g' /etc/ssh/sshd_config
  - sed -i -e 's/#RSAAuthentication yes/RSAAuthentication yes/g' /etc/ssh/sshd_config
  - sed -i -e 's/#PubkeyAuthentication yes/PubkeyAuthentication yes/g' /etc/ssh/sshd_config
  - sed -i -e '$aAllowUsers admin' /etc/ssh/sshd_config
  - service sshd restart

  #firewall
  - systemctl start firewalld
  - firewall-cmd --permanent --add-service=ssh
  - firewall-cmd --reload
  - systemctl enable firewalld

ベストアンサー1

ほとんどの質問に対する答えではありませんが、コメントが長すぎます。

  1. 別のユーザー（「admin」でも別のユーザーでも）がある理由は、画像に別の認証/許可層を追加することです（キー/パスワードを使用してユーザーとしてログインし、別のパスワードを入力してrootになります）。 ）。ユーザーがrootと同じUIDを持っていない場合は、「一般」ユーザーよりも高い権限を持つことができますが、rootと同じ権限を持っていません。

    また、他のユーザーが同じアカウントにアクセスできます。あるアカウントは別のキーで認証できます。これにより、複数のユーザー（および複数のコンピューター）がある場合の作業が簡単になります。他のユーザーを中断せずに特定のユーザーの権限を取り消すことは、ファイルからエントリを削除するだけですAuthorizedKeys（通常、~/.ssh/authorized_keys`。（明らかに同じです））直接ルートアクセスに適用されますが、追加の認証/権限レベルはありません）。

    攻撃者が鍵を使用できる場合：鍵の公開部分のみをサーバーに保存する必要があります。認証フェーズでは、クライアントは自分の秘密鍵を使用しますが、それをサーバーのどこにも置きません。したがって、サーバーからrootアクセス権を取得した人は、通常のユーザーとしてリモートでログインする能力を取得できません（そのコンピュータに秘密鍵を保持しません）。

    その他の事項については、一般的に次のように進めます。
    Q：「あなたのシステムへのルートアクセスを得た人を何と呼びますか？」
    ㅏ：「わかりました」

  2. コマンドラインの前に「sudo」を付けて、すべてのユーザーがroot権限ですべてのコマンドを実行できるようにすることが正しいですsudo。一部の人々はこれが良い考えだと思いますが、セキュリティの観点から見ると、これは最も愚かなことの1つです。誰もがシステム管理者にします。唯一の利点は、人々が誤って高いrm -Rf /権限（root直接ログインなど）で実行できないことです。しかし、筋肉の記憶が始まり、人々はsudoそれをどこでも使用し始め、残りの唯一の利点は命令を記録する能力だけでした。ご存知のように、これはセカンダリアカウントの目的にも反対です。

    簡単に言うと：ALL=(ALL) NOPASSWD:ALLTMは悪い考えです。、サーバーでは倍増しました。お願いしないでください。

    それを過ぎると、突然パート1）がはるかに理解され始めます。

おすすめ記事