Cách thiết lập xác thực đa yếu tố cho SSH trên CentOS 7

Giới thiệu

An yếu tố xác thực là một phần thông tin được sử dụng để chứng minh bạn có quyền thực hiện một hành động, như đăng nhập vào một hệ thống. An kênh xác thực là cách một hệ thống xác thực cung cấp một yếu tố cho người dùng hoặc yêu cầu người dùng trả lời. Mật khẩu và mã thông báo bảo mật là ví dụ về các yếu tố xác thực; máy tính và điện thoại là ví dụ về các kênh.

SSH sử dụng mật khẩu để xác thực theo mặc định và hầu hết các hướng dẫn làm cứng SSH đều khuyên bạn nên sử dụng khóa SSH thay thế. Tuy nhiên, đây vẫn chỉ là một yếu tố duy nhất. Nếu một diễn viên xấu đã xâm phạm máy tính của bạn thì họ cũng có thể sử dụng khóa của bạn để thỏa hiệp máy chủ của bạn.

Trong hướng dẫn này, chúng tôi sẽ thiết lập xác thực đa yếu tố để chống lại điều đó. Xác thực đa yếu tố (MFA) yêu cầu nhiều hơn một yếu tố để xác thực hoặc đăng nhập. Điều này có nghĩa là một diễn viên xấu sẽ phải thỏa hiệp nhiều thứ, như cả máy tính và điện thoại của bạn, để tham gia. Các loại yếu tố khác nhau thường được tóm tắt là :

1. Một cái gì đó bạn biết, như mật khẩu hoặc câu hỏi bảo mật
2. Một cái gì đó bạn có, như ứng dụng xác thực hoặc mã thông báo bảo mật
3. Một cái gì đó bạn là, như vân tay hoặc giọng nói của bạn

Một yếu tố phổ biến là ứng dụng OATH-TOTP, như Google Authenticator. OATH-TOTP (Mật khẩu một lần xác thực mở) là một giao thức mở tạo mật khẩu sử dụng một lần, thường là một số có 6 chữ số được tái chế sau mỗi 30 giây.

Bài viết này sẽ xem xét cách kích hoạt xác thực SSH bằng cách sử dụng ứng dụng OATH-TOTP cùng với khóa SSH. Đăng nhập vào máy chủ của bạn thông qua SSH sau đó sẽ yêu cầu hai yếu tố trên hai kênh, do đó làm cho nó an toàn hơn một mật khẩu hoặc khóa SSH một mình. Ngoài ra, chúng tôi sẽ xem xét một số trường hợp sử dụng bổ sung cho MFA và một số mẹo và thủ thuật hữu ích.

Điều kiện tiên quyết

Để làm theo hướng dẫn này, bạn sẽ cần:

• Một máy chủ CentOS 7 có một người dùng không phải root sudo và khóa SSH, mà bạn có thể thiết lập bằng cách làm theo Hướng dẫn cài đặt máy chủ ban đầu này.
• Điện thoại thông minh hoặc máy tính bảng có cài đặt ứng dụng OATH-TOTP, như Google Authenticator (iOS, Android).

Bước 1 - Cài đặt PAM của Google

Trong bước này, chúng tôi sẽ cài đặt và định cấu hình PAM của Google.

PAM, viết tắt của Mô-đun xác thực có thể cắm được, là một cơ sở hạ tầng xác thực được sử dụng trên các hệ thống Linux để xác thực người dùng. Vì Google đã tạo ra một ứng dụng OATH-TOTP, họ cũng tạo một PAM để tạo ra các TOTP và hoàn toàn tương thích với bất kỳ ứng dụng OATH-TOTP nào, như Google Authenticator hoặc Authy.

Đầu tiên, chúng ta cần thêm repo EPEL (Gói bổ sung cho Enterprise Linux).

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

Tiếp theo, cài đặt PAM. Bạn có thể được nhắc chấp nhận khóa EPEL nếu đây là lần đầu tiên sử dụng repo. Sau khi được chấp nhận, bạn sẽ không được nhắc lại để chấp nhận khóa.

sudo yum install google-authenticator

Khi cài đặt PAM, chúng tôi sẽ sử dụng ứng dụng trợ giúp đi kèm với PAM để tạo khóa TOTP cho người dùng mà bạn muốn thêm yếu tố thứ hai vào. Khóa này được tạo trên cơ sở từng người dùng, không phải trên toàn hệ thống. Điều này có nghĩa là mọi người dùng muốn sử dụng ứng dụng auth TOTP sẽ cần phải đăng nhập và chạy ứng dụng trợ giúp để lấy khóa riêng của họ; bạn không thể chạy nó một lần để kích hoạt nó cho tất cả mọi người (nhưng có một số lời khuyên ở phần cuối của hướng dẫn này để thiết lập hoặc yêu cầu MFA cho nhiều người dùng).

Chạy ứng dụng khởi tạo.

google-authenticator

Sau khi bạn chạy lệnh, bạn sẽ được hỏi một vài câu hỏi. Người đầu tiên yêu cầu mã thông báo xác thực phải dựa trên thời gian.

OutputDo you want authentication tokens to be time-based (y/n) y

PAM này cho phép mã thông báo dựa trên thời gian hoặc dựa trên tuần tự. Sử dụng mã thông báo dựa trên tuần tự có nghĩa là mã bắt đầu tại một điểm nhất định và sau đó tăng mã sau mỗi lần sử dụng. Sử dụng mã thông báo dựa trên thời gian có nghĩa là mã thay đổi ngẫu nhiên sau một thời gian nhất định trôi qua. Chúng tôi sẽ gắn bó với thời gian vì đó là những ứng dụng như Google Authenticator dự đoán, vì vậy hãy trả lời y vì có.

Sau khi trả lời câu hỏi này, rất nhiều đầu ra sẽ cuộn qua, bao gồm cả mã QR lớn. Tại thời điểm này, hãy sử dụng ứng dụng trình xác thực của bạn trên điện thoại để quét mã QR hoặc nhập thủ công khóa bí mật. Nếu mã QR quá lớn để quét, bạn có thể sử dụng URL phía trên mã QR để nhận phiên bản nhỏ hơn. Khi được thêm, bạn sẽ thấy mã gồm sáu chữ số thay đổi sau mỗi 30 giây trong ứng dụng của bạn.

chú thích: Đảm bảo bạn ghi lại khóa bí mật, mã xác minh và mã khôi phục ở nơi an toàn, như trình quản lý mật khẩu. Mã khôi phục là cách duy nhất để lấy lại quyền truy cập nếu bạn, ví dụ: mất quyền truy cập vào ứng dụng TOTP của bạn.

Các câu hỏi còn lại cho PAM biết cách hoạt động. Chúng tôi sẽ đi qua từng cái một.

OutputDo you want me to update your "/home/sammy/.google_authenticator" file (y/n) y

Điều này viết chìa khóa và các tùy chọn cho .google_authenticator tập tin. Nếu bạn nói không, chương trình thoát và không có gì được viết, có nghĩa là người xác thực sẽ không hoạt động.

OutputDo you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

Bằng cách trả lời có ở đây, bạn đang ngăn chặn một cuộc tấn công phát lại bằng cách làm cho mỗi mã hết hạn ngay lập tức sau khi sử dụng. Điều này ngăn cản kẻ tấn công bắt giữ mã bạn vừa sử dụng và đăng nhập bằng mã đó.

OutputBy default, tokens are good for 30 seconds. In order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with
poor time synchronization, you can increase the window from its default
size of +-1min (window size of 3) to about +-4min (window size of 17 acceptable tokens). 
Do you want to do so? (y/n) n

Trả lời có ở đây cho phép lên đến 8 mã hợp lệ trong một cửa sổ bốn phút di chuyển. Bằng cách trả lời không, bạn giới hạn nó thành 3 mã hợp lệ trong một cửa sổ cuộn 1:30 phút. Trừ khi bạn tìm thấy vấn đề với cửa sổ 1:30 phút, trả lời không là lựa chọn an toàn hơn.

OutputIf the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

Giới hạn tốc độ có nghĩa là kẻ tấn công từ xa chỉ có thể thử một số dự đoán nhất định trước khi bị chặn. Nếu trước đó bạn chưa định cấu hình giới hạn tốc độ trực tiếp vào SSH, làm như vậy bây giờ là một kỹ thuật làm cứng tuyệt vời.

chú thích: Khi bạn hoàn tất thiết lập này, nếu bạn muốn sao lưu khóa bí mật của mình, bạn có thể sao chép ~/.google-authenticator tập tin vào một vị trí đáng tin cậy. Từ đó, bạn có thể triển khai nó trên các hệ thống bổ sung hoặc triển khai lại nó sau khi sao lưu.

Bây giờ PAM của Google đã được cài đặt và cấu hình, bước tiếp theo là cấu hình SSH để sử dụng khóa TOTP của bạn. Chúng ta sẽ nói với SSH về PAM và sau đó cấu hình SSH để sử dụng nó.

Bước 2 - Cấu hình OpenSSH

Bởi vì chúng tôi sẽ thực hiện các thay đổi SSH qua SSH, điều quan trọng là không bao giờ đóng kết nối SSH ban đầu của bạn. Thay vào đó, hãy mở một phiên SSH thứ hai để thực hiện kiểm tra. Điều này là để tránh tự khóa máy chủ của bạn nếu có lỗi trong cấu hình SSH của bạn. Khi mọi thứ hoạt động, bạn có thể đóng một cách an toàn bất kỳ phiên nào.

Để bắt đầu, chúng tôi sẽ chỉnh sửa sshd tập tin cấu hình. Ở đây, chúng tôi đang sử dụng nano, không được cài đặt trên CentOS theo mặc định. Bạn có thể cài đặt nó bằng sudo yum install nanohoặc sử dụng trình soạn thảo văn bản thay thế yêu thích của bạn.

sudo nano /etc/pam.d/sshd

Thêm dòng sau vào cuối tệp.

/etc/pam.d/sshd

. . .
# Used with polkit to reauthorize users in remote sessions
-session   optional     pam_reauthorize.so prepare
auth required pam_google_authenticator.so nullok

Các nullok từ ở cuối dòng cuối cùng cho PAM biết rằng phương thức xác thực này là tùy chọn. Điều này cho phép người dùng không có mã thông báo OATH-TOTP để vẫn đăng nhập bằng khóa SSH của họ. Khi tất cả người dùng có mã thông báo OATH-TOTP, bạn có thể xóa nullok từ dòng này để bắt buộc phải có MFA.

Lưu và đóng tập tin.

Tiếp theo, chúng tôi sẽ định cấu hình SSH để hỗ trợ loại xác thực này. Mở tệp cấu hình SSH để chỉnh sửa.

sudo nano /etc/ssh/sshd_config

Tìm kiếm ChallengeResponseAuthentication dòng. Nhận xét ra no dòng và bỏ ghi chú no hàng.

/etc/ssh/sshd_config

. . .
# Change to no to disable s/key passwords
ChallengeResponseAuthentication yes
#ChallengeResponseAuthentication no
. . .

Lưu và đóng tệp, sau đó khởi động lại SSH để tải lại các tệp cấu hình. Khởi động lại sshd dịch vụ sẽ không đóng các kết nối mở, vì vậy bạn sẽ không mạo hiểm tự khóa mình bằng lệnh này.

sudo systemctl restart sshd.service

Để kiểm tra xem mọi thứ đã hoạt động chưa, hãy mở một thiết bị đầu cuối khác và thử đăng nhập qua SSH. Nếu trước đây bạn đã tạo khóa SSH và đang sử dụng khóa đó, bạn sẽ nhận thấy rằng bạn không phải nhập mật khẩu của người dùng hoặc mã xác minh MFA. Điều này là do khóa SSH ghi đè tất cả các tùy chọn xác thực khác theo mặc định. Nếu không, bạn sẽ nhận được một mật khẩu và mã xác nhận nhanh chóng.

Nếu bạn muốn đảm bảo những gì bạn đã làm cho đến nay hoạt động, trong phiên SSH mở của bạn, hãy điều hướng đến ~/.ssh/ và đổi tên tệp authorized_keys, tạm thời và mở một phiên mới và đăng nhập bằng mật khẩu và mã xác minh của chúng tôi.

cd ~/.ssh

mv authorized_keys authorized_keys.bak

Khi bạn đã xác minh rằng mã thông báo TOTP của bạn hoạt động đổi tên tệp 'authorized_keys.bak' trở lại thành nó.

mv authorized_keys.bak authorized_keys

Tiếp theo, chúng ta cần kích hoạt một khóa SSH là một yếu tố và mã xác minh là một thứ hai và cho SSH biết các yếu tố nào để sử dụng và ngăn chặn khóa SSH ghi đè tất cả các loại khác.

Bước 3 - Làm cho SSH nhận thức được về MFA

Mở lại sshd tập tin cấu hình.

sudo nano /etc/ssh/sshd_config

Thêm dòng sau vào cuối tệp. Điều này cho SSH biết phương thức xác thực nào là bắt buộc. Dòng này cho SSH biết chúng ta cần khóa SSH và mật khẩu hoặc mã xác minh (hoặc cả ba).

/etc/ssh/sshd_config

. . .
# Added by DigitalOcean build process
ClientAliveInterval 120
ClientAliveCountMax 2
AuthenticationMethods publickey,password publickey,keyboard-interactive

Lưu và đóng tập tin.

Tiếp theo, mở PAM sshd lại tập tin cấu hình.

sudo nano /etc/pam.d/sshd

Tìm dòng auth substack password-auth phía trên cùng của tệp. Nhận xét bằng cách thêm # là ký tự đầu tiên trên dòng. Điều này cho PAM không nhắc nhập mật khẩu.

/etc/pam.d/sshd

. . .
#auth       substack     password-auth
. . .

Lưu và đóng tệp, sau đó khởi động lại SSH.

sudo systemctl restart sshd.service

Bây giờ hãy thử đăng nhập lại vào máy chủ với một phiên khác. Không giống như lần trước, SSH nên yêu cầu mã xác minh của bạn. Khi đăng nhập, bạn sẽ được đăng nhập. Mặc dù bạn không thấy bất kỳ dấu hiệu nào cho thấy khóa SSH của bạn đã được sử dụng, nỗ lực đăng nhập của bạn đã sử dụng hai yếu tố. Nếu bạn muốn xác minh, bạn có thể thêm -v (cho tiết) sau lệnh SSH:

Example SSH output. . .
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammy/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
Authenticated with partial success.
debug1: Authentications that can continue: keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Verification code:

Đến cuối đầu ra, bạn sẽ thấy nơi SSH sử dụng khóa SSH của bạn và sau đó yêu cầu mã xác minh. Bây giờ bạn có thể đăng nhập qua SSH bằng khóa SSH và mật khẩu một lần. Nếu bạn muốn thực thi cả ba loại xác thực, bạn có thể làm theo bước tiếp theo.

Bước 4 - Thêm yếu tố thứ ba (Tùy chọn)

Ở Bước 3, chúng tôi đã liệt kê các loại xác thực được phê duyệt trong sshd_config tập tin:

1. publickey (Khóa SSH)
2. password publickey (mật khẩu)
3. keyboard-interactive (mã xác nhận)

Mặc dù chúng tôi liệt kê ba yếu tố khác nhau, với các tùy chọn mà chúng tôi đã chọn cho đến nay, họ chỉ cho phép khóa SSH và mã xác minh. Nếu bạn muốn có tất cả ba yếu tố (khóa SSH, mật khẩu và mã xác minh), một thay đổi nhanh sẽ cho phép cả ba yếu tố.

Mở PAM sshd tập tin cấu hình.

sudo nano /etc/pam.d/sshd

Tìm dòng bạn đã nhận xét trước đây, #auth substack password-authvà bỏ ghi chú dòng bằng cách xóa # tính cách. Lưu và đóng tập tin. Bây giờ một lần nữa, khởi động lại SSH.

sudo systemctl restart sshd.service

Bằng cách bật tùy chọn auth substack password-auth, PAM bây giờ sẽ nhắc nhập mật khẩu ngoài việc kiểm tra khóa SSH và yêu cầu mã xác minh mà chúng tôi đã làm trước đó. Bây giờ chúng ta có thể sử dụng một cái gì đó chúng ta biết (mật khẩu) và hai loại khác nhau của những thứ chúng tôi có (khóa SSH và mã xác minh) trên hai kênh khác nhau.

Cho đến nay, bài viết này đã vạch ra cách bật MFA bằng khóa SSH và mật khẩu một lần dựa trên thời gian. Nếu đây là tất cả những gì bạn cần, bạn có thể kết thúc ở đây. Tuy nhiên, đây không phải là cách duy nhất để thực hiện xác thực đa yếu tố. Dưới đây là một vài cách khác để sử dụng mô-đun PAM này để xác thực đa yếu tố và một số mẹo và thủ thuật để khôi phục, sử dụng tự động và hơn thế nữa.

Mẹo 1 - Phục hồi quyền truy cập

Như với bất kỳ hệ thống nào mà bạn cứng và bảo mật, bạn sẽ chịu trách nhiệm quản lý bảo mật đó. Trong trường hợp này, điều đó có nghĩa là không mất khóa SSH hoặc khóa bí mật TOTP của bạn và đảm bảo bạn có quyền truy cập vào ứng dụng TOTP của mình. Tuy nhiên, đôi khi mọi thứ xảy ra và bạn có thể mất quyền kiểm soát các khóa hoặc ứng dụng bạn cần tham gia.

Mất khóa SSH hoặc khóa bí mật TOTP

Nếu bạn mất khóa SSH hoặc khóa bí mật TOTP, việc khôi phục có thể được chia thành một vài bước. Đầu tiên là quay trở lại mà không biết mã xác minh và thứ hai là tìm khóa bí mật hoặc tạo lại khóa để đăng nhập MFA bình thường.

Để vào sau khi mất khóa bí mật tạo mã xác minh trên một giọt kỹ thuật số, bạn có thể chỉ đơn giản là sử dụng bảng điều khiển ảo từ trang tổng quan của bạn để đăng nhập bằng tên người dùng và mật khẩu của bạn.

Nếu không, bạn sẽ cần một người dùng quản trị có quyền truy cập sudo; đảm bảo không bật MFA cho người dùng này nhưng chỉ sử dụng khóa SSH. Nếu bạn hoặc người dùng khác mất khóa bí mật của họ và không thể đăng nhập, thì người dùng quản trị có thể đăng nhập và giúp khôi phục hoặc tạo lại khóa cho bất kỳ người dùng nào sử dụng sudo.

Khi bạn đã đăng nhập, có hai cách để giúp bạn có được bí mật TOTP:

1. Khôi phục khóa hiện có
2. Tạo khóa mới

Trong thư mục chính của mỗi người dùng, khóa bí mật và cài đặt Google Authenticator được lưu trong ~/.google-authenticator. Dòng đầu tiên của tệp này là khóa bí mật. Một cách nhanh chóng để lấy khóa là thực hiện lệnh sau, hiển thị dòng đầu tiên của google-authenticator tệp (tức là khóa bí mật). Sau đó, lấy khóa bí mật đó và nhập thủ công vào ứng dụng TOTP.

head -n 1 /home/sammy/.google_authenticator

Nếu có lý do không sử dụng khóa hiện tại (ví dụ: không thể dễ dàng chia sẻ khóa bí mật với người dùng bị ảnh hưởng một cách an toàn hoặc khóa hiện có bị xâm phạm), bạn có thể xóa ~/.google-authenticator tệp hoàn toàn. Điều này sẽ cho phép người dùng đăng nhập lại chỉ bằng một yếu tố duy nhất, giả sử bạn chưa thực thi MFA bằng cách xóa 'nullok' trong tệp '/etc/pam.d/sshd'. Sau đó, họ có thể chạy google-authenticator để tạo khóa mới.

Mất quyền truy cập vào ứng dụng TOTP

Nếu bạn cần đăng nhập vào máy chủ của mình nhưng không có quyền truy cập vào ứng dụng TOTP để nhận mã xác minh, bạn vẫn có thể đăng nhập bằng mã khôi phục được hiển thị khi bạn tạo khóa bí mật lần đầu tiên. Lưu ý rằng các mã khôi phục này chỉ sử dụng một lần. Khi một người được sử dụng để đăng nhập, nó không thể được sử dụng như một mã xác minh một lần nữa.

Mẹo 2 - Thay đổi cài đặt xác thực

Nếu bạn muốn thay đổi cài đặt MFA của mình sau cấu hình ban đầu, thay vì tạo cấu hình mới với cài đặt được cập nhật, bạn chỉ có thể chỉnh sửa ~/.google-authenticator tập tin. Tệp này được trình bày theo cách sau:

.google-authenticator layout

<secret key>
<options>
<recovery codes>

Các tùy chọn được đặt trong tệp này có một dòng trong phần tùy chọn; nếu bạn trả lời "không" cho một tùy chọn cụ thể trong quá trình thiết lập ban đầu, dòng tương ứng sẽ bị loại trừ khỏi tệp.

Dưới đây là những thay đổi bạn có thể thực hiện đối với tệp này:

• Để bật mã tuần tự thay vì mã dựa trên thời gian, hãy thay đổi dòng " TOTP_AUTH đến " HOTP_COUNTER 1.
• Để cho phép sử dụng nhiều mã đơn, hãy xóa dòng " DISALLOW_REUSE.
• Để mở rộng cửa sổ hết hạn mã thành 4 phút, hãy thêm dòng " WINDOW_SIZE 17.
• Để vô hiệu hóa nhiều lần đăng nhập không thành công (giới hạn tốc độ), hãy xóa dòng " RATE_LIMIT 3 30.
• Để thay đổi ngưỡng giới hạn tốc độ, hãy tìm dòng " RATE_LIMIT 3 30 và điều chỉnh các con số. Các 3 trong bản gốc cho biết số lần thử trong một khoảng thời gian và 30 cho biết khoảng thời gian tính bằng giây.
• Để vô hiệu hóa việc sử dụng mã khôi phục, hãy xóa năm mã gồm 8 chữ số ở cuối tệp.

Mẹo 3 - Tránh MFA cho một số tài khoản

Có thể có một tình huống trong đó một người dùng hoặc một vài tài khoản dịch vụ (tức là tài khoản được ứng dụng sử dụng, không phải con người) cần quyền truy cập SSH mà không bật MFA. Ví dụ, một số ứng dụng sử dụng SSH, giống như một số máy khách FTP, có thể không hỗ trợ MFA. Nếu ứng dụng không có cách yêu cầu mã xác minh, yêu cầu có thể bị kẹt cho đến khi kết nối SSH hết thời gian chờ.

Miễn là một vài tùy chọn trong /etc/pam.d/sshd được đặt chính xác, bạn có thể kiểm soát những yếu tố nào được sử dụng trên cơ sở từng người dùng.

Để cho phép MFA đối với một số tài khoản và khóa SSH chỉ dành cho những người khác, hãy đảm bảo các cài đặt sau trong /etc/pam.d/sshd đang hoạt động.

/etc/pam.d/sshd

#%PAM-1.0
auth       required     pam_sepermit.so
#auth       substack     password-auth

. . .

# Used with polkit to reauthorize users in remote sessions
-session   optional     pam_reauthorize.so prepare
auth       required      pam_google_authenticator.so nullok

Đây, auth substack password-auth được nhận xét vì mật khẩu cần phải bị vô hiệu hóa. MFA không thể bị ép buộc nếu một số tài khoản có nghĩa là bị MFA bị vô hiệu hóa, do đó, hãy thoát khỏi nullok tùy chọn trên dòng cuối cùng.

Sau khi thiết lập cấu hình này, chỉ cần chạy google-authenticator như bất kỳ người dùng nào cần MFA và không chạy nó cho người dùng chỉ sử dụng khóa SSH.

Mẹo 4 - Tự động thiết lập với quản lý cấu hình

Nhiều quản trị viên hệ thống sử dụng công cụ quản lý cấu hình, như Puppet, Chef hoặc Ansible, để quản lý hệ thống của họ. Nếu bạn muốn sử dụng một hệ thống như thế này để cài đặt thiết lập khóa bí mật khi tài khoản của người dùng mới được tạo, có một phương pháp để thực hiện điều đó.

google-authenticator hỗ trợ các công tắc dòng lệnh để đặt tất cả các tùy chọn trong một lệnh không tương tác. Để xem tất cả các tùy chọn, bạn có thể nhập google-authenticator --help. Dưới đây là lệnh sẽ thiết lập mọi thứ như được nêu trong Bước 1:

google-authenticator -t -d -f -r 3 -R 30 -W

Câu trả lời này trả lời tất cả các câu hỏi chúng tôi đã trả lời theo cách thủ công, lưu nó vào một tệp và sau đó xuất ra khóa bí mật, mã QR và mã khôi phục. (Nếu bạn thêm cờ -q, thì sẽ không có bất kỳ đầu ra nào.) Nếu bạn sử dụng lệnh này theo kiểu tự động, hãy đảm bảo nắm bắt khóa bí mật và / hoặc mã khôi phục và cung cấp chúng cho người dùng.

Mẹo 5 - Bắt buộc MFA cho tất cả người dùng

Nếu bạn muốn ép buộc MFA cho tất cả người dùng ngay cả trong lần đăng nhập đầu tiên hoặc nếu bạn không muốn dựa vào người dùng của mình để tạo khóa riêng, thì có một cách dễ dàng để xử lý việc này. Bạn có thể sử dụng một cách đơn giản .google-authenticator tệp cho từng người dùng vì không có dữ liệu do người dùng cụ thể lưu trữ trong tệp.

Để thực hiện việc này, sau khi tệp cấu hình được tạo ban đầu, một người dùng đặc quyền cần phải sao chép tệp vào thư mục gốc của mọi thư mục chính và thay đổi quyền của nó đối với người dùng thích hợp. Bạn cũng có thể sao chép tệp vào /etc/skel/ Do đó, nó sẽ tự động được sao chép sang thư mục chính của người dùng mới khi tạo.

Cảnh báo: Đây có thể là một nguy cơ bảo mật vì mọi người đều chia sẻ cùng một yếu tố thứ hai. Điều này có nghĩa rằng nếu nó bị rò rỉ, nó giống như mọi người dùng chỉ có một yếu tố. Cân nhắc điều này nếu bạn muốn sử dụng phương pháp này.

Một phương pháp khác để buộc tạo khóa bí mật của người dùng là sử dụng tập lệnh bash:

1. Tạo một mã thông báo TOTP,
2. Nhắc họ tải xuống ứng dụng Google Authenticator và quét mã QR sẽ được hiển thị và
3. Chạy google-authenticator ứng dụng cho họ sau khi kiểm tra xem .google-authenticator Tập tin đã tồn tại.

Để đảm bảo tập lệnh chạy khi người dùng đăng nhập, bạn có thể đặt tên .bash_login và đặt nó vào thư mục gốc của thư mục chính của họ.

Phần kết luận

Điều đó nói rằng, bằng cách có hai yếu tố (một khóa SSH + MFA token) trên hai kênh (máy tính của bạn + điện thoại của bạn), bạn đã làm cho nó rất khó khăn cho một đại lý bên ngoài để brute lực lượng theo cách của họ vào máy của bạn thông qua SSH và tăng lên rất nhiều bảo mật máy của bạn.