中文 (中国)
English
Mặc định, SSH sử dụng mật khẩu để xác thực, và hầu hết các hướng dẫn tăng cường bảo mật SSH đều khuyên bạn nên sử dụng SSH key thay thế. Tuy nhiên, SSH key cũng chỉ là một yếu tố duy nhất, dù là một yếu tố bảo mật cao hơn nhiều. Kênh truyền dữ liệu ở đây chính là terminal trên máy tính của bạn, gửi dữ liệu qua một tunnel được mã hóa đến máy chủ từ xa. Nhưng giống như hacker có thể đoán được mật khẩu, họ cũng có thể đánh cắp SSH key, và trong cả hai trường hợp, chỉ với một dữ liệu duy nhất, kẻ tấn công có thể truy cập vào hệ thống từ xa của bạn.
Trong bài hướng dẫn này, DataOnline hướng dẫn bạn thiết lập xác thực đa yếu tố (Multi-factor Authentication – MFA) để khắc phục điểm yếu đó. Xác thực đa yếu tố (MFA) hay còn gọi là xác thực hai yếu tố (Two-factor authentication – 2FA) yêu cầu phải có nhiều hơn một yếu tố để thực hiện quá trình xác thực hoặc đăng nhập. Điều này có nghĩa là kẻ xấu sẽ phải xâm nhập được nhiều thứ, chẳng hạn như máy tính và điện thoại của bạn, mới có thể truy cập vào hệ thống. Có một số loại yếu tố được sử dụng trong quá trình xác thực:
- Điều bạn biết: như mật khẩu hoặc câu hỏi bảo mật
- Điều bạn có: như ứng dụng xác thực (authenticator app) hoặc security token
- Điều bạn là: như dấu 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 (Open Authentication Time-Based One-Time Password) là một giao thức mở tạo ra mật khẩu dùng một lần, thường là một dãy số sáu chữ số được tái sử dụng sau mỗi 30 giây.
Bài viết này sẽ hướng dẫn cách kích hoạt xác thực SSH bằng ứng dụng OATH-TOTP bên cạnh SSH key. Việc đăng nhập vào máy chủ qua SSH sẽ yêu cầu hai yếu tố xác thực qua hai kênh khác nhau, do đó bảo mật cao hơn nhiều so với chỉ sử dụng mật khẩu hoặc SSH key một mình. Nếu bạn cần một VPS mạnh mẽ, ổn định để triển khai, khám phá ngay các gói mua VPS giá rẻ tại danh mục VPS!
Yêu cầu
Để theo dõi hướng dẫn này, bạn cần có:
● Một máy chủ Ubuntu 20.04 với một người dùng sudo không phải root, đã cài đặt SSH key và bật firewall, bạn có thể thiết lập theo hướng dẫn trong bài Thiết Lập Máy Chủ Ban Đầu.
● Một chiếc đ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 (có trên cả iOS và Android).
● Ngoài ra, bạn cũng có thể sử dụng một ứng dụng dòng lệnh trên Linux có tên ‘oathtool’ để tạo mã OATH-TOTP. Ứng dụng này có sẵn trong các kho lưu trữ của các bản phân phối khác nhau.
● Nếu bạn muốn bảo mật kết nối SSH của mình, có nhiều bước hữu ích được nêu ra trong bài “SSH Essentials”, chẳng hạn như whitelist người dùng, vô hiệu hóa đăng nhập root, và thay đổi cổng mà SSH sử dụng.
Bước 1 – Cài đặt Pam của Google
Trong bước này, chúng ta sẽ cài đặt và cấu hình PAM của Google.
PAM (viết tắt của Pluggable Authentication Module) là một 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, nên họ cũng phát triển một PAM có khả năng tạo ra các mã TOTP và tương thích hoàn toàn với bất kỳ ứng dụng OATH-TOTP nào như Google Authenticator hay Authy.
Đầu tiên, cập nhật bộ nhớ cache của kho lưu trữ Ubuntu:
sudo apt-getupdate
Tiếp theo, cài đặt PAM:
sudo apt-get install libpam-google-authenticator
Sau khi cài đặt PAM, chúng ta sẽ sử dụng một ứng dụng trợ giúp đi kèm với PAM này để tạo một TOTP key cho người dùng cần có yếu tố xác thực thứ hai. Khóa này được tạo riêng theo từng người dùng, không phải chung cho 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 xác thực TOTP sẽ cần đăng nhập và chạy ứng dụng trợ giúp để tạo khóa của riêng họ; bạn không thể chỉ chạy một lần duy nhất để áp dụng cho tất cả (mặc dù có một số mẹo ở cuối bài hướng dẫn để thiết lập hoặc bắt buộc MFA cho nhiều người dùng).
Chạy ứng dụng khởi tạo:
google-authenticator
Sau khi chạy lệnh, ứng dụng sẽ yêu cầu bạn trả lời một số câu hỏi. Câu hỏi đầu tiên hỏi liệu các mã xác thực có nên dựa vào thời gian hay không:
Output
Do you want authentication tokens to be time-based (y/n) y
PAM này cho phép tạo mã dựa trên thời gian hoặc dựa trên thứ tự. Sử dụng mã dựa trên thứ tự nghĩa là mã sẽ bắt đầu từ một điểm nhất định và sau đó tăng dần sau mỗi lần sử dụng. Sử dụng mã dựa trên thời gian nghĩa là mã sẽ thay đổi sau một khoảng thời gian xác định. Ở đây, chúng ta sử dụng mã dựa trên thời gian vì đó là tiêu chuẩn mà các ứng dụng như Google Authenticator mong đợi, vì vậy hãy trả lời y cho có.
Sau khi trả lời câu hỏi này, rất nhiều thông tin sẽ được in ra, bao gồm cả một mã QR lớn. Sử dụng ứng dụng xác thực trên điện thoại của bạn để quét mã QR hoặc nhập thủ công secret key. Nếu mã QR quá lớn để quét, bạn có thể sử dụng URL phía trên mã QR để có phiên bản nhỏ hơn. Một khi được thêm vào, bạn sẽ thấy một mã gồm sáu chữ số thay đổi sau mỗi 30 giây trong ứng dụng của bạn.
Lưu ý: Hãy chắc chắn rằng bạn ghi lại secret key, verification code và các recovery codes vào một nơi an toàn, chẳng hạn như trình quản lý mật khẩu. Các recovery codes là cách duy nhất để khôi phục quyền truy cập nếu, ví dụ, bạn mất quyền truy cập vào ứng dụng TOTP.
Những câu hỏi còn lại sẽ thông báo cho PAM cách thức hoạt động. Chúng ta sẽ đi qua từng câu một:
Do you want meto update your "~/.google_authenticator" file (y/n) y
Câu lệnh này ghi khóa và các tuỳ chọn vào file .google_authenticator. Nếu bạn trả lời no thì chương trình sẽ thoát và không ghi gì, có nghĩa là ứng dụng xác thực sẽ không hoạt động.
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 tonoticeor even prevent man-in-the-middle attacks (y/n) y
Trả lời “y” ở đây sẽ ngăn chặn cuộc tấn công “replay” bằng cách khiến mỗi mã hết hiệu lực ngay sau khi được sử dụng. Điều này ngăn kẻ tấn công bắt được mã mà bạn vừa sử dụng và đăng nhập bằng mã đó:
Bydefault, a new token isgenerated every 30 seconds by the mobile app.
Để bù đắp cho sự chênh lệch thời gian có thể xảy ra giữa máy khách và máy chủ, chúng ta cho phép một mã bổ sung trước và sau thời điểm hiện tại. Điều này cho phép chênh lệch thời gian tối đa lên đến 30 giây giữa máy chủ xác thực và máy khách.
Giả sử bạn gặp vấn đề với việc đồng bộ thời gian không tốt, trong trường hợp đó, bạn có thể mở rộng cửa sổ thời gian từ kích thước mặc định của 3 mã hợp lệ (một mã trước, mã hiện tại, và một mã sau) lên tới 17 mã hợp lệ (8 mã trước, mã hiện tại, và 8 mã sau). Điều này cho phép chênh lệch thời gian tối đa lên đến 4 phút giữa máy khách và máy chủ.
Do you want todo so? (y/n) n
Trả lời “n” ở đây sẽ giới hạn cửa sổ chỉ còn 3 mã hợp lệ trong khoảng thời gian cuộn 1:30 phút. Trừ khi bạn gặp vấn đề với cửa sổ 1:30 phút, việc trả lời “n” là lựa chọn bảo mật hơn. Bạn có thể thay đổi cài đặt này sau trong file .google_authenticator nằm ở thư mục gốc của người dùng.
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.
Nếu máy tính mà bạn đăng nhập không được “cứng hóa” chống lại các cuộc tấn công dò mật khẩu, bạn có thể kích hoạt giới hạn tốc độ cho module xác thực.
Theo mặc định, điều này giới hạn kẻ tấn công không được phép thử quá 3 lần đăng nhập trong mỗi khoảng 30 giây. Nếu trước đó bạn chưa cấu hình rate-limiting trực tiếp trên SSH, thì kích hoạt tính năng này là một bước kỹ thuật làm cứng hệ thống rất hữu ích.
Lưu ý: Sau khi hoàn tất cấu hình, nếu bạn muốn sao lưu secret key, bạn có thể sao chép file
~/.google_authenticatorđến vị trí tin cậy khác. Từ đó, bạn có thể triển khai trên các hệ thống khác hoặc khôi phục lại cấu hình sau khi sao lưu.
Giờ đây, khi 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 TOTP key của bạn. Chúng ta sẽ cần thông báo cho SSH về PAM này và cấu hình SSH để sử dụng nó.
Bước 2 – Cấu hình Openssh sử dụng Mfa/2fa
Vì chúng ta sẽ thực hiện các thay đổi SSH qua SSH, nên quan trọng là không bao giờ đóng kết nối SSH ban đầu. Thay vào đó, hãy mở một phiên SSH thứ hai để kiểm tra. Điều này giúp tránh việc bạn tự khóa mình ra khỏi máy chủ nếu cấu hình SSH có lỗi. Khi mọi thứ hoạt động ổn, bạn có thể thoải mái đóng những phiên làm việc không cần thiết.
Một biện pháp an toàn khác là tạo bản sao lưu các file hệ thống mà bạn sẽ chỉnh sửa, để nếu có sự cố xảy ra, bạn có thể khôi phục lại file gốc và bắt đầu từ đầu với một cấu hình sạch.
Đầu tiên, hãy tạo bản sao lưu file cấu hình sshd:
sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.bak
Tiếp theo, mở file bằng nano hoặc trình soạn thảo yêu thích:
sudo nano /etc/pam.d/sshd
Thêm dòng sau vào cuối file:
# StandardUn*x password updating. @include common-password auth required pam_google_authenticator.so nullok auth required pam_permit.so
Ở đây, từ “nullok” ở cuối dòng báo với PAM 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ó token OATH-TOTP vẫn có thể đăng nhập chỉ bằng SSH key. Khi tất cả người dùng đã có token OATH-TOTP, bạn có thể loại bỏ “nullok” để bắt buộc sử dụng MFA. Dòng thứ hai với pam_permit.so là cần thiết để cho phép xác thực nếu người dùng không sử dụng token MFA để đăng nhập. Khi đăng nhập, mỗi phương thức đều cần trả về SUCCESS để xác thực được cho phép. Nếu người dùng không sử dụng công cụ xác thực MFA, sử dụng tùy chọn nullok sẽ trả về IGNORE cho xác thực bàn phím tương tác. pam_permit.so sau đó sẽ trả về SUCCESS và cho phép xác thực tiếp tục.
Lưu và đóng file.
Tiếp theo, chúng ta sẽ cấu hình SSH để hỗ trợ kiểu xác thực này.
Trước tiên, tạo bản sao lưu file cấu hình SSH:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
Bây giờ, mở file cấu hình SSH để chỉnh sửa:
sudo nano /etc/ssh/sshd_config
Tìm dòng “ChallengeResponseAuthentication” và đặt giá trị của nó thành “yes”:
# Change to yes to enable challenge-response passwords (beware issues with# some PAM modules and threads)ChallengeResponseAuthenticationyes
Lưu và đóng file, sau đó khởi động lại SSH để nạp lại các file cấu hình. Việc khởi động lại dịch vụ sshd sẽ không đóng các kết nối SSH đang mở, nên bạn sẽ không lo tự khóa mình ra ngoài:
sudo systemctl restart sshd.service
Để kiểm tra xem mọi thứ đã hoạt động ổn chưa, hãy mở một terminal khác và thử đăng nhập qua SSH. Rất quan trọng là bạn giữ phiên SSH hiện tại mở và chỉ thử đăng nhập qua phiên khác, nếu không bạn có thể tự khóa mình ra ngoài và phải sử dụng web console để vào lại hệ thống.
Lưu ý: Nếu trước đó bạn đã tạo SSH key và đang sử dụng nó, bạn có thể nhận thấy bạn không cần nhập mật khẩu người dùng hoặc mã xác thực MFA. Điều này là do SSH key mặc định sẽ ghi đè lên tất cả các tuỳ chọn xác thực khác. Nếu không, bạn nên thấy được lời nhắc nhập mật khẩu và mã xác thực.
Tiếp theo, để kích hoạt SSH key làm một yếu tố và mã xác thực làm yếu tố thứ hai, chúng ta cần thông báo cho SSH biết các yếu tố nào được sử dụng và ngăn SSH key ghi đè lên tất cả các phương thức khác.
Bước 3 – Cho SSH nhận biết được mfa
Mặc dù đã thiết lập, MFA vẫn chưa hoạt động nếu bạn chỉ sử dụng SSH key. Để làm cho SSH nhận biết MFA, hãy mở lại file cấu hình sshd_config:
sudo nano /etc/ssh/sshd_config
Thêm dòng sau vào cuối file. Dòng này thông báo cho SSH biết các phương thức xác thực cần thiết. Chúng ta yêu cầu người dùng sử dụng SSH key và hoặc là mật khẩu hoặc là mã xác thực (hoặc cả ba):
AuthenticationMethods publickey,password publickey,keyboard-interactive
Lưu và đóng file.
Tiếp theo, mở lại file cấu hình PAM của SSH:
sudo nano /etc/pam.d/sshd
Tìm dòng chứa @include common-auth và comment nó lại bằng cách thêm ký tự “#” vào đầu dòng. Điều này báo cho PAM không cần yêu cầu nhập mật khẩu:
# Standard Un*x authentication.#@include common-auth
Lưu và đóng file, sau đó khởi động lại SSH:
sudo systemctl restart sshd.service
Bây giờ thử đăng nhập vào máy chủ qua một phiên terminal khác. Khác với lần trước, SSH giờ sẽ hỏi mã xác thực của bạn. Nhập mã xác thực và bạn sẽ hoàn tất quá trình đăng nhập. Mặc dù không có dấu hiệu nào cho thấy SSH key đã được sử dụng, nhưng quá trình đăng nhập của bạn đã sử dụng hai yếu tố. Nếu bạn muốn kiểm tra chi tiết, bạn có thể thêm tuỳ chọn -v (verbose) sau lệnh SSH.
Lưu ý, khi sử dụng -v, bạn sẽ thấy output như sau:
debug1: Authentications that can continue: publickey debug1:Next authentication method: publickey debug1: Offering RSA publickey: /Users/sammy/.ssh/id_rsa debug1: Server accepts key: pkalg rsa-sha2-512 blen 279 Authenticated withpartial success. debug1: Authentications that can continue: password,keyboard-interactive debug1:Next authentication method: keyboard-interactive Verification code:
Phía cuối của output, bạn sẽ thấy SSH sử dụng SSH key của bạn rồi sau đó yêu cầu nhập mã xác thực. Giờ bạn có thể đăng nhập qua SSH với SSH key và mật khẩu một lần sử dụng (one-time password). Nếu muốn bắt buộc sử dụng cả ba yếu tố xác thực, hãy thực hiện bước tiếp theo.
Chúc mừng, bạn đã thành công khi thêm một yếu tố xác thực thứ hai cho việc đăng nhập từ xa vào máy chủ qua SSH.
Nếu đây chính là cách bạn muốn – sử dụng SSH key và token TOTP để kích hoạt MFA cho SSH (đối với hầu hết người dùng, đây là cấu hình tối ưu) – thì bạn đã hoàn thành.
Tiếp theo là một số mẹo và thủ thuật cho việc khôi phục, sử dụng tự động và những cấu hình nâng cao khác.
Bước 4 – Thêm yếu tố thứ ba
Trong Bước 3, chúng ta đã liệt kê các kiểu xác thực được chấp nhận trong file sshd_config:
- publickey (SSH key)
- password (mật khẩu)
- keyboard-interactive (mã xác thực)
Mặc dù liệt kê ba yếu tố, các tuỳ chọn mà chúng ta đã chọn chỉ cho phép sử dụng SSH key và mã xác thực. Nếu bạn muốn sử dụng đồng thời cả ba yếu tố (SSH key, mật khẩu và mã xác thực), chỉ cần thay đổi nhanh một chút như sau:
Mở lại file cấu hình PAM của SSH:
sudo nano /etc/pam.d/sshd
Tìm dòng bạn đã comment trước đó, #@include common-auth, và bỏ comment bằng cách loại bỏ ký tự “#”. Lưu và đóng file. Sau đó, khởi động lại SSH:
sudo systemctl restart sshd.service
Bằng cách bật lại @include common-auth, PAM giờ sẽ yêu cầu nhập mật khẩu bên cạnh việc kiểm tra SSH key và mã xác thực. Cách này giúp bạn sử dụng “điều chúng ta biết” (mật khẩu) và “hai điều chúng ta có” (SSH key và mã xác thực) qua hai kênh khác nhau (máy tính của bạn cho SSH key và điện thoại cho token TOTP).
Bước 5 – Khôi phục quyền truy cập Google MFA
Như với bất kỳ hệ thống nào được tăng cường bảo mật, bạn cần chịu trách nhiệm trong việc quản lý bảo mật đó. Trong trường hợp này, nghĩa là không được mất SSH key hoặc secret key TOTP và phải đảm bảo bạn luôn có quyền truy cập vào ứng dụng TOTP của mình. Tuy nhiên, đôi khi sự cố xảy ra và bạn có thể mất quyền truy cập vào các khóa hoặc ứng dụng cần thiết để đăng nhập.
Mất secret key totp
Nếu bạn mất secret key TOTP, bạn có thể tách quá trình khôi phục thành hai bước: bước đầu tiên là đăng nhập vào hệ thống mà không cần mã xác thực, bước thứ hai là lấy lại hoặc tạo mới secret key để đăng nhập MFA bình thường. Điều này thường xảy ra khi bạn có một chiếc điện thoại mới mà không chuyển các secret sang ứng dụng xác thực mới.
Để đăng nhập vào máy chủ (ví dụ trên một Droplet của DataOnline) khi mất secret key TOTP, bạn có thể sử dụng virtual console từ dashboard để đăng nhập bằng tên người dùng và mật khẩu. Phương pháp này có hiệu lực vì bạn chỉ bảo vệ tài khoản của mình với MFA đối với kết nối SSH. Các kết nối không qua SSH, chẳng hạn như đăng nhập console, không sử dụng module PAM của Google Authenticator.
Nếu bạn đang sử dụng hệ thống không phải là Droplet, bạn có hai lựa chọn để khôi phục quyền truy cập:
- Sử dụng quyền truy cập console (local hoặc qua các hệ thống như iDrac).
- Sử dụng một tài khoản khác không được kích hoạt MFA.
Lựa chọn thứ hai có mức độ bảo mật thấp hơn vì mục đích của MFA là tăng cường bảo vệ tất cả các kết nối SSH, nhưng nó vẫn là một phương án dự phòng nếu bạn mất quyền truy cập vào ứng dụng xác thực của mình.
Sau khi đã đăng nhập vào hệ thống, có hai cách để lấy lại secret key TOTP:
- Khôi phục khóa hiện có
- Tạo khóa mới
Trong thư mục home của mỗi người dùng, secret key và các cài đặt của Google Authenticator được lưu trong file ~/.google_authenticator. Dòng đầu tiên của file này chính là secret key.
Một cách nhanh để lấy khóa là chạy lệnh hiển thị dòng đầu tiên của file .google_authenticator (tức là secret key):
head -n 1 /home/sammy/.google_authenticator
Sau khi khôi phục được khóa, bạn có thể nhập thủ công vào ứng dụng xác thực hoặc điền các thông tin cần thiết vào URL dưới đây để Google tạo mã QR để bạn quét. Bạn sẽ cần nhập tên người dùng, hostname, secret key từ file .google_authenticator, và một cái tên do bạn tự đặt cho entry-name-in-auth-app để dễ dàng phân biệt khóa này với một token TOTP khác.
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/username@hostname%3Fsecret%3D16-char-secret%26issuer%3Dentry-name-in-auth-app
Nếu vì lý do nào đó bạn không muốn sử dụng khóa hiện có (ví dụ, không thể chia sẻ một cách an toàn secret key với người dùng bị ảnh hưởng), bạn có thể xóa file ~/.google_authenticator đi. Điều này sẽ cho phép người dùng đăng nhập lại chỉ với một yếu tố duy nhất, với điều kiện bạn chưa buộc MFA bằng cách loại bỏ tùy chọn nullok. Sau đó, họ có thể chạy lệnh google-authenticator để tạo khóa mới.
Mất quyền truy cập ứng dụng totp
Nếu bạn cần đăng nhập vào máy chủ nhưng không có quyền truy cập vào ứng dụng TOTP để nhận mã xác thực, bạn vẫn có thể đăng nhập sử dụng các recovery codes đã được hiển thị khi bạn tạo secret key lần đầu. Các recovery codes này là 5 dòng cuối của file .google_authenticator và mỗi mã chỉ có thể sử dụng một lần. Tuy nhiên, để sử dụng phương thức này, bạn phải lưu trữ các recovery codes ở nơi dễ truy cập khi không có quyền truy cập vào ứng dụng TOTP. Khám phá ngay danh mục mua VPS của chúng tôi với các gói mua VPS giá rẻ, đảm bảo hiệu suất vượt trội, hỗ trợ 24/7, phù hợp cho mọi nhu cầu tại danh mục VPS!
Bước 6 – Thay đổi cài đặt xác thực
Nếu bạn muốn thay đổi cài đặt MFA sau khi đã thiết lập ban đầu, thay vì tạo lại một cấu hình mới, bạn chỉ cần chỉnh sửa file ~/.google_authenticator. Các tuỳ chọn trong file này được hiển thị theo định dạng sau:
.google-authenticator layout <secretkey> <options> <recoverycodes>
Mỗi tuỳ chọn trong phần “options” tương ứng với một dòng; nếu bạn trả lời “no” cho một tuỳ chọn nào đó trong quá trình thiết lập ban đầu, chương trình sẽ không ghi dòng tương ứng vào file.
Dưới đây là một số thay đổi bạn có thể thực hiện trong file:
● Để bật mã theo thứ tự thay vì theo thời gian, thay dòng
"TOTP_AUTH thành "HOTP_COUNTER 1.
● Để cho phép sử dụng lại một mã nhiều lần, hãy xóa dòng chứa "DISALLOW_REUSE.
● Để kéo dài cửa sổ thời gian hiệu lực của mã đến 4 phút, thêm dòng "WINDOW_SIZE 17.
● Để vô hiệu hóa việc giới hạn số lần đăng nhập thất bại (rate-limiting), xóa dòng "RATE_LIMIT 3 30.
● Để thay đổi ngưỡng giới hạn rate-limiting, tìm dòng "RATE_LIMIT 3 30" và điều chỉnh các con số. Số 3 chỉ số lần thử trong khoảng thời gian, còn số 30 biểu thị thời gian tính bằng giây.
● Để vô hiệu hóa việc sử dụng recovery codes, hãy xóa 5 mã recovery gồm 8 chữ số nằm ở cuối file.
Bước 7 – Loại bỏ mfa cho một số tài khoản
Có thể xảy ra tình huống mà một số tài khoản cá nhân hoặc tài khoản dịch vụ (ví dụ, tài khoản do ứng dụng sử dụng chứ không phải của con người) cần truy cập SSH mà không có MFA. Ví dụ, một số ứng dụng sử dụng SSH như một số FTP clients có thể không hỗ trợ MFA. Nếu ứng dụng không có cách để yêu cầu mã xác thực, yêu cầu đó có thể bị treo cho đến khi kết nối SSH hết hạn.
Để kiểm soát những yếu tố xác thực cho từng người dùng, bạn có thể chỉnh sửa file /etc/pam.d/sshd.
Để cho phép MFA chỉ với một số tài khoản và chỉ SSH cho những tài khoản khác, hãy đảm bảo rằng các cài đặt sau trong file /etc/pam.d/sshd được kích hoạt:
# PAM configuration for the Secure Shell service# Standard Un*x authentication.#@include common-auth ... # Standard Un*x password updating.@include common-password auth required pam_google_authenticator.so nullok
Ở đây, dòng @include common-auth được comment vì mật khẩu cần phải được vô hiệu hóa. Bạn không thể bắt buộc MFA nếu một số tài khoản đã tắt MFA, vì vậy hãy giữ lại tùy chọn nullok ở dòng cuối.
Sau khi cài đặt cấu hình này, hãy chạy lệnh google-authenticator cho bất kỳ người dùng nào cần MFA, và không chạy với những người dùng chỉ sử dụng SSH key.
Bước 8 – Tự động hóa thiết lập với công cụ quản lý cấu hình
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 hoặc Ansible để quản lý hệ thống của mình. Bạn có thể sử dụng hệ thống như vậy để cài đặt và thiết lập secret key mỗi khi có người dùng mới tạo tài khoản.
google-authenticator hỗ trợ các tham số dòng lệnh cho phép thiết lập tất cả các tuỳ chọn trong một lệnh không tương tác. Để xem tất cả các tuỳ chọn, bạn có thể gõ google-authenticator --help. Dưới đây là lệnh sẽ thiết lập mọi thứ như đã nêu ở Bước 1:
google-authenticator -t -d -f -r 3 -R 30 -w 3
Các tham số được tham chiếu ở trên như sau:
● -t => Sử dụng cơ chế đếm dựa trên thời gian
● -d => Không cho phép sử dụng lại token
● -f => Ép ghi cài đặt vào file mà không cần xác nhận từ người dùng
● -r => Số lần thử nhập mã đúng
● -R => Thời gian tính bằng giây mà người dùng có thể thử nhập mã đúng
● -w => Số mã có thể hợp lệ cùng lúc (tham số này liên quan tới cửa sổ thời gian từ 1:30 phút đến 4 phút hiệu lực của mã)
Lệnh này thiết lập hoàn toàn ứng dụng xác thực, lưu cài đặt vào file và sau đó xuất ra secret key, mã QR và recovery codes. (Nếu bạn thêm tham số -q, sẽ không có bất kỳ xuất nào.) Nếu sử dụng lệnh này tự động, hãy đảm bảo script của bạn lưu lại secret key và/hoặc recovery codes và cung cấp cho người dùng.
Bước 9 – 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 từ lần đăng nhập đầu tiên hoặc không muốn phụ thuộc vào việc người dùng tự tạo khóa, có một cách nhanh để giải quyết điều này. Bạn có thể sử dụng cùng một file .google_authenticator cho mỗi người dùng, vì file này không chứa bất kỳ dữ liệu riêng cho từng người dùng.
Để làm như vậy, sau khi tạo file cấu hình, một người dùng có quyền cao cần sao chép file này vào thư mục gốc của mỗi home directory và thay đổi quyền truy cập cho phù hợp với người dùng đó. Bạn cũng có thể sao chép file này vào /etc/skel/, làm cho file tự động được sao chép vào thư mục home của mỗi người dùng mới khi chúng được tạo.
Cảnh báo: Phương pháp này có thể là một rủi ro bảo mật vì mọi người dùng đều chia sẻ cùng một yếu tố thứ hai. Điều này có nghĩa là nếu file này bị rò rỉ, như thể mọi người dùng chỉ có một yếu tố bảo mật. Hãy cân nhắc kỹ lưỡng nếu bạn muốn sử dụng phương án này.
Một phương pháp khác để ép bắt người dùng tạo secret key là sử dụng một script bash mà:
- Tạo một token TOTP,
- Yêu cầu người dùng tải ứng dụng Google Authenticator và quét mã QR sẽ hiển thị,
- Sau đó chạy ứng dụng
google-authenticatorcho họ sau khi kiểm tra xem file~/.google_authenticatorđã tồn tại hay chưa.
Để đảm bảo script chạy khi người dùng đăng nhập, bạn có thể đặt nó vào file .bash_login trong thư mục gốc của home directory của họ.
Kết luận
Trong hướng dẫn này, bạn đã áp dụng thành công cơ chế xác thực đa yếu tố bằng cách kết hợp SSH key và token MFA, trải rộng qua hai kênh kết nối là máy tính và điện thoại. Phương pháp này đã giúp tăng cường đáng kể bảo mật cho máy chủ khi truy cập từ xa qua SSH, khiến các cuộc tấn công brute-force trở nên cực kỳ khó khăn cho những kẻ xâm nhập và đảm bảo hệ thống của bạn an toàn hơn trong môi trường CNTT hiện đại.
