Ảnh hưởng của các mục trong / etc / securetty


19

Theo mặc định trên RHEL 5.5 tôi có

[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

Sự khác biệt giữa từng loại mục nhập (console, vc / và tty ) là gì. Cụ thể, kết quả cuối cùng của việc thêm và xóa từng loại mục là gì?

Sự hiểu biết của tôi là chúng ảnh hưởng đến cách thức và thời điểm bạn có thể đăng nhập, nhưng có bất kỳ hiệu ứng nào khác không? Và khi nào bạn có thể và khi nào bạn không thể đăng nhập tùy thuộc vào mục nào?

EDIT 1 Điều tôi biết là tty 1-6 tương ứng với việc bạn có thể đăng nhập từ 6 bảng điều khiển đầu tiên mà bạn đạt được bằng cách sử dụng CTRL-ALT-F1 thông qua CTRL-ALT-F6. Tôi luôn nghĩ đó là những máy chơi game ảo, vì vậy tôi hơi bối rối. Và giao diện điều khiển tương ứng là gì? Cảm ơn.

EDIT 2 Hiệu ứng nếu có trong chế độ người dùng đơn là gì?

Câu trả lời:


34

/etc/securettyđược tham khảo bởi mô-đun pam_securetty để quyết định từ gốc thiết bị đầu cuối ảo (ttyS) nào được phép đăng nhập từ đó. Trước đây, /etc/securettyđược tư vấn bởi các chương trình như đăng nhập trực tiếp, nhưng bây giờ PAM xử lý việc đó. Vì vậy, những thay đổi /etc/securettysẽ ảnh hưởng đến mọi thứ khi sử dụng PAM với tệp cấu hình sử dụng pam_securetty.so. Vì vậy, chỉ có chương trình đăng nhập bị ảnh hưởng theo mặc định. /etc/pam.d/loginđược sử dụng cho đăng nhập cục bộ và /etc/pam.d/remoteđược sử dụng cho đăng nhập từ xa (như telnet).

Các loại mục nhập chính và ảnh hưởng của chúng là như sau:

  • Nếu /etc/securettykhông tồn tại, root được phép đăng nhập từ bất kỳ tty nào
  • Nếu /etc/securettytồn tại và trống, quyền truy cập root sẽ bị hạn chế ở chế độ người dùng hoặc các chương trình không bị hạn chế bởi pam_securetty (ví dụ: su, sudo, ssh, scp, sftp)
  • nếu bạn đang sử dụng devfs (hệ thống tệp không dùng để xử lý / dev), việc thêm các mục có dạng vc / [0-9] * sẽ cho phép đăng nhập root từ số bảng điều khiển ảo đã cho
  • nếu bạn đang sử dụng udev (để quản lý và thay thế thiết bị động cho devfs), việc thêm các mục ở dạng tty [0-9] * sẽ cho phép đăng nhập root từ số bảng điều khiển ảo đã cho
  • bảng điều khiển liệt kê trong securetty, thường không có tác dụng vì / dev / bàn điều khiển trỏ đến bảng điều khiển hiện tại và thường chỉ được sử dụng làm tên tệp tty trong chế độ người dùng duy nhất, không bị ảnh hưởng bởi /etc/securetty
  • thêm các mục như pts / [0-9] * sẽ cho phép các chương trình sử dụng thiết bị đầu cuối giả (pty) và pam_securetty để đăng nhập vào root giả sử pty được phân bổ là một trong những chương trình được liệt kê; Thông thường, không nên bao gồm các mục này vì đó là rủi ro bảo mật; chẳng hạn, nó sẽ cho phép ai đó đăng nhập vào root thông qua telenet, sẽ gửi mật khẩu trong bản rõ (lưu ý rằng pts / [0-9] * là định dạng cho udev được sử dụng trong RHEL 5.5; nó sẽ khác nếu sử dụng devfs hoặc một số hình thức quản lý thiết bị khác)

Đối với chế độ người dùng, /etc/securettykhông được tham khảo vì sulogin được sử dụng thay vì đăng nhập. Xem trang người đàn ông sulogin để biết thêm. Ngoài ra, bạn có thể thay đổi chương trình đăng nhập được sử dụng /etc/inittabcho mỗi runlevel.

Lưu ý rằng bạn không nên sử dụng /etc/securettyđể kiểm soát đăng nhập gốc thông qua ssh. Để làm điều đó thay đổi giá trị của PermitRootLogin trong /etc/ssh/sshd_config. Theo mặc định /etc/pam.d/sshdkhông được cấu hình để tham khảo pam_securetty (và do đó /etc/securetty). Bạn có thể thêm một dòng để làm như vậy, nhưng ssh không đặt tty thực tế cho đến khi nào đó sau giai đoạn xác thực, vì vậy nó không hoạt động như mong đợi. Trong giai đoạn xác thực và tài khoản - ít nhất là cho openssh - tty (PAM_TTY) được mã hóa thành "ssh".

Câu trả lời trên được dựa trên RHEL 5.5. Phần lớn nó sẽ liên quan đến các bản phân phối hiện tại của các hệ thống * nix khác, nhưng có những khác biệt, một số trong đó tôi lưu ý, nhưng không phải tất cả.

Tôi đã tự trả lời điều này vì các câu trả lời khác không đầy đủ và / hoặc không chính xác. Nhiều diễn đàn, blog, vv trực tuyến cũng có thông tin không chính xác và không đầy đủ trong chủ đề này, vì vậy tôi đã thực hiện nghiên cứu và thử nghiệm rộng rãi để cố gắng có được thông tin chi tiết chính xác. Nếu bất cứ điều gì tôi nói là sai, xin vui lòng cho tôi biết mặc dù.

Nguồn:


+1 để dành thời gian trả lời theo chiều sâu như vậy. Tôi không chắc tại sao không có câu trả lời được chấp nhận ở đây. Có vẻ như bạn đã trả lời câu hỏi của OP. Tôi thích bình luận của @Alexios, "vc / X và ttyX là từ đồng nghĩa [ous] ..."
harperville

Debian gần đây đã gỡ bỏ / etc / securetty. Nó được coi là lỗi thời, và có thể gây rắc rối nhiều hơn giá trị của nó. Nó được sử dụng cho telnet và rlogin, nhưng để có được một số thông tin đăng nhập container hoạt động, các giả danh như "pts / 0" được thêm vào một số hệ thống, đánh bại mục đích ban đầu của nó. Nếu bạn cần hạn chế đăng nhập root vào một bộ thiết bị cụ thể, có nhiều cơ chế đáng tin cậy hơn. Xem bug.debian.org/731656
dlitz

4

vc/XttyXlà từ đồng nghĩa: các đường dẫn khác nhau đến cùng một thiết bị. Điểm quan trọng của sự dư thừa là bắt các trường hợp khác nhau để không khóa bạn.

Theo truyền thống, login(và có thể getty, tôi không thể nhớ chắc chắn) sẽ kiểm tra /etc/securettyvà từ chối rootđăng nhập trên các thiết bị đầu cuối chưa niêm yết. Trên các hệ thống hiện đại, có nhiều cách khác để làm điều này và các biện pháp bảo mật khác. Kiểm tra nội dung của /etc/login.defs(cũng bao gồm securettychức năng của trang và được đề xuất bởi securetty(5)trang chủ), đồng thời /etc/pam.d/login, nơi bạn có thể kiểm soát hành vi của tính năng này.

securettychỉ được kiểm tra bởi login, nên các phương tiện đăng nhập không sử dụng login(ví dụ: SSH với use_login=no, trình quản lý hiển thị X, v.v.) không bị ảnh hưởng.


Điều đáng chú ý là busybox các hệ thống dựa trên nó vẫn có thể được sử dụng vì thực tế đơn giản là nó loginkhông có /etc/login.defshỗ trợ.
phk
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.