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

Đối với vấn đề bảo mật của server thì xác thực đa yếu tố (MFA – Multi-Factor Authentication) là phương pháp bảo vệ hiệu quả giúp giảm thiểu nguy cơ bị tấn công bởi kẻ xấu. Trong bài viết này, Vietnix sẽ hướng dẫn chi tiết đến bạn cách thiết lập xác thực đa yếu tố (MFA) cho SSH trên CentOS 7.

Yêu cầu để thiết lập xác thực đa yếu tố (MFA) cho SSH trên CentOS 7

Để có thể cài đặt xác thực đa yếu tố (MFA) cho SSH trên hệ điều hành CentOS 7, người dùng cần đáp ứng những yêu cầu sau:

• Một máy chủ CentOS 7 với người dùng non-root có quyền sudo và SSH key.
• Smartphone hoặc thiết bị di động đã cài đặt ứng dụng OATH-TOTP.

4 bước cài đặt xác thực đa yếu tố cho SSH trên CentOS 7

Nếu bạn đang sử dụng VPS thì việc thiết lập xác thực đa yếu tố (MFA) cho SSH trên CentOS 7 là một trong những cách hiệu quả để bảo vệ hệ thống của bạn trước các mối đe dọa an ninh. Tuy nhiên, để đảm bảo tối đa an toàn cho dữ liệu và ứng dụng của bạn, việc sử dụng dịch vụ VPS là một lựa chọn hoàn hảo.

Với dịch vụ thuê VPS Việt Nam tốc độ cao của Vietnix, bạn sẽ được trải nghiệm một môi trường hoàn toàn riêng biệt, được trang bị tài nguyên và tính năng hiện đại nhằm đáp ứng mọi nhu cầu của bạn. Vietnix còn mang đến các giải pháp bảo mật chuyên nghiệp, bao gồm Firewall, hệ thống backup dữ liệu định kỳ và giám sát, cùng với hạ tầng chống DDoS chuyên nghiệp, đảm bảo an toàn cho hệ thống của bạn trước những mối đe dọa tấn công.

Liên hệ ngay với Vietnix để được tư vấn chi tiết.

Quá trình thiết lập MFA cho SSH trên CentOS 7 được thực hiện bằng cách sử dụng SSH key và ứng dụng xác thực OATH-TOTP như Google Authenticator. Cụ thể: 

Bước 1: Cài đặt Google PAM 

Trước hết, bạn cần cài đặt và cấu hình Google PAM (Pluggable Authentication Module). PAM là một cơ sở hạ tầng xác thực được sử dụng trên hệ điều hành Linux với mục đích xác thực người dùng. Bởi vì ứng dụng OATH-TOTP được tạo ra bởi Google, thế nên nền tảng này cũng đã cung cấp một PAM để tạo ra TOTP có thể tương thích  hoàn toàn với bất kỳ ứng dụng OATH-TOTH, chẳng hạn Google Authenticator hoặc Authy. 

Đầu tiên bạn thêm repo EPEL (Extra Packages for Enterprise Linux) với câu lệnh:

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

Sau đó, cài đặt PAM với câu lệnh bên dưới. (Lưu ý: Trong lần sử dụng repo đầu tiên, người dùng sẽ nhận thông báo nhắc nhở chấp nhận EPEL key được gửi từ hệ thống, khi đã xác nhận thì hệ thống sẽ không nhắc lại ở những lần sử dụng tiếp theo). 

sudo yum install google-authenticator

PAM khi đã được cài đặt sẽ cho phép người dùng sử dụng thêm một ứng dụng hỗ trợ đi kèm để cung cấp một TOTP key cho user mình muốn thêm yếu tố xác thực thứ 2. Key này được tạo ra dựa trên cơ sở user-by-user mà không phải trên system-wide. Đồng nghĩa với mỗi user nếu muốn sử dụng ứng dụng xác thực TOTP sẽ cần phải đăng nhập và khởi chạy ứng dụng trợ giúp để lấy khóa của riêng họ. 

Một lưu ý là nếu chỉ khởi chạy ứng dụng một lần sẽ không thể giúp người dùng kích hoạt cho tất cả user khác. Tuy nhiên, vẫn có một số mẹo được chia sẻ ở phần cuối bài viết để thiết lập hoặc yêu cầu MFA cho nhiều người dùng. 

Khởi chạy ứng dụng:

google-authenticator

Sau khi câu lệnh được khởi chạy, hệ thống sẽ gửi một số câu hỏi đến người dùng. Trong đó, câu đầu tiên sẽ hỏi về các token xác thực có dựa trên thời gian hay không. Cụ thể: 

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

PAM cho phép người dùng sử dụng các token dựa trên thời gian hoặc theo trình tự. Trong đó, nếu sử dụng các token dựa theo trình tự, đồng nghĩa rằng, đoạn mã bắt đầu từ một điểm cụ thể được xác định, sau đó mã sẽ gia tăng sau mỗi lần sử dụng. Với token theo thời gian, mã sẽ thay đổi ngẫu nhiên sau một khoảng thời gian nhất định. 

Bài viết này sử dụng token dựa trên thời gian để đáp ứng mong đợi của các ứng dụng như Google Authenticator. Vì thế, người dùng sẽ phản hồi cho câu hỏi trên với đáp án là y để đồng ý lựa chọn. 

Sau khi trả lời câu hỏi này, nhiều Output sẽ được cuộn qua, bao gồm một mã QR lớn. Đến đây, người dùng sử dụng ứng dụng xác thực trên điện thoại để quét mã QR hoặc nhập tay secret key. Trường hợp mã QR quá lớn để quét, người dùng có thể thông qua URL nằm trên mã QR để lấy phiên bản mã nhỏ hơn. Sau khi quét thành công, ứng dụng sẽ hiển thị một mã gồm 6 chữ số. 

Đối với các câu hỏi còn lại sẽ cung cấp cho PAM biết về cách thức hoạt động. Bạn trả lời lần lượt như sau: 

Output
Do you want me to update your "/home/vietnix/.google_authenticator" file (y/n)

Ở câu hỏi này, key và các tùy chọn sẽ được ghi vào file .google_authenticator. Do đó, nếu chọn “no”, chương trình sẽ thoát ra và không có bất cứ thông tin nào được ghi vào file. Và ứng dụng xác thực sẽ không hoạt động. 

Output
Do 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 chọn “yes”, các mã xác thực chỉ có hiệu lực trong 1 lần sử dụng và sẽ hết hạn sau khi được xác thực. Điều này ngăn những đối tượng xấu sử dụng lại mã xác thực đã dùng để đăng nhập vào tài khoản.

Output
By 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

Nếu bạn chọn “yes” cho câu hỏi này, hệ thống sẽ cho phép tối đa 8 mã xác thực hợp lệ trong 4 phút liên tục. Còn nếu trả lời “no”, số mã xác thực hợp lệ sẽ giới hạn lại còn 3 mã trong 1 phút 30 giây liên tục. Vì vậy, trừ khi bạn gặp vấn đề kỹ thuật khi chọn “no”, thì đây là lựa chọn tốt cho người dùng. 

Output
If 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

Trong câu hỏi này, rate-limiting biểu thị rằng, kẻ tấn công từ xa chỉ có một vài lần thử đoán mật khẩu trước khi bị chặn. Do đó, nếu người dùng chưa từng cấu hình trực tiếp rate limiting vào SSH trước đó thì giờ đây, việc kích hoạt rate limiting là một kỹ thuật tăng cường bảo mật. 

Lưu ý: Sau khi hoàn tất cài đặt, nếu người dùng muốn backup secret key, có thể sao chép file ~/.google-authenticator đến một vị trí khác đáng tin cậy. Bằng cách này, người dùng có thể triển khai secret key trên các hệ thống bổ sung hoặc triển khai lại sau khi backup. 

Giờ đây, khi đã cài đặt và cấu hình Google PAM, người dùng sẽ sang bước tiếp theo – cấu hình SSH để sử dụng TOTP key của mình. 

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

Ở bước này, người dùng cần thực hiện chỉnh sửa SSH thông qua SSH tunnel. Đến đây bạn mở một phiên bản SSH thứ 2 để kiểm tra các thay đổi, thay vì đóng kết nối SSH ban đầu. Điều này giúp bạn tránh tình trạng tự khóa mình khỏi máy chủ nếu có lỗi xảy ra trong quá trình cấu hình SSH. 

Khi chắc chắn mọi thứ của phiên thay đổi đã hoạt động ổn định, bạn có thể đóng lại bất kỳ section SSH nào. 

Đầu tiên, bạn chỉnh sửa file configuration sshd. Ở đây, bạn sử dụng nano text editor, nhưng trình editor nano không có sẵn trên CentOS mà phải cài thủ công bằng lệnh sau:

sudo nano /etc/pam.d/sshd

Sau đó, thêm dòng lệnh sau vào dòng cuối cùng của file. 

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

Trong command-line, từ nullok ở dòng cuối cùng biểu thị 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ó OATH-TOTP token vẫn có thể đăng nhập bằng SSH key của mình. Sau khi tất cả người dùng đều có OATH-TOTP token thì có thể xóa nullok khỏi dòng để buộc MFA được áp dụng. 

Tiếp đó, thực hiện lưu và đóng file. 

Để hỗ trợ cho phương thức xác thực này, người dùng sẽ phải cấu hình SSH bằng cách mở file configuration để điều chỉnh:

sudo nano /etc/ssh/sshd_config

Lúc này, trên màn hình, người dùng tìm kiếm các dòng ChallengeResponseAuthentication. Sau đó, chú thích dòng “no” và bỏ chú thích dòng “yes”. 

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

Lưu và đóng file sau khi hoàn tất, tiếp theo khởi chạy lại để các thay đổi có hiệu lực. Việc tải lại dịch vụ sshd sẽ không đóng các kết nối đang hoạt động. Do đó, người dùng sẽ tránh được các rủi ro khi tự khóa mình bằng câu lệnh này:

sudo systemctl restart sshd.service

Để kiểm tra mọi thứ có đang hoạt động hay không, người dùng có thể mở cửa sổ dòng lệnh khác và thử đăng nhập qua SSH. Nếu trước đó người dùng đã tạo và sử dụng SSH key cho đến hiện tại thì không cần phải nhập mật khẩu hoặc mã xác minh MFA.

Do SSH key theo mặc định sẽ ghi đè lên tất cả các tùy chọn xác thực khác. Nếu không, hệ thống sẽ gửi thông báo nhắc nhở đến người dùng về mật khẩu và mã xác minh. 

Trường hợp người dùng muốn đảm bảo những cài đặt đã thiết lập đến nay vẫn hoạt động thì trong phiên SSH đang mở hiện tại, thực hiện điều hướng đến  ~/.ssh/ và đổi tên file authorized_keys. Sau đó, mở một phiên mới và sử dụng mật khẩu cùng mã xác minh của mình để đăng nhập.  

cd ~/.ssh
mv authorized_keys authorized_keys.bak

Sau khi người dùng đã xác minh thành công TOTP token của mình hoạt động, hãy đổi tên file authorized_keys.bak về tên gốc bằng cách sử dụng lệnh:

mv authorized_keys.bak authorized_keys

Tiếp theo, kích hoạt SSH key để giữ vai trò như một yếu tố và sử dụng mã xác minh như một yếu tố thứ 2. Đồng thời, cũng cho SSH biết các yếu tố nào được sử dụng và ngăn cản khóa SSH ghi đè lên tất cả các loại xác thực khác.

Bước 3: Thiết lập cho SSH nhận diện MFA

Mở lại file configuration sshd với lệnh:

sudo nano /etc/ssh/sshd_config

Sau đó, thêm dòng lệnh bên dưới vào cuối file để cho SSH biết các phương thức xác thực nào được yêu cầu. Dòng này cho biết SSH cần một SSH key và mật khẩu hoặc mã xác minh (hoặc cả 3). 

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

Khi đã thêm xong dòng lệnh, người dùng lưu và đóng lại file. 

Mở lại file configuration PAM sshd. 

sudo nano /etc/pam.d/sshd

Trong file sshd, tìm kiếm dòng auth substack password-auth nằm ở phía trên cùng và nhận xét bằng cách thêm ký tự # ở đầu dòng để thông báo cho PAM không nhắc đến mật khẩu khi đăng nhập. 

. . .
#auth       substack     password-auth
. . .
Sau đó lưu và đóng file rồi khởi chạy lại SSH. 
sudo systemctl restart sshd.service

Giờ đây, người dùng có thể thử đăng nhập vào máy chủ bằng một phiên đăng nhập khác. Khác với những lần trước đó, lần này SSH sẽ yêu cầu người dùng về mã xác thực và sẽ được đăng nhập thành công sau khi nhập mã. 

Mặc dù không hiển thị bất kỳ chỉ dẫn nào cho thấy SSH key của người dùng được sử dụng, nhưng thực tế rằng, lần đăng nhập này đã sử dụng xác thực 2 yếu tố. Nếu người dùng muốn xác minh điều này thì có thể thêm tùy chọn -v (cho verbose) sau lệnh SSH: 

Example SSH output\
. . .
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/vietnix/.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:

Ở cuối Output, tại nơi SSH sử dụng SSH key của mình và yêu cầu mã xác minh. Lúc này, người dùng có thể thông qua SSH với SSH key và mật khẩu dùng 1 lần để đăng nhập vào web server. Mặt khác, nếu người dùng thực thi cả 3 loại yếu tố xác thực, có thể thực hiện theo hướng dẫn ở bước 4. 

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

Ở bước trên, thông qua file sshd_config đã có các loại phương thức được liệt kê: 

1. publickey (SSH key).
2. password publickey (mật khẩu).
3. keyboard-interactive (mã xác thực).

Mặc dù có 3 yếu tố khác nhau được liệt kê, nhưng với các tùy chọn được quyết định chỉ có 2 phương thức là SSH key và mã xác minh được phê duyệt. Do đó, nếu người dùng muốn kích hoạt cả 3 yếu tố (SSH key, mật khẩu và mã xác minh) cần thực hiện một tùy chỉnh nhanh chóng. Cụ thể:

Mở file configuration PAM sshd.

sudo nano /etc/pam.d/sshd

Tiếp đến, định vị dòng lệnh người dùng đã nhận xét trước đó, #auth substack password-auth, và bỏ nhận xét bằng cách xóa ký tự #. Sau đó, lưu và đóng file và khởi động SSH lại một nữa. 

sudo systemctl restart sshd.service

Bằng cách sử dụng kích hoạt tùy chọn auth substack password-auth, PAM sẽ yêu cầu mật khẩu bên cạnh việc kiểm tra SSH key và yêu cầu mã xác thực đã được người dùng tạo ra trước đó. Giờ đây, người dùng có thể sử dụng mật khẩu của mình và 2 yếu tố khác (SSH key và mã xác minh) qua 2 kênh khác nhau. 

Bên trên, là cách kích hoạt MFA dựa vào SSH key và mật khẩu đăng nhập 1 lần dựa trên thời gian. Nếu những thông tin này đã đủ để đáp ứng nhu cầu cần tìm thì người dùng có thể kết thúc quá trình tham khảo tại đâ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 module PAM này để xác thực đa yếu tố cùng một số mẹo và thủ thuật để khôi phục, sử dụng tự động,…

Tip 1: Khôi phục quyền truy cập

Dưới đây là hướng dẫn xử lý khi có sự cố xảy ra khiến người dùng mất quyền kiểm soát các key hoặc ứng dụng cần để truy cập.    

Mất SSH key hoặc TOTP secret key

Trường hợp người dùng mất SSH key hoặc TOTP secret key, việc khôi phục có thể được chia thành vài bước như sau: 

• Quay lại và không biết mã xác minh.
• Tìm secret key hoặc tạo lại secret key mới để đăng nhập bằng MFA. 

Trong trường hợp người dùng bị mất secret key tạo mã xác minh trên VPS của Vietnix, bạn có thể gửi yêu cầu hỗ trợ đến Vietnix để được xử lý nhanh chóng thông qua các kênh như: Livechat, Ticket, Hotline, Telegram, Zalo,…

Hoặc người dùng cần một administrative user có quyền sudo và để đảm bảo không kích hoạt MFA cho tài khoản này mà chỉ sử dụng SSH key. Trong trường hợp người dùng làm mất secret key và không thể đăng nhập, administrative user có thể đăng nhập và hỗ trợ khôi phục hoặc tạo lại key cho user có sử dụng sudo. 

Có 2 cách giúp người dùng sau khi đăng nhập lấy được TOTP secret key: 

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

Trong thư mục home của mỗi người dùng, secret key và cài đặt Google Authenticator được lưu trong ~/.google-authenticator. Tại đây, dòng đầu tiên sẽ là một secret key.

Để lấy được key, cách nhanh nhất là thực hiện lệnh sau, lệnh này sẽ hiển thị dòng đầu tiên của file google-authenticator (tức secret key). Người dùng lấy secret key đó rồi nhập thủ công vào ứng dụng TOTP. 

head -n 1 /home/vietnix/.google_authenticator

Nếu không thể chia sẻ secret key hiện tại với người dùng một cách an toàn hoặc key bị lộ thì có thể thực hiện xóa file ~/.google-authenticator. Đ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ố, miễn là người dùng chưa bắt buộc sử dụng MFA bằng cách xóa ‘nullok’ trong file /etc/pam.d/sshd. Sau đó, chạy google-authenticator để tạo key mới. 

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

Nếu người dùng cần đăng nhập vào server của mình nhưng không thể truy cập được ứng dụng TOTP để lấy xác minh thì vẫn có thể đăng nhập thông qua các mã khôi phục đã hiển thị khi người dùng lần đầu khởi tạo secret key. 

Tip 2: Tùy chỉnh cài đặt xác thực

Nếu muốn thay đổi cài đặt MFA sau khi hoàn thành thiết lập ban đầu, thay vì tạo ra một cấu hình mới với các thiết lập được cập nhật thì người dùng có thể tùy chỉnh với file ~/.google-authenticator. File này được trình bày như sau:

<secret key>
<options>
<recovery codes>

Trong phần Option của file, mỗi tùy chọn sẽ có một dòng tương ứng. Nếu người dùng trả lời “no” 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ẽ không hiển thị trong file. 

Dưới đây là những thay đổi mà người dùng có thể thực hiện trên file:

• Để kích hoạt sequential codes thay vì time based codes, người dùng có thể thay đổi dòng “ TOTP_AUTH” thành “ HOTP_COUNTER 1”.
• Để có thể sử dụng một lần được nhiều lần, người dùng xóa dòng “ DISALLOW_REUSE”. 
• Để kéo dài thời hạn mã xác thực đến 4 phút, người dùng có thể thêm dòng " WINDOW_SIZE 17”.
• Để vô hiệu hóa đăng nhập thất bại nhiều lần (giới hạn tốc độ), người dùng có thể xóa dòng “ RATE_LIMIT 3 30”. 
• Để thay đổi ngưỡng rate limiting, người dùng có thể tìm dòng “ RATE_LIMIT 3 30” và điều chỉnh các con số. Tại đây, số 3 trong thiết lập ban đầu cho biết số lần thử trong một khoảng thời gian, còn số 30 cho biết khoảng thời gian tính bằng giây. 
• Để vô hiệu hóa hiệu lực của các mã khôi phục, người dùng có thể xóa năm mã 8 chữ số ở cuối file. 

Tip 3: Tránh thiết lập xác thực đa yếu tố (MFA) cho một số tài khoản

Đôi khi có thể xảy ra tình huống một người dùng hoặc một số tài khoản dịch vụ (chẳng hạn như các tài khoản được sử dụng bởi các ứng dụng, không phải user bình thường) cần truy cập SSH mà không phải bật tính năng MFA.

Nếu ứng dụng không có cách nào yêu cầu mã xác minh, yêu cầu đó có thể bị treo cho đến khi SSH hết thời gian chờ kết nối. 

Mặt khác, người dùng có thể kiểm soát bất kỳ yếu tố nào được sử dụng dựa trên cơ sở user-by-user nếu có vài tùy chọn trong file /etc/pam.d/sshd được đặt chính xác. 

Để cho phép sử dụng MFA đối với một số tài khoản và chỉ sử dụng SSH key cho các tài khoản khác, người dùng cần đảm bảo rằng các thiết lập sau đang hoạt động trong file /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

Tại đây, auth substack password-auth được chỉnh thành ghi chú vì password cần được tắt đi. Giao thức MFA không thể thực thi nếu vẫn còn một số account đang tắt MFA. Vì thế để khắc phục, người dùng cần để tùy chọn nullok ở dòng cuối cùng. 

Sau khi cài đặt hoàn tất, bạn chỉ cần khởi chạy lệnh google-authenticator cho những tài khoản cần sử dụng MFA, còn với những tài khoản chỉ sử dụng SSH key thì không cần phải thực hiện lệnh.

Tip 4: Tự động hóa thiết lập với Configuration Management

Hiện có nhiều quản trị viên hệ thống sử dụng các công cụ quản lý cấu hình như Puppet, Chef hay Ansible để quản trị hệ thống của họ. Do đó, nếu người dùng muốn ứng dụng hệ thống này để cài đặt secret key khi khởi tạo một tài khoản mới, cần có một phương pháp thực hiện được điều đó.

Bằng cách sử dụng google-authenticator hỗ trợ các chuyển đổi dòng lệnh để thiết lập tất cả các tùy chọn trong một lệnh duy nhất mà không cần phải sử dụng các giao diện tương tác để cài đặt từng tùy chọn một. 

Để xem tất cả các tùy chọn, người dùng có thể nhập lệnh google-authenticator --help. Sau đó, lệnh sẽ thiết lập tất cả các tùy chọn như đã liệt kê trong bước 1: 

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

Trên màn hình, người dùng lưu lại các tùy chọn vào một file. Sau đó, Output secret key, mã QR và mã khôi phục. (Nếu người dùng thêm -q flat, sẽ không có bất kỳ Output nào hiển thị sau đó). 

Ngoài ra, nếu người dùng sử dụng lệnh này trong quá trình tự động hóa, hãy đảm bảo nắm bắt được secret key hoặc các mã khôi phục và cung cấp chúng cho các user. 

Tip 5: Bắt buộc sử dụng MFA cho tất cả người dùng

Cách đơn giản có thể thực hiện chính là sử dụng cùng một file .google-authenticator cho tất cả người dùng. Vì trong file này sẽ không chứa dữ liệu về người dùng cụ thể.

Để thực hiện điều này, sau khi file configuration được khởi tạo, người dùng đặc quyền – privileged user cần sao chép file vào thư mục root của mỗi thư mục chứa tài khoản người dùng và thay đổi quyền truy cập sao cho tương thích với mỗi người dùng. 

Ngoài ra, cũng có thể sao chép file vào /etc/skel/ để file có thể được sao chép tự động sang thư mục home của người dùng mới sau khi tạo. 

Cũng có một phương pháp khác để bắt buộc tạo secret key cho người dùng – sử dụng một bash script: 

• Tạo TOTP token. 
• Yêu cầu người dùng tải xuống ứng dụng Google Authenticator và quét mã QR để được hiển thị.
• Khởi chạy ứng dụng google-authenticator sau khi kiểm tra file google-authenticator có tồn tại hay chưa. 

Để đảm bảo rằng tập lệnh khởi chạy sau khi người dùng đăng nhập, có thể đặt tên tệp lệnh là .bash_login và đặt ở root thư mục home của người dùng. 

Với 11 năm hoạt động Vietnix hỗ trợ cho hơn 50.000 khách hàng cá nhân và doanh nghiệp phát triển kinh doanh trên internet. Vietnix luôn chú trọng đầu tư vào hạ tầng và nhân sự chất lượng nhằm mang đến cho khách hàng một dịch vụ ổn định nhất. Tính đến thời điểm hiện tại Vietnix tự hào vì đã đạt được những con số ấn tượng như sau:

• 50.000 khách hàng trong và ngoài nước.
• 97% khách hàng đánh giá 5* và giới thiệu dịch vụ sau khi sử dụng.
• 89% khách hàng duy trì dịch vụ đến thời điểm hiện tại.
• 100.000 dịch vụ được kích hoạt.
• Thương hiệu Việt Nam xuất sắc 2022.

Nhanh tay đăng ký Vietnix VPS ngay và trải nghiệm dịch vụ ổn định, tốc độ cao, hỗ trợ nhanh chóng với nhiều ưu đãi hấp dẫn nhất.

• Địa chỉ: 265 Hồng Lạc, Phường 10, Quận Tân Bình, Thành Phố Hồ Chí Minh.
• Hotline: 1800 1093 – 07 088 44444.
• Email: sales@vietnix.com.vn.

Kết luận

Trên đây là cách thiết lập xác thực đa yếu tố (MFA) cho SSH trên CentOS 7. Đừng quên chia sẻ kinh nghiệm của bạn sau khi thực hiện theo hướng dẫn trên của Vietnix cho mọi người cùng tham khảo nhé.