Chỉ cho phép người dùng cụ thể đăng nhập qua ssh tại một cổng và những người khác đăng nhập qua cổng khác


13

Tôi có trường hợp sử dụng sau đây:

  • Cần cho phép người dùng đăng nhập từ một mạng được bảo mật, đáng tin cậy
  • và sau đó cho phép một vài (chỉ hai) người dùng di động đăng nhập từ xa trên máy Linux Centos.

Tôi có thể làm cho sshd chạy trên các cổng khác nhau, vd:

  • từ bên trong, bạn có thể chạy nó vào ngày 22 vì tôi không muốn làm cho chúng kết nối trên các cổng khác (làm rối kịch bản).
  • Đối với người dùng di động bên ngoài, tôi sẽ chạy sshd trên một cổng khác, giả sử cổng X (tăng tính bảo mật - đây là một loại thiết lập văn phòng nhỏ).

Để bảo mật hơn, tôi đã hy vọng định cấu hình sshd để chỉ cho phép truy cập vào những người dùng cụ thể trên cổng X (và sau đó định cấu hình một số cảnh báo để chúng tôi có thể biết khi nào người dùng đăng nhập qua cổng X).

Tuy nhiên, tôi không thể tìm thấy bất kỳ cấu hình như thế này trong tài liệu sshd. Nếu không có giải pháp nào như thế này, thì ít nhất có thể kích hoạt tập lệnh shell để chạy bất cứ khi nào ai đó hoàn thành đăng nhập sshd trên cổng X không? Tôi đã xem tài liệu của iptables để xem liệu nó có thể kích hoạt cảnh báo khi đăng nhập sshd ở đó không nhưng không thể đưa ra bất cứ điều gì.

Đầu vào đánh giá cao

Câu trả lời:


12

Chạy SSHtrên một cổng thay thế không được tính là bảo mật nữa. Nó chỉ thêm một chút tối nghĩa và thêm một bước phức tạp cho người dùng của bạn. Nó bổ sung thêm các chướng ngại vật cho những người đang tìm cách phá vỡ mạng của bạn, những người đang sử dụng máy quét cổng tự động và không quan tâm nó chạy trên cổng nào.

Nếu bạn muốn tăng cường bảo mật trên một hệ thống cho phép SSH gửi đến từ xa dựa trên internet, hãy kiểm soát người dùng của bạn theo sshd_confignhư @Anthon đã chỉ định, sau đó cũng triển khai bảo mật trực tiếp trong PAM.

Tạo hai nhóm, lusersrusers. Thêm người dùng di động từ xa vào rusersnhóm. Sử dụng mô-đun PAM pam_succeed_if.so để cho phép truy cập vào những người dùng đó. Thêm dòng vào cấu hình pam của bạn cho ssh:

account     sufficient  pam_succeed_if.so user ingroup lusers
account     sufficient  pam_succeed_if.so user ingroup rusers

Một số mô-đun pam_succeed_if.so có thể yêu cầu bạn sử dụng cú pháp hơi khác nhau, như group = lusers.

Sau đó, không chỉ sshdgiới hạn người dùng có thể kết nối mà trong trường hợp xảy ra lỗi sshd, bạn vẫn có sự bảo vệ mà các hạn chế dựa trên PAM đưa ra.

Một bước bổ sung cho người dùng từ xa là buộc sử dụng ssh_keys với cụm mật khẩu. Vì vậy, người dùng cục bộ có thể đăng nhập bằng khóa hoặc mật khẩu, nhưng người dùng từ xa phải có khóa và nếu bạn tạo khóa cho họ, bạn có thể đảm bảo khóa có liên kết cụm mật khẩu. Do đó, giới hạn quyền truy cập vào các vị trí thực sự sở hữu khóa SSH cụm mật khẩu. Và hạn chế các vectơ tấn công tiềm năng nếu mật khẩu của người dùng được tổng hợp.

Trong sshd_config:

thay đổi 2 cài đặt:

ChallengeResponseAuthentication yes

PasswordAuthentication yes

đến:

ChallengeResponseAuthentication no

PasswordAuthentication no

Vì vậy, mặc định bây giờ chỉ cho phép xác thực khóa. Sau đó, đối với người dùng cục bộ, bạn có thể sử dụng matchcài đặt cấu hình để thay đổi mặc định cho người dùng cục bộ. Giả sử mạng riêng cục bộ của bạn là 192.168.1.0/24, hãy thêm vào sshd_config:

Match Address 192.168.1.0/24
PasswordAuthentication yes

Giờ đây, người dùng cục bộ có thể kết nối với mật khẩu hoặc khóa và người dùng từ xa sẽ buộc phải sử dụng khóa. Tùy thuộc vào bạn để tạo các khóa với cụm từ.

Là một lợi ích bổ sung, bạn chỉ phải quản lý một lần duy nhất sshd_configvà bạn chỉ phải chạy ssh trên một cổng duy nhất, giúp giảm bớt sự quản lý của chính bạn.


chỉnh sửa 2017-01-21 - Hạn chế sử dụng authorized_keystệp.

Nếu bạn muốn đảm bảo rằng người dùng không thể tự tạo khóa ssh và sử dụng nó với một authorized_keystệp để đăng nhập, bạn có thể kiểm soát điều đó bằng cách đặt một vị trí cụ thể cho sshd sẽ tìm các khóa được ủy quyền.

Trong /etc/ssh/sshd_config, thay đổi:

AuthorizedKeysFile  %h/ssh/authorized_keys

đến một cái gì đó như:

AuthorizedKeysFile  /etc/.ssh/authorized_keys/%u

Chỉ vào một thư mục được kiểm soát mà người dùng không có quyền viết để có nghĩa là họ không thể tạo khóa riêng và sử dụng nó để giải quyết các quy tắc bạn đã đặt.


2
Tôi không thấy câu trả lời của bạn phân biệt người dùng từ xa với người dùng địa phương. Nếu ai đó trong lusersnhóm nhưng không trong rusersnhóm tạo ra một cặp khóa và cập nhật thông tin của họ ~/.ssh/authorized_keys, họ sẽ có thể đăng nhập từ xa.
Richard Hansen

8

Bạn có thể thêm một cái gì đó như thế này vào /etc/ssh/sshd_config:

AllowUsers mobileuser1 mobileuser2 *@10.0.0.0/8

Ở trên giả định rằng người dùng từ xa được phép được đặt tên mobileuser1mobileuser2, và mạng đáng tin cậy của bạn là 10.0.0.0 với mặt nạ mạng con 255.0.0.0.

Điều này cho phép hai người dùng di động đăng nhập từ bất cứ đâu và mọi người đăng nhập từ mạng đáng tin cậy. Bất kỳ người dùng nào không khớp với bất kỳ mẫu nào trong số đó (chẳng hạn như người dùng foođăng nhập từ xa) sẽ bị từ chối truy cập.


Đó là mảnh tôi đã bỏ lỡ trong câu trả lời của tôi. Tôi nghĩ rằng nếu chúng tôi kết hợp câu trả lời của bạn với tôi, đó là một giải pháp khá mạnh mẽ.
Tim Kennedy

2

Bạn có thể làm điều này bằng cách bắt đầu hai ssh daemon và hai sshd_configtệp. Sao chép cái hiện có của bạn (ví dụ từ /etc/ssh/sshd_config /etc/ssh/sshd_alt_configvà trong thiết lập cấu hình thay thế (từ mantrang cho sshd_config:

Hải cảng

Specifies the port number that sshd(8) listens on.  The default
is 22.  Multiple options of this type are permitted.  See also
ListenAddress

Người dùng cho phép

This keyword can be followed by a list of user name patterns,
separated by spaces.  If specified, login is allowed only for
user names that match one of the patterns.  Only user names are
valid; a numerical user ID is not recognized.  By default, login
is allowed for all users.  If the pattern takes the form
USER@HOST then USER and HOST are separately checked, restricting
logins to particular users from particular hosts.  The
allow/deny directives are processed in the following order:
DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.

Bạn có thể muốn có nhật ký ssh thay thế cho một tệp khác, và ví dụ: làm theo những gì được ghi vào tệp đó để nhận thấy các nỗ lực đăng nhập bất thường.

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.