Thời phong kiến, để xác thực lệnh điều động binh mã, người xưa đã dùng Hổ Phù, một cơ chế dựa trên vật sở hữu (Possession-based Authentication) có từ hàng ngàn năm trước.
Hổ Phù là một miếng đồng hình con hổ được xẻ làm đôi, lệnh điều binh chỉ có hiệu lực khi hai nửa này được ghép lại và khớp nhau hoàn toàn. The Met mô tả một nửa do hoàng đế giữ, nửa còn lại nằm trong tay người chỉ huy.
Cơ chế này giảm sự phụ thuộc vào Trí nhớ và Lòng tin. Lời nói có thể bị nghe lén, mật khẩu có thể bị ép cung mà khai ra, nhưng muốn giả lệnh bằng Hổ Phù thì phải có được nửa khớp với mảnh người chỉ huy đang giữ. Miếng đồng vẫn có thể bị trộm hoặc làm giả, nhưng biết một câu mật khẩu thôi thì chưa đủ.
Ngày nay, SSH Key gợi nhớ đến chiếc Hổ Phù đó: chứng minh mình giữ đúng chìa khóa, thay vì đọc ra một bí mật. Vậy tại sao ở thời đại của AI, vẫn còn nhiều SysAdmin chấp nhận dùng Password để bảo vệ cả một hạ tầng server?
1. Điểm yếu của Password
Vấn đề lớn nhất của Password không nằm ở việc người dùng hay đặt là 123456 hay password@123. Vấn đề thực sự nằm ở cơ chế Shared Secret (Bí mật chia sẻ).
Để chứng minh danh tính với Server bằng Password, bạn buộc phải *gửi* bí mật đó đi (transmit). SSH mã hóa đường truyền bằng giao thức riêng, không phải SSL/TLS, nên người nghe lén giữa đường không đọc được mật khẩu. Nhưng tại điểm đích, Server vẫn nhận được bí mật để đối chiếu. Ví như nói nhỏ mật khẩu cho lính canh trong một căn phòng kín: người ngoài không nghe được, còn lính canh thì có.
- Nếu lính canh (Server) bị mua chuộc hoặc bạn chấp nhận nhầm Host Key của một Server giả, bí mật có thể rơi vào tay kẻ khác.
- Nếu mật khẩu bị lấy ở đầu mút, chẳng hạn qua keylogger, kẻ có nó có thể đăng nhập lại chừng nào mật khẩu còn hiệu lực. Đây là tái sử dụng bí mật đã lộ, không phải phát lại gói tin SSH đã mã hóa.
Hơn nữa, Password là "Something you know". Đặc điểm của tri thức là nó có thể bị sao chép vô hạn mà chủ nhân không hề hay biết. Nếu ai đó nhìn trộm bạn gõ phím, họ đã có được bản sao của chìa khóa. Ngược lại, Hổ Phù là "Something you have". Mất miếng đồng thì ít nhất còn có cơ hội nhận ra vì thiếu một vật. File Private Key lại có thể bị copy mà bản gốc vẫn nằm nguyên trên máy.
Đối với anh em SysAdmin, việc mở port 22 với Password Authentication chẳng khác nào mở tiệc mời botnet. Hãy thử tail -f /var/log/auth.log (hoặc /var/log/secure) trên một server mới tạo xem. Bạn có thể thấy những lượt đăng nhập tự động từ khắp nơi trên thế giới đang thi nhau "thử vận may" (Brute-force).
Dù chúng có đoán sai cả triệu lần, CPU của server vẫn phải tốn tài nguyên để xử lý cái Access Denied đó. Đó là một sự lãng phí tài nguyên và rủi ro bảo mật không đáng có.
2. Sự ra đời của SSH
Trước năm 1995, các SysAdmin thời đó quản lý server từ xa thông qua các giao thức như Telnet, rlogin hay rsh.
Với Telnet thông thường, những gì bạn gõ, bao gồm cả username và password, được gửi dưới dạng văn bản thô qua mạng. Các giao thức rlogin và rsh truyền thống cũng không bảo vệ nội dung bằng mã hóa. Nếu coi Internet là một đường ống nước bằng kính trong suốt, thì ai đứng ngoài cũng có thể nhìn thấy dòng nước (dữ liệu) đang chảy bên trong màu gì. Một hacker chỉ cần tcpdump trên đường truyền là gom được cả rổ mật khẩu.
Mọi thứ thay đổi vào năm 1995 tại Đại học Công nghệ Helsinki (Phần Lan). Hệ thống mạng của trường bị tấn công bằng kỹ thuật password sniffing.
Để đối phó, một nhà nghiên cứu tên là Tatu Ylönen đã tự tay viết một giao thức mới để thay thế Telnet. Ông đặt tên nó là Secure Shell, viết tắt là SSH.
Thay vì trông chờ đường ống luôn kín, SSH xử lý dữ liệu ngay tại hai đầu mút (Endpoints). Trước khi thả dữ liệu vào ống, SSH dùng thuật toán để "xáo trộn" nó thành một mớ ký tự hỗn độn. Sang đến đầu kia, chìa khóa giải mã sẽ sắp xếp lại mớ hỗn độn đó thành thông tin có nghĩa. Dù hacker có ghé mắt vào đường ống ở giữa, thứ họ nhận được chỉ là dữ liệu mã hóa (ciphertext) không thể đọc trực tiếp thành nội dung ban đầu.
Một chi tiết thú vị về Port 22: Khi Tatu thiết kế SSH, ông muốn nó thay thế Telnet (chạy ở port 23) và FTP (chạy ở port 21). Ông nhìn vào danh sách port chuẩn của IANA và thấy con số 22 vẫn còn trống. Port 22 nằm kẹp giữa 21 và 23, như một tuyên ngôn ngầm rằng SSH sinh ra để thế chỗ cho cả hai giao thức kém bảo mật kia. Tatu gửi email cho IANA xin cấp port 22, và phần còn lại là lịch sử. Ông kể lại chuyện này trong bài viết về port 22 .
Từ đó, SSH dần lan rộng khắp thế giới, trở thành "tiêu chuẩn de facto" cho việc quản trị server từ xa, đẩy Telnet vào viện bảo tàng công nghệ.
3. SSH Key Authentication
SSH đã hỗ trợ xác thực bằng RSA từ phiên bản đầu, như Tatu Ylönen mô tả trong bài báo năm 1996 . Còn quy trình dưới đây là xác thực bằng khóa công khai của SSH phiên bản 2 đang dùng hiện nay.
Về mặt kỹ thuật, SSH Key Authentication là ứng dụng của mật mã khóa công khai (Public-key cryptography), cụ thể là cơ chế Chữ ký số (Digital Signature).
Khác với Password (bạn gửi bí mật đi để so khớp), SSH Key hoạt động theo nguyên tắc: Server nắm giữ ổ khóa (Public Key), Client nắm giữ con dấu (Private Key).
Có thể hình dung quy trình theo RFC 4252 như sau:
- Đề nghị (Proposal): Client có thể gửi Public Key lên Server để hỏi: *"Tôi muốn đăng nhập bằng Key này"*. Đây là bước thăm dò tùy chọn, Client cũng có thể gửi thẳng yêu cầu đã ký.
- Kiểm tra (Check): Server kiểm tra Key đó có được phép dùng cho tài khoản này hay không, thường qua file
~/.ssh/authorized_keys. Có tên trong danh sách mới chỉ là điều kiện đầu tiên. - Chuẩn bị dữ liệu: Client đưa Session ID cùng thông tin yêu cầu đăng nhập vào dữ liệu cần ký. Chữ ký nhờ vậy được gắn với chính phiên kết nối đang mở.
- Ký số (Signing): Client dùng Private Key để ký dữ liệu đó rồi gửi yêu cầu kèm chữ ký lên Server. Client không gửi Private Key.
- Xác minh (Verification): Server dùng Public Key (đang có sẵn) để kiểm tra xem chữ ký kia có đúng là được tạo ra bởi Private Key tương ứng hay không. Nếu Key được phép dùng và chữ ký hợp lệ, bước xác thực bằng Key thành công. Server vẫn có thể yêu cầu thêm yếu tố xác thực theo cấu hình.
Điểm mấu chốt về bảo mật: Trong quy trình xác thực này, Client không gửi Private Key cho Server. Server chỉ cần Public Key để kiểm tra chữ ký.
Ngay cả khi kẻ tấn công có được một chữ ký xác thực, hắn cũng không thể mang nó sang phiên khác để đăng nhập lại (Replay Attack), vì Session ID đã khác. Với thuật toán an toàn và triển khai đúng, chữ ký cũng không cho phép suy ngược ra Private Key.
Đây là lý do SSH Key có lợi thế về kiến trúc so với Password: Server có thể kiểm tra bạn giữ bí mật mà không cần nhận chính bí mật ấy. Nhưng Client vẫn phải xác minh đúng Server qua Host Key. Lần đầu kết nối, hãy đối chiếu fingerprint qua kênh đáng tin trước khi chấp nhận. Nếu khóa đã biết bỗng đổi, cần kiểm tra nguyên nhân, đừng xóa cảnh báo cho qua.
4. Best Practices
SSH Key an toàn hơn Password nếu dùng đúng cách. Dưới đây là vài nguyên tắc để anh em SysAdmin ngủ ngon hơn.
4.1. Tại sao luôn phải đặt Passphrase?
Trong câu chuyện Tín Lăng Quân cứu Triệu được chép ở Sử ký , nước Triệu bị quân Tần vây hãm, Tín Lăng Quân muốn cứu nhưng không có quyền điều binh. Binh quyền nằm ở chiếc Hổ Phù trong tay vua Ngụy. Ông bèn nhờ Như Cơ trộm chiếc Hổ Phù từ trong phòng ngủ của vua, rồi giành quyền chỉ huy quân Ngụy và đưa 8 vạn quân đi giải vây cho nước Triệu.
Trong thế giới số, Như Cơ chính là Malware, là Poisoned Package, hoặc một pha Social Engineering ngọt ngào mà bạn vô tình dính bẫy.
Bài học ở đây là: Cơ chế của Hổ Phù (hay SSH Key) là dựa trên vật sở hữu. Ai cầm vật đó, người đó có quyền. Laptop của bạn chính là "phòng ngủ của vua". Nếu bạn mất laptop, hoặc máy dính virus, hacker có thể copy được file Private Key.
- Nếu không có Passphrase: Kẻ lấy được file có thể dùng nó đăng nhập vào những Server còn cấp quyền cho Key đó.
- Nếu có Passphrase: File Private Key được mã hóa. Kẻ lấy file còn phải tìm cách vượt qua lớp bảo vệ này, chẳng hạn đoán passphrase yếu.
Passphrase thêm một lớp bảo vệ cho Key lưu trên đĩa, nhưng không nên coi đó là MFA hoàn chỉnh. Malware trên máy vẫn có thể lấy passphrase lúc bạn gõ hoặc lợi dụng SSH agent đã mở khóa. Đừng lười một bước nhỏ mà để lại mối nguy tiềm tàng về lâu dài.
4.2. Chọn RSA hay Ed25519?
Hãy tưởng tượng RSA giống như những bộ giáp sắt (Plate Armor) của hiệp sĩ Châu Âu trung cổ. Thời gian đầu, nó rất kiên cố. Nhưng khi vũ khí tấn công (năng lực tính toán của máy tính) ngày càng mạnh lên, người ta buộc phải đắp ngày càng nhiều sắt lên bộ giáp đó để giữ an toàn. Với RSA, tăng mức bảo vệ thường đi kèm tăng kích thước khóa. Bộ giáp 4096 bit vì thế cũng cồng kềnh hơn. Điều đó không có nghĩa mọi RSA Key đều đã yếu hay đều phải tăng lên 4096 bit.
Ngược lại, Ed25519 (dựa trên đường cong elliptic) giống như kỵ binh Mông Cổ trong phép so sánh này: gọn nhẹ, cơ động, không cần mang theo một bộ giáp sắt đồ sộ.
Về mặt kỹ thuật:
- RSA 4096: Là một sớ văn bản dài dằng dặc, copy-paste rất dễ thiếu đầu hụt đuôi.
- Ed25519: Public Key ngắn gọn hơn nhiều so với RSA 4096. Đây là thuật toán chữ ký số, không dùng để mã hóa hay giải mã dữ liệu phiên SSH. Đừng nhầm độ dài chuỗi Key với số bit bảo mật.
Nếu cả Client lẫn Server hỗ trợ và môi trường không có yêu cầu riêng, Ed25519 là lựa chọn gọn nhẹ khi tạo Key mới. RSA vẫn có chỗ trong những hệ thống cần tương thích. Cú pháp tạo Ed25519 theo tài liệu ssh-keygen :
ssh-keygen -t ed25519 -C "name@company.com"
4.3. Một key hay nhiều key?
Trong giới SysAdmin tồn tại một cuộc tranh luận không hồi kết về việc nên dùng bao nhiêu key là đủ. Có hai phe thường thấy:
Phe chúa nhẫn: "One Ring to rule them all" (Một chìa cho tất cả) Bạn tạo đúng 1 cặp key, và copy Public Key đó lên tất cả 100 con server bạn quản lý, từ Github cá nhân, VPS test cho đến hệ thống Core Banking của công ty.
- Ưu điểm: Cực nhàn. File
~/.ssh/configngắn gọn. Đi đâu cũng chỉ cần 1 file identity. - Nhược điểm: Đây là một điểm rủi ro tập trung. Nếu Private Key bị lộ và dùng được, mọi nơi còn cấp quyền cho Key ấy đều cần được kiểm tra. Việc đi revoke (thu hồi) cùng một Key trên 100 con server là một cơn ác mộng.
Phe 3 đầu 6 tay: Mỗi Server một Key Bạn quản lý 50 server, bạn tạo 50 cặp key khác nhau.
- Ưu điểm: Khi chỉ một Key bị lộ, phạm vi thu hồi gọn hơn (Compartmentalization). Mất chìa khóa phòng kho thì không phải thay cả bộ khóa nhà. Nhưng nếu toàn bộ Key cùng nằm trên một laptop bị chiếm, nhiều chìa cũng mất theo cả chùm.
- Nhược điểm: Bạn sẽ chết chìm trong đống file key. Quản lý, backup và config alias cho 50 cái key này sẽ ngốn hết thời gian làm việc của bạn.
Giải pháp: Phân chia theo Ngữ cảnh (Security Domains). Đây là con đường trung đạo giúp bạn trung hòa cả ưu nhược điểm của 2 phe trên. Hãy tạo key dựa trên Identity (Danh tính) và Mức độ rủi ro:
- Key Cá nhân (Personal): Dùng cho Github cá nhân, VPS học tập, blog riêng.
- Key Công việc (Work): Dùng cho hạ tầng công ty, Gitlab công ty. (Rủi ro cao, cần bảo vệ nghiêm ngặt). Nếu bạn làm cho nhiều công ty khác nhau thì mỗi công ty một key.
- Key Khách (Guest/Temp): Dùng cho các server của khách hàng freelance, làm xong dự án thì thu hồi quyền trên Server theo thỏa thuận. Việc chỉ xóa file Private Key trên máy mình, hoặc cất nó vào ổ cứng offline, không làm Server ngừng chấp nhận Key đó.
Bằng cách này, bạn quản lý Key vừa nhàn vừa dễ thu hồi khi một Key cụ thể bị lộ. Tách thêm theo thiết bị cũng giúp biết cần gỡ Key nào khi mất máy. Nếu nghi Private Key đã bị sao chép, hãy cấp Key mới và gỡ Public Key cũ khỏi nơi cấp quyền. Đổi passphrase trên bản mình giữ không vô hiệu hóa bản sao đã lộ.
4.4. Nên chmod key thế nào?
Quyền file là chuyện ai được đọc hoặc ghi Private Key trên máy, không phải biến nó thành một vật bất biến. Theo tài liệu OpenSSH , Private Key không được để những người dùng khác đọc được. Cách đặt thông dụng là 700 cho thư mục ~/.ssh và 600 cho file Private Key.
Nếu muốn bỏ cả quyền ghi của chủ sở hữu để tránh sửa nhầm, bạn có thể dùng:
chmod 400 ~/.ssh/id_ed25519400 = Read-only với chủ sở hữu, không cấp quyền cho group và những người dùng khác. 600 cũng hợp lệ, cho phép chủ sở hữu đọc và ghi.
Cách chmod này phù hợp với nguyên tắc Least Privilege (Quyền hạn tối thiểu), nhưng đừng giao cho nó việc của một két sắt. Chủ sở hữu vẫn có thể cấp lại quyền ghi, còn malware chạy dưới cùng user vẫn có thể đọc file 400. Muốn bảo vệ Key khi file bị lấy đi, bạn vẫn cần passphrase và một máy tính được bảo vệ tử tế.
Kết
Suy cho cùng, Hổ Phù hay SSH Key cũng chỉ là công cụ. Vào tay tướng tài thì cứu nước, vào tay kẻ lơ là thì mất nước. Hy vọng bài viết này giúp anh em giữ chặt được cái "Hổ Phù" của mình. Nếu có gì thiếu sót, mong nhận được comment góp ý bên dưới!
No comments yet