Đăng Nhập SSH Lần Đầu Vào VPS Trên macOS, Windows Và Linux: Không Còn Ám Ảnh Lỗi Permission Denied

Lần đầu tiên đăng nhập SSH vào một chiếc VPS mới tinh giống như lần đầu cầm chìa khóa từ tới mở cửa căn hộ mới nhận bàn giao: bạn phải đến đúng tòa nhà (IP), tra đúng chiếc chìa khóa gốc (Private Key) vào đúng ổ khóa của chủ hộ (User), và xác nhận đúng biển số phòng (Host Fingerprint). Chỉ nhìn thấy một dấu nhắc nhấp nháy trên màn hình Terminal chưa đủ để khẳng định bạn đã ngồi đúng trên chiếc máy chủ mình định cấu hình. Việc rà soát chuẩn xác ngay từ bước đặt chân vào cửa sẽ giúp bạn tránh được cảnh gõ nhầm lệnh cài phần mềm lên máy chủ Production đang chạy ổn định.

Hướng dẫn thực chiến này áp dụng cho các máy chủ VPS chạy hệ điều hành Linux vừa khởi tạo, kết nối từ máy tính cá nhân của bạn thông qua trình khách tiêu chuẩn OpenSSH Client. Trong các câu lệnh mẫu bên dưới, chúng tôi sử dụng tài khoản quản trị mặc định do nhà cung cấp cấp phát lúc tạo máy (trên chiếc LAB-CF-01 của CloudFly là tài khoản root). Lưu ý rằng tùy vào nhà cung cấp Cloud hoặc bản Image hệ điều hành bạn chọn, tên tài khoản mặc định có thể là ubuntu, debian hay ec2-user — vì vậy hãy luôn nhìn vào thông tin chi tiết của đúng chiếc VPS bạn vừa tạo.

Chuẩn bị hành trang trước khi bật Terminal

Trước khi gõ bất kỳ câu lệnh nào, hãy mở sổ tay vận hành ra và gom đủ 5 thông tin cốt lõi: Địa chỉ IPv4 công khai của VPS lab, cổng lắng nghe SSH (mặc định là 22), tên User ban đầu, đường dẫn tới file Private Key trên máy tính cá nhân (khớp với chiếc Public Key bạn đã gắn lên Panel lúc tạo máy), và cuối cùng là đường vào Web Console dự phòng. Một thói quen cực tốt của dân kỹ thuật lâu năm là trước khi copy địa chỉ IP, luôn liếc mắt nhìn lại tên Instance và mã ID một lần nữa để chắc chắn không copy nhầm địa chỉ IP của máy chủ khách hàng.

Hãy nhớ kỹ nguyên lý bất di bất dịch của cặp khóa bất đối xứng: file Private Key (không có đuôi .pub) phải nằm im và được bảo mật tuyệt đối trên máy tính cá nhân của bạn. Tham số -i trong câu lệnh SSH luôn yêu cầu trỏ vào file Private Key này chứ không bao giờ nhận file .pub. Ngoài ra, nếu lúc tạo khóa bạn có đặt mật khẩu bảo vệ khóa (Passphrase), trình khách SSH trên máy bạn sẽ hỏi cụm mật khẩu đó để giải mã file khóa cục bộ — đừng nhầm lẫn lời nhắc này với mật khẩu đăng nhập tài khoản CloudFly hay mật khẩu của user Linux trên server nhé!

Sơ đồ minh họa cơ chế xác thực bằng cặp khóa SSH: tuyệt đối không bao giờ chép file Private Key của bạn đẩy lên VPS để đăng nhập.

Bước 1: Kiểm tra sẵn sàng công cụ OpenSSH Client trên máy cá nhân

Trên hệ điều hành macOS hoặc hầu hết các bản phân phối Linux Desktop, công cụ OpenSSH Client đã được tích hợp sẵn từ trong trứng nước. Bạn chỉ cần mở ứng dụng Terminal lên và gõ lệnh kiểm tra phiên bản:

ssh -V

Đối với anh em sử dụng Windows 10 / Windows 11, hãy mở cửa sổ PowerShell và chạy đúng câu lệnh ssh -V ở trên. Các bản Windows hiện đại đều đã cài sẵn OpenSSH Client chính chủ của Microsoft. Trong trường hợp hy hữu nếu máy báo chưa nhận diện được lệnh, bạn chỉ cần vào phần Optional Features (Tính năng tùy chọn) trong Settings của Windows để bật OpenSSH Client theo hướng dẫn chính thức từ Microsoft — tuyệt đối không cần và không nên tải các phần mềm SSH trôi nổi không rõ nguồn gốc trên mạng về cài đặt.

Dòng thông tin phiên bản trả về (ví dụ OpenSSH_9.x hoặc OpenSSH_for_Windows_8.x) giúp bạn biết công cụ dưới máy trạm đã sẵn sàng. Nhân tiện lúc này, hãy đóng bớt các cửa sổ Terminal cũ không liên quan để lát nữa thao tác không bị loạn tab.

Bước 2: Đối chiếu dấu vân tay máy chủ (Host Fingerprint) qua kênh tin cậy

Khi bạn kết nối SSH tới một địa chỉ IP lần đầu tiên trong đời, máy tính của bạn chưa từng biết mặt mũi chiếc server này ra sao nên sẽ bật lên dòng thông báo kinh điển: “The authenticity of host ‘…’ can’t be established… Are you sure you want to continue connecting (yes/no/[fingerprint])?”. Chín trên mười người mới học sẽ nhắm mắt gõ chữ yes cái rụp cho nhanh! Nhưng khoan đã: chuỗi mã băm SHA256:... mà SSH đang hỏi bạn chính là Host Key Fingerprint dùng để định danh bản thân chiếc máy chủ VPS (khác hoàn toàn với chiếc SSH Key cá nhân của bạn nhé).

Làm sao để biết chiếc server đang trả lời ở đầu dây bên kia đúng là VPS của mình chứ không phải một kẻ nghe lén (Man-in-the-Middle) hay do mình gõ nhầm IP sang máy người khác? Cách chuẩn chỉnh nhất là mở màn hình Web Console chính thức của VPS trên bảng điều khiển nhà cung cấp, đăng nhập vào và chạy lệnh đọc dấu vân tay của khóa máy chủ (ví dụ chuẩn khóa Ed25519):

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Câu lệnh trên chỉ đọc file khóa công khai của máy chủ (/etc/ssh/ssh_host_ed25519_key.pub) nên hoàn toàn an toàn. Khi nhìn thấy chuỗi SHA256:... trên Web Console khớp 100% từng ký tự với chuỗi mà Terminal trên laptop đang hỏi, lúc đó bạn mới tự tin gõ yes để lưu vào danh bạ known_hosts. Lưu ý rằng các công cụ quét qua mạng như ssh-keyscan cũng chỉ lấy thông tin qua đường truyền Internet chưa xác thực nên không thể thay thế bước kiểm tra qua Console nội bộ này được.

Đặc biệt, đừng bao giờ vì lười biếng mà thêm cờ StrictHostKeyChecking=no vào thói quen gõ lệnh hằng ngày chỉ để bỏ qua câu hỏi xác nhận danh tính máy chủ!

Ảnh chụp màn hình Web Console thực tế lúc 08:17 ngày 01/10/2026 trên máy chủ LAB-CF-02, hiển thị rõ Hostname, mốc thời gian và chuỗi Host Fingerprint chuẩn Ed25519 để người quản trị đối chiếu trước khi kết nối từ laptop. Bạn có thể bấm vào ảnh để phóng to.

Bước 3: Kết nối SSH từ máy tính macOS hoặc Linux

Sau khi đã sẵn sàng, hãy thay thế cụm chữ IP_LAB bằng địa chỉ IP thực tế của VPS và trỏ đúng đường dẫn tới file Private Key trên máy của bạn (tuyệt đối đừng copy-paste nguyên xi chữ IP_LAB rồi hỏi sao máy báo lỗi không tìm thấy host nhé!):

ssh -i ~/.ssh/localhost-lab -o IdentitiesOnly=yes root@IP_LAB

Nếu máy chủ của bạn đã được đổi cổng SSH sang một con số khác ngoài cổng 22 mặc định, hãy thêm tham số -p SO_CONG vào câu lệnh. Một mẹo cực hay dành cho anh em quản lý nhiều server: tùy chọn -o IdentitiesOnly=yes sẽ ra lệnh cho trình khách SSH chỉ sử dụng đúng chiếc khóa bạn chỉ định sau cờ -i, thay vì đem cả chục chiếc khóa đang nạp sẵn trong bộ nhớ ssh-agent ra thử lần lượt từng cái một cho đến khi bị server khóa cửa vì tội thử sai quá số lần quy định (Too many authentication failures)!

Khi gõ Passphrase để mở khóa (nếu có), màn hình Terminal sẽ đứng im không hiện dấu sao (*) nào cả — đó là tính năng bảo mật mặc định của Unix/Linux chứ không phải bàn phím của bạn bị liệt đâu, cứ gõ đúng rồi nhấn Enter. Ngoài ra, trên macOS và Linux, nếu bạn gặp thông báo lỗi kinh điển WARNING: UNPROTECTED PRIVATE KEY FILE! Permissions 0644 for '...' are too open, nguyên nhân là do OpenSSH từ chối sử dụng một chiếc chìa khóa mà ai trên máy cũng đọc được. Hãy khóa chặt quyền truy cập file Private Key chỉ cho riêng tài khoản của bạn bằng lệnh chmod:

chmod 600 ~/.ssh/localhost-lab

Chỉ chạy chmod 600 trên đúng file khóa cần thiết, tuyệt đối không chạy đệ quy (-R) lên toàn bộ thư mục nhà ($HOME) của bạn.

Bước 4: Kết nối SSH từ Windows PowerShell

Nếu bạn đang ngồi trên máy tính chạy Windows, hãy mở PowerShell và sử dụng biến môi trường $env:USERPROFILE để trỏ tới thư mục chứa khóa trong hồ sơ người dùng của bạn:

ssh -i "$env:USERPROFILE\.ssh\localhost-lab" -o IdentitiesOnly=yes root@IP_LAB

Cặp dấu ngoặc kép "..." bao quanh đường dẫn là chiêu thức bảo vệ cực kỳ quan trọng trên Windows, giúp câu lệnh không bị đứt gãy nếu tên tài khoản Windows của bạn có chứa dấu cách (ví dụ C:\Users\Nguyen Van A\...). Trong trường hợp OpenSSH trên Windows phàn nàn về quyền truy cập file khóa quá rộng, bạn cần chỉnh lại danh sách kiểm soát truy cập (ACL) trên hệ thống tập tin NTFS theo hướng dẫn của Microsoft (vì lệnh chmod 600 là của thế giới POSIX/Linux, không áp dụng trực tiếp cho phân quyền NTFS của Windows).

Nguyên tắc vàng khi chẩn đoán lỗi Permission denied (publickey): luôn kiểm tra bộ ba IP + User + Private Key trên máy khách trước khi nghi ngờ cấu hình trên Server.

Bằng chứng thực nghiệm kết nối từ Windows sang Ubuntu (Ngày 05/10/2026)

Để kiểm chứng thực tế quy trình kết nối từ môi trường Windows, vào ngày 05/10/2026 chúng tôi đã thực hiện kết nối từ máy trạm WIN03 (chạy Windows Server 2022 Trial, build 20348.169 với trình khách OpenSSH_for_Windows_8.1p1) sang máy chủ đích LAB03 chạy Ubuntu. Tất nhiên, số liệu dưới đây phản ánh chính xác môi trường thử nghiệm Windows Server đó.

Một cặp khóa chuẩn Ed25519 mới được sinh ra trực tiếp ngay trên máy WIN03 (file Private Key nằm cố định tại Windows, hoàn toàn không sao chép đi đâu khác). Phần Public Key khi gắn vào máy chủ Linux LAB03 được thiết lập giới hạn chặt chẽ chỉ chấp nhận kết nối xuất phát từ đúng địa chỉ IP của WIN03 kèm cờ restrict (tắt toàn bộ quyền chuyển tiếp cổng và PTY thừa). Phiên kiểm chứng gọi thực thi từ xa câu lệnh hostname để lấy tên máy chủ.

Ở tầng thương lượng nhận diện máy chủ, trình khách đã chọn thuật toán khóa máy chủ ECDSA. Trước khi chấp nhận lưu khóa lần đầu tiên, dấu vân tay (Fingerprint) đã được đối chiếu khớp 100% với file Public Host Key chuẩn ECDSA đọc từ kênh quản trị đã xác thực của chính chiếc LAB03. Một lưu ý kỹ thuật rất đáng nhớ: khi đối chiếu Host Fingerprint, bạn phải so sánh cùng một thuật toán khóa (ECDSA so với ECDSA, Ed25519 so với Ed25519), chứ không thể lấy mã băm Ed25519 đi so với mã băm ECDSA được!

Một chi tiết nhỏ rất thú vị trong quá trình thực nghiệm: ở lần gõ lệnh kết nối đầu tiên, khi màn hình đang dừng lại chờ người dùng gõ chữ xác nhận lưu Host Key thì kết nối bị đóng do hết thời gian chờ (Timeout) của phiên. Ở lần chạy ngay sau đó, khi khóa máy chủ đã được xác nhận lưu vào danh bạ, kết nối đi thẳng vào trong và trả kết quả mượt mà trong tích tắc. Việc ghi chép trung thực cả hiện tượng đóng kết nối khi chờ xác nhận lần đầu giúp bạn hiểu rằng không phải cứ thấy ngắt kết nối là vội vàng đổ lỗi cho hỏng Private Key hay tường lửa chặn!

Bước 5: Xác nhận danh tính ngay sau khi bước chân vào Server

Ngay khi màn hình Terminal chuyển sang dấu nhắc của máy chủ từ xa, đừng vội chạy lệnh cài đặt phần mềm ngay. Hãy gõ tổ hợp 3 lệnh đọc thông tin cơ bản dưới đây để biết chắc chắn 100% mình đang là ai và đang đứng ở đâu:

whoami
hostname
cat /etc/os-release

Hãy đối chiếu tên tài khoản trả về từ whoami, tên máy chủ từ hostname và thông tin hệ điều hành từ /etc/os-release xem có khớp hoàn toàn với chiếc VPS lab của bạn hay không. Trên chiếc LAB-CF-01, chúng tôi cũng đã đăng nhập bằng SSH Key vào môi trường Ubuntu 24.04 và xác minh đầy đủ các bước này trước khi chuyển sang các bài cấu hình chuyên sâu.

Bắt bệnh nhanh 3 lỗi SSH kinh điển trước khi đụng vào cấu hình Server

Khi gõ lệnh SSH mà không vào được máy, bạn hãy nhìn kỹ dòng thông báo lỗi cuối cùng trên màn hình để khoanh vùng đúng chỗ ngứa:

• Lỗi Connection timed out (Hết thời gian chờ): Gói tin của bạn đi mãi không thấy hồi âm. Hãy kiểm tra ngay xem mình có gõ sai địa chỉ IP không, VPS trên Panel đã bật (ACTIVE) chưa, mạng Internet chỗ bạn có chặn cổng không, hoặc tường lửa (Firewall / UFW / Cloud Firewall) có đang khóa chặt cổng SSH hay không.
• Lỗi Connection refused (Từ chối kết nối): Gói tin đã chạm tới đích nhưng bị hất văng ra ngay lập tức. Thường là do dịch vụ sshd trên máy chủ chưa chạy, hoặc SSH đang lắng nghe ở một cổng khác với cổng bạn gõ trong lệnh.
• Lỗi Permission denied (publickey) (Từ chối quyền truy cập): Mạng đã thông, cổng đã mở, dịch vụ SSH đã tiếp chuyện bạn nhưng… chìa khóa không mở được ổ! Hãy rà soát lại đúng bộ ba: gõ đúng tên User chưa (root hay ubuntu)? Trỏ đúng file Private Key khớp với Public Key trên server chưa? Và phân quyền thư mục ~/.ssh (700) cùng file authorized_keys (600) trên server có bị sai không?

Riêng khi gặp bảng cảnh báo chữ hoa WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!, hãy dừng lại suy nghĩ: nếu bạn vừa mới cài lại hệ điều hành (Rebuild VPS) trên cùng địa chỉ IP đó thì việc khóa máy chủ thay đổi là hoàn toàn hợp lý; nhưng nếu bạn không hề cài lại máy mà tự dưng thấy cảnh báo này, hãy vào Web Console kiểm tra lại Host Fingerprint ngay lập tức trước khi xóa dòng khóa cũ trong known_hosts.

Cây chẩn đoán nhanh sự cố SSH: đọc đúng thông báo lỗi sẽ giúp bạn tiết kiệm hàng giờ đồng hồ mò mẫm sửa nhầm chỗ.

Thoát phiên làm việc an toàn và lộ trình bước tiếp theo

Khi muốn ngắt kết nối SSH để quay về máy tính cá nhân, bạn chỉ cần gõ lệnh exit (hoặc nhấn tổ hợp phím Ctrl + D). Lưu ý một điều hết sức hiển nhiên nhưng người mới đôi khi vẫn nhầm: gõ exit chỉ là đóng cánh cửa kết nối từ xa, còn chiếc VPS trên mây vẫn đang chạy ầm ầm và vẫn tính phí theo giờ như thường!

Để vận hành máy chủ lâu dài một cách chuyên nghiệp, ở các bài tiếp theo chúng ta sẽ tạo một tài khoản quản trị riêng có quyền sudo và kiểm chứng bằng một cửa sổ SSH thứ hai trước khi khóa cửa tài khoản root. Nguyên tắc sống còn: chưa thử thông suốt đường vào mới thì tuyệt đối không được đóng cánh cửa cũ!

Câu hỏi thường gặp (FAQ): Nếu có thêm đồng nghiệp cùng tham gia quản trị VPS thì làm sao? Hãy bảo người đó tự tạo cặp khóa SSH trên máy của họ rồi gửi phần Public Key (.pub) cho bạn gắn thêm vào server — tuyệt đối không bao giờ gửi file Private Key của bạn qua Zalo/Telegram để dùng chung! Và nếu chẳng may SSH có hỏi mật khẩu user Linux, đừng bao giờ gõ mật khẩu tài khoản quản trị CloudFly của bạn vào đó nhé.

Tài liệu tham khảo chuẩn quốc tế (đối chiếu ngày 30/09/2026): OpenSSH Manual (ssh), Ubuntu Server OpenSSH Documentation, và Microsoft Learn: OpenSSH for Windows.

Cùng chuỗi bài học: Xem toàn bộ Lộ trình cài đặt WordPress trên VPS từ A đến Z.