Tạo SSH key từ Windows, Linux hoặc macOS, xác minh host key và kiểm tra phiên đăng nhập mới trước khi hạn chế đăng nhập mật khẩu trên Ubuntu Server.
Một phiên SSH đang mở không bảo đảm bạn có thể đăng nhập lại sau khi sửa cấu hình. Với người mới quản trị server, mục tiêu của bài này là tạo đường truy cập bằng key, xác minh đúng máy đích và thử phiên mới trước khi siết phương thức đăng nhập. Ví dụ dùng Ubuntu Server 24.04 LTS và tài khoản labadmin.
Bạn cần IP hoặc hostname của server, tài khoản đăng nhập hợp lệ, quyền sudo và console từ hypervisor hoặc nhà cung cấp VPS. Không bắt đầu tắt đăng nhập mật khẩu nếu console chưa sử dụng được. Giữ phiên quản trị hiện tại mở trong suốt quá trình, đồng thời chuẩn bị một cửa sổ terminal thứ hai để thử.
Trên Windows, dùng Windows Terminal với OpenSSH client đã cài. Windows Terminal là giao diện chứa PowerShell hoặc shell khác; bản thân ứng dụng này không thay thế SSH client. Kiểm tra ssh -V. Trên Linux/macOS, dùng Terminal và kiểm tra cùng lệnh. Nếu máy thuộc tổ chức có yêu cầu key phần cứng hay xác thực nhiều yếu tố, làm theo chính sách đó thay vì áp dụng nguyên mẫu bên dưới.
Theo Ubuntu OpenSSH Server, cần kiểm tra cấu hình trước khi áp dụng để tránh tự khóa truy cập. Tài liệu OpenSSH giúp tra tùy chọn; hãy đối chiếu thêm man ssh và man sshd_config trên phiên bản đang dùng.
Host key thuộc máy chủ, giúp client xác minh máy mà mình đang kết nối. Key đăng nhập thuộc người dùng: private key ở máy quản trị, public key được cho phép trên server. Hai vai trò này khác nhau, dù đều liên quan tới mật mã bất đối xứng.
Khi kết nối lần đầu, SSH hỏi bạn có chấp nhận fingerprint của host key hay không. Mở console của server và lấy fingerprint trực tiếp:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
Đối chiếu đúng loại key và fingerprint được client hiển thị. Nếu máy không có host key Ed25519, dùng public host key tương ứng được cấu hình. Không chấp nhận tự động chỉ vì IP quen thuộc. IP có thể được cấp lại; một server cài mới cũng có host key mới.
Khi thấy cảnh báo host key thay đổi, xác minh việc cài lại, thay key hoặc đổi máy qua kênh quản trị tin cậy. Không xóa known_hosts hàng loạt để bỏ cảnh báo. Sau khi xác minh đúng sự kiện thay key, mới xóa đúng bản ghi bằng ssh-keygen -R với tên hoặc IP liên quan, rồi kết nối và đối chiếu lại.
Chạy trên client, không chạy trên server đích:
ssh-keygen -t ed25519 -f ~/.ssh/linux_lab_ed25519 -C "linux-lab-admin"
Chọn passphrase để bảo vệ private key khi file bị sao chép. Lệnh tạo hai file: linux_lab_ed25519 là private key và file đuôi .pub là public key. Không gửi private key qua email, ticket hoặc dán vào phần quản trị web. Public key được phép đưa vào danh sách key đăng nhập nhưng vẫn nên quản lý nguồn gốc và chủ sở hữu.
Trên PowerShell, nếu cách mở rộng ~ của công cụ gây khó hiểu, dùng đường dẫn rõ ràng:
ssh-keygen -t ed25519 -f "$env:USERPROFILE\.ssh\linux_lab_ed25519" -C "linux-lab-admin"
Get-Content "$env:USERPROFILE\.ssh\linux_lab_ed25519.pub"
Kiểm tra file đã tồn tại trước khi tạo. Không xác nhận ghi đè key cũ nếu chưa biết nó đang được dùng cho hệ thống nào. Với tổ chức yêu cầu thuật toán khác hoặc FIPS, kiểm tra chính sách và hỗ trợ của các phía; không mặc định Ed25519 phù hợp mọi môi trường.
Trên Linux/macOS có ssh-copy-id, dùng:
ssh-copy-id -i ~/.ssh/linux_lab_ed25519.pub labadmin@SERVER_IP
Thay SERVER_IP bằng IP thật của lab. Công cụ cần một phương thức đăng nhập hiện đang hoạt động. Windows thường không có sẵn ssh-copy-id; bạn có thể đọc file .pub, rồi dùng console hoặc phiên SSH hiện tại để thêm nguyên một dòng public key vào ~/.ssh/authorized_keys của labadmin.
Trên server, khi đang đăng nhập đúng tài khoản cần nhận key:
install -d -m 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
ls -ld ~ ~/.ssh
ls -l ~/.ssh/authorized_keys
Chỉ thêm dòng public key, không xóa các key hợp lệ đã có. Kiểm tra key không bị xuống dòng giữa chừng và file thuộc đúng user. Thư mục home, .ssh hoặc authorized_keys có quyền ghi quá rộng có thể khiến sshd không chấp nhận key. Không dùng sudo một cách máy móc vì có thể vô tình tạo file thuộc root trong home của người dùng.
Nếu thao tác bằng console root để cấp key cho user khác, cần đặt owner và group phù hợp theo id labadmin. Đừng giả định primary group luôn trùng tên user trong mọi môi trường có LDAP hoặc cấu hình tùy chỉnh.
Mở terminal mới trên client:
ssh -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -o PasswordAuthentication=no -i ~/.ssh/linux_lab_ed25519 labadmin@SERVER_IP
Yêu cầu passphrase của private key là bình thường. Nó khác với mật khẩu của tài khoản trên server. Tùy chọn trên giúp tránh hiểu nhầm rằng đăng nhập đã dùng key trong khi client lặng lẽ chuyển sang mật khẩu.
Sau khi vào, chạy whoami, id và sudo -v. Lệnh cuối có thể yêu cầu mật khẩu sudo tùy policy; đó là bước nâng quyền, không chứng minh SSH vừa dùng mật khẩu. Thử thoát phiên mới và đăng nhập lại lần nữa. Phiên cũ vẫn giữ nguyên để xử lý nếu có lỗi.
Nếu không thành công, dùng ssh -vv trên client để xem key nào được đề nghị. Log có thể chứa hostname và tên tài khoản, vì vậy lọc thông tin trước khi chia sẻ. Trên server, đọc sudo journalctl -u ssh --since '-10 minutes' --no-pager. Với hệ thống ghi log theo cách khác, đối chiếu log xác thực tương ứng thay vì mặc định luôn có /var/log/auth.log.
Trước khi sửa, lưu bản cấu hình và xem các file được include:
sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.before-lab
sudo ls -l /etc/ssh/sshd_config.d
sudo sshd -T | grep -E 'passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|permitrootlogin'
OpenSSH thường dùng giá trị được thiết lập đầu tiên cho một tùy chọn. Thứ tự include, các file cloud-init và khối Match có thể làm giá trị hiệu lực khác điều bạn vừa thêm. Đọc cấu hình hiện tại trước khi chọn file drop-in; không coi một tên file cố định là luôn ghi đè được mọi nguồn khác.
Với lab không dùng MFA qua keyboard-interactive, cấu hình mục tiêu là:
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
Không tắt keyboard-interactive khi cơ chế MFA hợp lệ đang phụ thuộc vào nó. Thay đổi này có thể chặn người quản trị khác nếu họ chưa có phương thức truy cập tương ứng. Xác nhận nhu cầu của mọi tài khoản được quản lý trước khi áp dụng lên server dùng chung.
Kiểm tra cú pháp và giá trị hiệu lực, rồi reload:
sudo sshd -t
sudo sshd -T | grep -E 'passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|permitrootlogin'
sudo systemctl reload ssh
Chỉ reload nếu sshd -t thành công. Với cấu hình có Match, cần dùng sshd -T -C với user, địa chỉ client và hostname đúng để kiểm tra bối cảnh liên quan. Reload làm dịch vụ đọc lại cấu hình; phiên đang tồn tại thường tiếp tục, nhưng bạn vẫn phải giữ console vì cấu hình mới có thể chặn phiên kế tiếp.
Permission denied (publickey): kiểm tra đúng user, key, owner, mode và dòng public key; đối chiếu key fingerprint. Đăng nhập nhầm root thay vì user được nhà cung cấp cấp là lỗi thường gặp.
Connection refused: đọc listener bằng ss -lntp từ console và kiểm tra unit ssh/ssh.socket. Chưa nên thay key vì lỗi có thể xảy ra trước giai đoạn xác thực.
Timeout: kiểm tra IP, route, port forwarding, firewall máy chủ và firewall nhà cung cấp. Không tắt tất cả firewall để thử vì có thể phơi dịch vụ khác ra mạng.
Mất quyền sau thay đổi: vào console, khôi phục đúng file đã chỉnh sửa, kiểm tra sshd -t, rồi reload. Bản sao của file chính không tự khôi phục các drop-in mới tạo; phải xử lý cả những file đó.
Hoàn thành khi phiên mới đăng nhập bằng key được, sudo đúng policy, phương thức không còn cho phép đã bị từ chối và console vẫn hoạt động. Ghi lại fingerprint cùng vị trí lưu key; không ghi passphrase hay private key vào biên bản.
Nếu quản trị nhiều server, dùng file cấu hình client để gắn rõ hostname, user và key cho từng máy. Việc này giảm nhầm tài khoản nhưng không thay thế xác minh máy đích. Không đặt cấu hình vô hiệu hóa kiểm tra host key cho mọi host. Khi thu hồi một key, xác định tất cả tài khoản và máy đã cho phép public key đó, rồi xóa đúng dòng liên quan.
Key có passphrase vẫn cần được bảo vệ trên máy client. SSH agent có thể giúp giảm số lần nhập nhưng cần hiểu thời gian key được nạp và rủi ro agent forwarding. Bài nhập môn không yêu cầu bật forwarding; chỉ sử dụng khi có nhu cầu và chính sách rõ ràng.
Xem thêm Linux Essentials nếu cần ôn kiến thức nền trước khi thực hành.
Tạo tài khoản quản trị, user dịch vụ và thư mục dùng chung trên Ubuntu; chẩn đoán Permission denied theo user, đường dẫn, mode và chính sách truy cập.
Hiểu repository, cài và cập nhật gói trên Ubuntu Server, kiểm tra sau thay đổi và xử lý lỗi lock, DNS hoặc chữ ký mà không bỏ qua cơ chế xác minh.
Thực hành tạo systemd service trên Ubuntu, kiểm tra trạng thái, restart, reload và tự khởi động; tìm lỗi từ user, đường dẫn, quyền và log của dịch vụ.
Lọc log Linux theo service, thời gian và boot; phân biệt lỗi gốc với thông báo hệ quả, kiểm tra quyền đọc và xác nhận phục hồi sau khi sửa nguyên nhân.