/ 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

각 항목 유형 (console, vc / 및 tty ) 의 차이점은 무엇입니까? 구체적으로, 각 항목 유형을 추가하고 제거한 최종 결과는 무엇입니까?

내 이해는 로그인 방법과시기에 영향을 미치지 만 다른 영향이 있습니까? 어떤 항목이 있는지에 따라 언제 로그인 할 수 있습니까?

편집 1
내가 아는 것은 tty 1-6은 CTRL-ALT-F1에서 CTRL-ALT-F6을 통해 CTRL-ALT-F1을 사용하여 도달하는 처음 6 개의 콘솔에서 로그인 할 수 있는지 여부에 해당합니다. 나는 항상 그것들이 가상 콘솔이라고 생각했기 때문에 약간 혼란 스럽습니다. 그리고 콘솔도 무엇에 해당합니까? 감사.

편집 2
단일 사용자 모드에서 어떤 영향이 있습니까?



답변

/etc/securetty어떤 가상 터미널 (ttyS) 루트에서 로그인이 허용되는지 결정하기 위해 pam_securetty 모듈이 문의합니다. 과거에는 /etc/securetty로그인과 같은 프로그램에서 직접 문의했지만 이제는 PAM이 처리합니다. 따라서 /etc/securettypam_securetty.so를 사용하는 구성 파일과 함께 PAM을 사용하는 모든 항목에 변경 사항이 적용 됩니다. 따라서 기본적으로 로그인 프로그램 만 영향을받습니다. /etc/pam.d/login로컬 로그인 /etc/pam.d/remote에 사용되며 텔넷과 같은 원격 로그인에 사용됩니다.

기본 항목 유형과 그 영향은 다음과 같습니다.

  • /etc/securetty존재하지 않는 경우 루트는 모든 tty에서 로그인 할 수 있습니다
  • 경우 /etc/securetty존재가 비어있는, 루트 액세스가 pam_securetty에 의해 제한되지 않습니다 단일 사용자 모드 또는 프로그램에 제한됩니다 (예 : SU, sudo를, SSH, SCP, SFTP를)
  • devfs (/ dev 처리를 위해 더 이상 사용되지 않는 파일 시스템)를 사용하는 경우 vc / [0-9] * 형식의 항목을 추가하면 지정된 가상 콘솔 번호에서 루트 로그인이 허용됩니다.
  • udev (동적 장치 관리 및 devfs 대체 용)를 사용하는 경우 tty [0-9] * 형식의 항목을 추가하면 주어진 가상 콘솔 번호에서 루트 로그인이 허용됩니다.
  • securetty에 콘솔을 나열하면 일반적으로 / dev / console이 현재 콘솔을 가리 키므로 영향을 미치지 않으며 일반적으로 단일 사용자 모드에서 tty 파일 이름으로 만 사용됩니다. /etc/securetty
  • pts / [0-9] *와 같은 항목을 추가하면 의사 터미널 (pty) 및 pam_securetty를 사용하는 프로그램이 할당 된 pty가 나열된 항목 중 하나라고 가정하여 루트에 로그인 할 수 있습니다. 보안 상 위험하므로 일반적으로 이러한 항목을 포함하지 않는 것이 좋습니다. 예를 들어 누군가가 텔레 넷을 통해 루트에 로그인 할 수있게하는데, 일반 텍스트로 비밀번호를 전송합니다 (pts / [0-9] *는 RHEL 5.5에서 사용되는 udev의 형식이며, devfs를 사용하는 경우에는 다릅니다) 또는 다른 형태의 장치 관리)

단일 사용자 모드 /etc/securetty의 경우 로그인 대신 sulogin이 사용되므로 참조하지 않습니다. 자세한 내용은 sulogin 매뉴얼 페이지를 참조하십시오. 또한 /etc/inittab각 런레벨에 사용되는 로그인 프로그램을 변경할 수 있습니다 .

/etc/securettyssh를 통해 루트 로그인을 제어 하는 데 사용해서는 안됩니다 . 그렇게하려면에서 PermitRootLogin의 값을 변경하십시오 /etc/ssh/sshd_config. 기본적으로 /etc/pam.d/sshdpam_securetty (및 따라서 /etc/securetty) 를 참조하도록 구성되어 있지 않습니다 . 그렇게하기 위해 줄을 추가 할 수는 있지만 ssh는 인증 단계 이후 언젠가까지 실제 tty를 설정하지 않으므로 예상대로 작동하지 않습니다. 인증 및 계정 단계 (적어도 openssh의 경우)에서 tty (PAM_TTY)는 “ssh”로 하드 코딩됩니다.

위의 답변은 RHEL 5.5를 기반으로합니다. 그것의 대부분은 다른 * nix 시스템의 현재 배포판과 관련이 있지만 차이점이 있지만 그중 일부는 내가 지적했지만 전부는 아닙니다.

다른 답변이 불완전하거나 부정확했기 때문에 직접 대답했습니다. 온라인에있는 다른 많은 포럼, 블로그 등에서도이 주제에 대한 정보가 부정확하고 불완전합니다. 따라서 정확한 세부 정보를 얻기 위해 광범위한 조사와 테스트를 수행했습니다. 내가 말한 내용이 잘못된 경우 알려주십시오.

출처 :


답변

vc/XttyX같은 디바이스에 다른 경로 : 동의어이다. 이중화의 요점은 여러 가지 경우를 잡아서 잠그지 않도록하는 것입니다.

전통적으로 login(그리고 아마도 getty기억이 나지 않을 것입니다) 나열되지 않은 터미널에서 로그인을 확인 /etc/securetty하고 거부 root합니다. 최신 시스템에는이를 수행하는 다른 방법과 다른 보안 조치도 있습니다. 의 기능을 /etc/login.defs다루고 맨 페이지에서 securetty권장하는 내용 과이 기능의 동작을 제어 할 수 있는 내용을 확인하십시오 .securetty(5)/etc/pam.d/login

securetty로만 확인 되므로 login사용하지 않는 로그인 수단 login(예 : SSH with use_login=no, X 디스플레이 관리자 등)은 영향을받지 않습니다.