web-dev-qa-db-ja.com

/ etc / securettyのエントリの影響

RHEL 5.5ではデフォルトで

[deuberger@saleen trunk]$ Sudo cat /etc/securetty 
console
vc/1
vc/2
vc/3
vc/4
vc/5
vc/6
vc/7
vc/8
vc/9
vc/10
vc/11
tty1
tty2
tty3
tty4
tty5
tty6
tty7
tty8
tty9
tty10
tty11

各エントリタイプの違いは何ですか（コンソール、vc /、およびtty）。具体的には、各エントリタイプを追加および削除した結果はどうなりますか？

ログインの方法とタイミングに影響するというのが私の理解ですが、他の影響はありますか？また、どのエントリがあるかによって、いつログインでき、いつログインできないのですか？

編集1私が知っていることは、tty 1-6が、CTRL-ALT-F1からCTRL-ALT-F6を使用して到達する最初の6つのコンソールからログインできるかどうかに対応することです。私はいつもそれらが仮想コンソールだと思っていたので、少し混乱しています。そして、コンソールも何に対応していますか？ありがとう。

編集2シングルユーザーモードの場合、どのような影響がありますか？

linuxsecurityrhelloginpam
19
deuberger

/etc/securettyは、pam_securettyモジュールによって参照され、どの仮想端末（ttyS）ルートからのログインを許可するかを決定します。以前は、/etc/securettyは、loginなどのプログラムから直接参照されていましたが、現在はPAMが処理します。したがって、/etc/securettyへの変更は、pam_securetty.soを使用する構成ファイルでPAMを使用するすべてに影響します。したがって、デフォルトで影響を受けるのはログインプログラムだけです。 /etc/pam.d/loginはローカルログインに使用され、/etc/pam.d/remoteはリモートログイン（telnetなど）に使用されます。

主なエントリの種類とその影響は次のとおりです。

  • /etc/securettyが存在しない場合、rootは任意のttyからのログインを許可されます
  • /etc/securettyが存在し、空の場合、ルートアクセスは、pam_securetty（つまり、su、Sudo、ssh、scp、sftp）によって制限されていないシングルユーザーモードまたはプログラムに制限されます。
  • devfs（/ devを処理するための非推奨のファイルシステム）を使用している場合、vc/[0-9] *形式のエントリを追加すると、指定された仮想コンソール番号からのrootログインが許可されます
  • udevを使用している場合（動的デバイス管理とdevfsの置換用）、tty [0-9] *形式のエントリを追加すると、指定された仮想コンソール番号からのrootログインが許可されます
  • securettyにコンソールを一覧表示しても、/ dev/consoleが現在のコンソールを指し、通常は/etc/securettyの影響を受けないシングルユーザーモードのttyファイル名としてのみ使用されるため、効果はありません。
  • pts/[0-9] *のようなエントリを追加すると、割り当てられたptyがリストされているものの1つであると想定して、疑似端末（pty）とpam_securettyを使用するプログラムがrootにログインできるようになります。これはセキュリティ上のリスクがあるため、通常はこれらのエントリを含めないことをお勧めします。たとえば、パスワードをプレーンテキストで送信するテレネット経由で誰かがrootにログインできるようにします（pts/[0-9] *はRHEL 5.5で使用されるudevの形式であることに注意してください。devfsを使用している場合は異なります）またはその他の形式のデバイス管理）

シングルユーザーモードの場合、ログインの代わりにsuloginが使用されるため、/etc/securettyは参照されません。詳細については、suloginのmanページを参照してください。また、各ランレベルの/etc/inittabで使用されるログインプログラムを変更することもできます。

/etc/securettyを使用してssh経由でrootログインを制御しないでください。これを行うには、/etc/ssh/sshd_configのPermitRootLoginの値を変更します。デフォルトでは、/etc/pam.d/sshdはpam_securettyを参照するように構成されていません（したがって/etc/securetty）。そうするための行を追加することもできますが、sshは実際のttyを認証段階の後のある時点まで設定しないため、期待どおりに機能しません。認証とアカウントの段階で（少なくともopensshの場合）、tty（PAM_TTY）は「ssh」にハードコードされます。

上記の回答はRHEL 5.5に基づいています。その多くは他の* nixシステムの現在のディストリビューションに関係しますが、違いはあります。

他の回答が不完全または不正確だったため、自分で回答しました。オンラインの他の多くのフォーラム、ブログなどにも、このトピックに関する不正確で不完全な情報があるため、正確な詳細を取得するために広範囲にわたる調査とテストを行いました。私が言ったことが間違っている場合は、私に知らせてください。

出典：

34
deuberger

_vc/X_とttyXは同義語です。同じデバイスへの異なるパスです。冗長性のポイントは、ロックアウトしないようにさまざまなケースをキャッチすることです。

伝統的に、login（そしておそらくgetty、確かに覚えていないかもしれません）は_/etc/securetty_をチェックし、一覧にない端末でのrootログインを拒否します。最近のシステムでは、これを実行する他の方法と他のセキュリティ対策もあります。 _/etc/login.defs_（securettyの機能もカバーし、securetty(5)のマンページで推奨）の内容と、動作を制御できる_/etc/pam.d/login_の内容を確認してくださいこの機能の。

securettyはloginによってのみチェックされるため、loginを使用しないログイン手段（たとえば、SSHと_use_login=no_、Xディスプレイマネージャーなど）は使用されません影響を受けません。

4
Alexios