Wpływ wpisów na / etc / securetty

Domyślnie na RHEL 5.5 mam

[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

Jaka jest różnica między każdym typem pozycji (konsola, vc / i tty ). W szczególności, jaki jest końcowy wynik dodawania i usuwania każdego typu pozycji?

Rozumiem, że wpływają one na sposób i czas logowania, ale czy są jeszcze inne efekty? A kiedy możesz i kiedy nie możesz się zalogować, w zależności od tego, które wpisy tam są?

EDYCJA 1 Wiem, że tty 1-6 odpowiadają, czy możesz zalogować się z pierwszych 6 konsol, do których docierasz za pomocą CTRL-ALT-F1 przez CTRL-ALT-F6. Zawsze myślałem, że to wirtualne konsole, więc jestem trochę zdezorientowany. A co odpowiada również konsoli? Dzięki.

EDYCJA 2 Jaki jest efekt, jeśli występuje w trybie pojedynczego użytkownika?

/etc/securettyjest konsultowany przez moduł pam_securetty, aby zdecydować, z którego katalogu głównego terminali wirtualnych (ttyS) można się zalogować. W przeszłości /etc/securettykonsultowano się z takimi programami, jak logowanie bezpośrednie, ale teraz PAM to obsługuje. Tak więc zmiany /etc/securettywpłyną na wszystko przy użyciu PAM z plikiem konfiguracyjnym, który używa pam_securetty.so. Tak więc domyślnie dotyczy to tylko programu logowania. /etc/pam.d/loginsłuży do logowania lokalnego i /etc/pam.d/remotesłuży do zdalnego logowania (np. telnet).

Podstawowe typy wpisów i ich wpływ są następujące:

• Jeśli /etc/securettynie istnieje, root może zalogować się z dowolnego tty
• Jeśli /etc/securettyistnieje i jest pusty, dostęp do konta root zostanie ograniczony do trybu jednego użytkownika lub programów, które nie są ograniczone przez pam_securetty (tj. Su, sudo, ssh, scp, sftp)
• jeśli używasz devfs (przestarzały system plików do obsługi / dev), dodanie wpisów w formie vc / [0-9] * pozwoli na zalogowanie roota z podanego numeru wirtualnej konsoli
• jeśli używasz udev (do dynamicznego zarządzania urządzeniami i zamiany na devfs), dodanie wpisów z formularza tty [0-9] * pozwoli na zalogowanie roota z podanego numeru konsoli wirtualnej
• wyświetlenie konsoli w Securetty zwykle nie ma żadnego efektu, ponieważ / dev / console wskazuje na bieżącą konsolę i zwykle jest używana tylko jako nazwa pliku tty w trybie pojedynczego użytkownika, na co nie ma wpływu /etc/securetty
• dodanie wpisów takich jak pts / [0-9] * pozwoli programom używającym pseudo-terminali (pty) i pam_securetty zalogować się do roota, zakładając, że przydzielony pty jest jednym z wymienionych; zwykle dobrym pomysłem jest nieuwzględnianie tych wpisów, ponieważ stanowi to zagrożenie bezpieczeństwa; pozwoliłby na przykład komuś zalogować się do roota przez telenet, który wysyła hasła w postaci zwykłego tekstu (zauważ, że pts / [0-9] * jest formatem udev używanym w RHEL 5.5; inaczej będzie, jeśli użyjesz devfs lub inna forma zarządzania urządzeniem)

W przypadku trybu pojedynczego użytkownika /etc/securettynie jest konsultowane, ponieważ zamiast logowania używana jest sulogina. Zobacz stronę podręcznika użytkownika sulogin, aby uzyskać więcej informacji. Możesz także zmienić program logowania używany /etc/inittabdla każdego poziomu pracy.

Zauważ, że nie powinieneś używać /etc/securettydo kontrolowania loginów root poprzez ssh. Aby to zrobić, zmień wartość PermitRootLogin w /etc/ssh/sshd_config. Domyślnie /etc/pam.d/sshdnie jest skonfigurowany do przeglądania pam_securetty (i dlatego /etc/securetty). Możesz dodać linię, aby to zrobić, ale ssh nie ustawia rzeczywistego tty, dopóki jakiś czas po etapie autoryzacji, więc nie działa zgodnie z oczekiwaniami. Na etapie uwierzytelniania i konta - przynajmniej dla openssh - tty (PAM_TTY) jest na stałe zakodowane na „ssh”.

Powyższa odpowiedź oparta jest na RHEL 5.5. Wiele z nich dotyczy bieżących dystrybucji innych systemów * nix, ale istnieją różnice, z których niektóre zauważyłem, ale nie wszystkie.

Sam na to odpowiedziałem, ponieważ inne odpowiedzi były niepełne i / lub niedokładne. Wiele innych forów, blogów itp. W Internecie zawiera również niedokładne i niekompletne informacje w tym temacie, dlatego przeprowadziłem szeroko zakrojone badania i testy, aby uzyskać prawidłowe szczegóły. Jeśli cokolwiek, co powiedziałem, jest złe, daj mi jednak znać.

Źródła:

• http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/ch-sec-network.html#s1-wstation-privileges
• http://www.mathematik.uni-marburg.de/local-doc/centos5/pam-0.99.6.2/html/sag-pam_securetty.html
• http://linux.die.net/man/1/login
• http://www.tldp.org/HOWTO/html_single/Text-Terminal-HOWTO/
• http://www.kernel.org/doc/Documentation/devices.txt
• http://en.wikipedia.org/wiki/Virtual_console
• http://en.wikipedia.org/wiki/Linux_console
• http://www.kernel.org/doc/man-pages/online/pages/man4/console.4.html
• http://www.unix.com/security/8527-restricting-root-login.html
• http://www.redhat.com/mirrors/LDP/HOWTO/Serial-HOWTO-11.html#ss11.3
• http://www.mathematik.uni-marburg.de/local-doc/centos5/udev-095/udev_vs_devfs

vc/Xi ttyXsą synonimami: różne ścieżki do tych samych urządzeń. Redundancja polega na wyłapywaniu różnych przypadków, aby cię nie zablokować.

Tradycyjnie login(i być gettymoże nie pamiętam na pewno) sprawdzałby /etc/securettyi odmawiał rootlogowania na niepublicznych terminalach. W nowoczesnych systemach istnieją inne sposoby, aby to zrobić, a także inne środki bezpieczeństwa. Sprawdź zawartość /etc/login.defs(która obejmuje również securettyfunkcjonalność i jest zalecana przezsecuretty(5) podręcznika), a także /etc/pam.d/login, gdzie możesz kontrolować zachowanie tej funkcji.

Ponieważ securettyjest to sprawdzane tylko przez login, nie wpływa to na logowanie, które nie używa login(np. SSH z use_login=noX menedżerami wyświetlania itp.).