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


19

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 シングルユーザーモードである場合の影響は何ですか?

回答:


34

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

主なエントリタイプとその影響は次のとおりです。

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

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

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

上記の回答はRHEL 5.5に基づいています。その多くは、他の* nixシステムの現在の分布に関係しますが、違いがありますが、すべてではありませんが、いくつかを指摘しました。

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

ソース:


そのような深さで応答するために時間をかけるための+1。なぜここに受け入れられた答えがないのか分かりません。OPの質問に回答したようです。私は@Alexiosのコメント、「vc / XとttyXは同義語です...」
harperville

Debianは最近/ etc / securettyを削除しました。それは時代遅れだと考えられており、それは価値があるよりも間違いなく多くのトラブルです。telnetおよびrloginに使用されていましたが、一部のコンテナログインを機能させるために、一部のシステムに「pts / 0」などの疑似端末が追加され、元の目的を無効にします。ルートログインを特定のデバイスセットに制限する必要がある場合は、より信頼性の高いメカニズムがあります。参照してくださいbugs.debian.org/731656
dlitz

4

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ディスプレイマネージャは、)影響を受けません。


busyboxベースのシステムでloginは、/etc/login.defsサポートがないという単純な事実のためにまだ有用である可能性があることに注意してください。
phk
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.