Bật SSH trên Ubuntu: cài OpenSSH Server và tăng cường bảo mật

Bật SSH trên Ubuntu: cài đặt, khởi động, mở tường lửa

SSH trên Ubuntu đến từ gói openssh-server. Ubuntu Server đề nghị cài nó trong quá trình cài đặt, và gần như mọi image cloud hay VPS đều kèm sẵn và đang lắng nghe; Ubuntu Desktop thì hoàn toàn không cài.

1. Cài openssh-server

sudo apt update
sudo apt install -y openssh-server

Nếu gói đã có sẵn, apt sẽ báo như vậy và không thay đổi gì. Bước cài đặt cũng đăng ký một hồ sơ ứng dụng UFW tên OpenSSH, được dùng ở bước 3.

2. Bật và khởi động dịch vụ

sudo systemctl enable --now ssh
systemctl status ssh

Trên Ubuntu, unit có tên ssh; sshd là tên bí danh. enable --now khởi động daemon ngay lập tức và ở mỗi lần khởi động máy. Từ Ubuntu 22.10, sshd được kích hoạt qua socket: ssh.socket giữ cổng 22 và khởi động ssh.service khi có kết nối đến đầu tiên, nên trạng thái inactive (dead) kèm TriggeredBy: ssh.socket ngay sau khi cài là bình thường. Cổng vẫn đang mở. Để có cái nhìn tổng quát hơn, xem bài liệt kê dịch vụ bằng systemctl.

3. Cho phép SSH qua UFW

Ubuntu được cài với UFW ở trạng thái tắt. Nếu bạn bật nó, hãy cho phép SSH trước; bật tường lửa khi chưa có quy tắc là cách kinh điển để tự khóa mình khỏi một máy từ xa.

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

ufw allow OpenSSH dùng hồ sơ ứng dụng và mở cổng 22/tcp. Nếu sau này bạn chuyển sshd sang cổng khác, hãy cho phép cổng mới bằng sudo ufw allow 2222/tcp và xóa quy tắc cũ. Tìm địa chỉ của máy chủ bằng hostname -I.

Kết nối từ Windows, macOS hoặc Linux

Mọi hệ điều hành máy tính hiện nay đều có sẵn OpenSSH client, và cú pháp ở đâu cũng giống nhau:

ssh username@SERVER_IP
ssh -p 2222 username@SERVER_IP      # non-default port

• Windows 10 và 11: mở PowerShell hoặc Windows Terminal và gõ lệnh; OpenSSH client được tích hợp trong Windows từ năm 2018 (phiên bản 1809). Nếu ssh không được nhận diện, hãy thêm nó trong Settings > Apps > Optional features.
• macOS: Terminal, cùng một lệnh.
• Linux: bất kỳ terminal nào; openssh-client được cài mặc định trên Ubuntu.

Ở lần kết nối đầu tiên, chấp nhận dấu vân tay (fingerprint) khóa máy chủ bằng yes; nó được lưu trong ~/.ssh/known_hosts và bạn sẽ được cảnh báo nếu nó thay đổi. Sau đó nhập mật khẩu tài khoản. Phần tiếp theo sẽ thay mật khẩu bằng khóa.

Chuyển sang xác thực bằng khóa

Đăng nhập bằng mật khẩu là thứ các botnet dò (brute-force) suốt ngày đêm; khóa khiến những lần thử đó trở nên vô ích. Hãy tạo cặp khóa Ed25519 trên máy tính của chính bạn, không bao giờ trên máy chủ:

ssh-keygen -t ed25519 -C "laptop-2026"

Chấp nhận đường dẫn mặc định (~/.ssh/id_ed25519) và đặt passphrase; nó mã hóa khóa riêng trên ổ đĩa, và nhờ SSH agent bạn chỉ phải nhập một lần mỗi phiên. Chỉ tệp .pub mới rời khỏi máy của bạn.

Sao chép khóa công khai lên máy chủ

Trên macOS và Linux, ssh-copy-id làm việc này trong một bước, dùng mật khẩu của bạn lần cuối:

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@SERVER_IP

Bản OpenSSH cho Windows không có ssh-copy-id; thay vào đó hãy chuyển khóa qua bằng pipe từ PowerShell:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh username@SERVER_IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Cả hai cách đều thêm khóa vào ~/.ssh/authorized_keys của người dùng đó. Quyền truy cập rất quan trọng: sshd lặng lẽ bỏ qua tệp này khi ~/.ssh không ở chế độ 700 hoặc authorized_keys có thể bị ghi bởi bất kỳ ai ngoài chủ sở hữu. Từ một terminal mới, ssh username@SERVER_IP giờ sẽ đăng nhập mà không cần mật khẩu tài khoản. Đừng động đến phần tiếp theo cho đến khi việc này hoạt động.

Gia cố sshd_config: không mật khẩu, không root, chỉ người dùng trong danh sách cho phép

Hãy giữ phiên hiện tại mở trong khi chỉnh sửa; nếu cấu hình mới làm hỏng điều gì, đó là đường để bạn quay lại. /etc/ssh/sshd_config bắt đầu bằng Include /etc/ssh/sshd_config.d/*.conf, và sshd giữ giá trị đầu tiên nó đọc được cho mỗi từ khóa, nên một tệp drop-in sẽ thắng mọi thứ nằm phía dưới trong tệp chính. Hơn nữa, cloud image thường kèm sẵn /etc/ssh/sshd_config.d/50-cloud-init.conf với PasswordAuthentication yes, đó là lý do việc sửa tệp chính thường có vẻ không có tác dụng. Cách khắc phục là một tệp drop-in có tên được sắp xếp đứng đầu:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Dán nội dung sau, thay username bằng tên đăng nhập của bạn:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AllowUsers username
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

PermitRootLogin no giả định bạn có một tài khoản không đặc quyền với quyền sudo. Nếu đến giờ bạn vẫn làm việc bằng root, hãy tạo người dùng sudo trên Linux và sao chép khóa của bạn sang tài khoản đó trước khi áp dụng tệp. Sau đó kiểm tra cú pháp, tải lại, và xem các giá trị sshd thực sự dùng sau khi gộp mọi tệp include, đó chính là thứ sshd -T in ra:

sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|allowusers|port'

Mở terminal thứ hai và đăng nhập bằng khóa trước khi đóng terminal thứ nhất. Tác dụng của từng chỉ thị:

Keepalive cũng có ở phía client: ServerAliveInterval 60 trong ~/.ssh/config trên máy của bạn giúp router NAT không cắt các phiên đang rảnh.

Đổi cổng SSH không phải là bảo mật

Chuyển sshd khỏi cổng 22 là lời khuyên phổ biến. Thứ bạn nhận được là ít dòng nhật ký hơn. Các máy quét hàng loạt quét toàn bộ 65.535 cổng và tìm ra sshd trên cổng 2222 trong vòng vài giờ; bất kỳ ai nhắm vào bạn sẽ tìm ra nó trong vài giây bằng nmap. Khóa, chặn đăng nhập root, danh sách cho phép và fail2ban mới là bảo mật; cổng chỉ mang tính hình thức. Nó vẫn hữu ích trên máy chủ bận rộn vì giữ cho nhật ký xác thực dễ đọc; chỉ đừng bao giờ coi nó là một lớp phòng thủ.

Nếu bạn vẫn đổi, hãy làm theo thứ tự: mở cổng mới trong UFW, đổi cổng, khởi động lại, thử từ terminal thứ hai, rồi xóa quy tắc cũ. Bỏ dấu chú thích ở #Port 22 trong /etc/ssh/sshd_config, đặt cổng mới, rồi:

sudo ufw allow 2222/tcp
sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket    # Ubuntu 22.10 and later
sudo systemctl restart ssh           # Ubuntu 22.04 and earlier

Trên các bản phát hành kích hoạt qua socket, chính unit socket chứ không phải sshd quyết định cổng nào được dùng; Ubuntu kèm sẵn một systemd generator đọc Port từ cấu hình sshd trong lúc daemon-reload và cập nhật ssh.socket. Xác nhận bằng sudo ss -tlnp | grep sshd. Bài kiểm tra cổng đang mở trên Linux giải thích kết quả. Nếu sshd vẫn cứng đầu ở cổng 22, hãy tắt kích hoạt qua socket và để dịch vụ tự giữ cổng: sudo systemctl disable --now ssh.socket && sudo systemctl enable --now ssh.service. Khi ssh -p 2222 hoạt động từ một terminal mới, chạy sudo ufw delete allow OpenSSH.

Thêm fail2ban và cân nhắc xác thực hai yếu tố

Khi mật khẩu đã bị tắt, dò mật khẩu không thể thành công, nhưng mỗi lần thử vẫn tốn một tiến trình fork và một dòng nhật ký. fail2ban theo dõi nhật ký xác thực và cấm các địa chỉ thất bại liên tục:

sudo apt install -y fail2ban
sudo nano /etc/fail2ban/jail.local

Đưa nội dung này vào tệp:

[sshd]
enabled = true
port = ssh
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Đừng bao giờ sửa jail.conf; tệp này bị thay thế khi nâng cấp và jail.local sẽ ghi đè nó. port = ssh được phân giải qua /etc/services, nên hãy viết port = 2222 nếu bạn đã chuyển daemon. backend = systemd đọc trực tiếp journal và hoạt động bất kể image của bạn có ghi /var/log/auth.log hay không. fail2ban-client status sshd liệt kê các địa chỉ bị cấm; sudo fail2ban-client set sshd unbanip 203.0.113.7 bỏ cấm một địa chỉ. Mặc định các quy tắc của fail2ban được xét trước quy tắc của UFW, nên hai công cụ cùng tồn tại được.

Xác thực hai yếu tố

Khi khóa cộng passphrase vẫn chưa đủ, libpam-google-authenticator thêm một mã theo thời gian bên trên khóa: cài nó, chạy google-authenticator bằng người dùng đăng nhập, thêm auth required pam_google_authenticator.so vào /etc/pam.d/sshd (và chú thích dòng @include common-auth trong đó), rồi đặt KbdInteractiveAuthentication yes và AuthenticationMethods publickey,keyboard-interactive trong sshd. Một lợi ích thực sự khi laptop bị đánh cắp, và cũng thêm một thứ có thể bị mất: hãy cất các mã dự phòng (scratch code) ở ngoài máy chủ.

Khắc phục sự cố: connection refused, timed out, permission denied

Connection refused (kết nối bị từ chối)

Máy chủ có phản hồi nhưng không có gì lắng nghe trên cổng đó: sshd đã dừng, đang giữ cổng khác, hoặc bạn gõ sai cổng. Từ console của nhà cung cấp, chạy systemctl status ssh và sudo ss -tlnp | grep ssh. Một lỗi cú pháp khiến sshd không khởi động được; sudo sshd -t in ra dòng gây lỗi và journalctl -u ssh -n 50 cho thấy lần khởi động gần nhất.

Connection timed out (hết thời gian kết nối)

Gói tin bị loại bỏ chứ không bị từ chối, điều này gần như luôn có nghĩa là tường lửa: UFW thiếu quy tắc cho phép (sudo ufw status verbose), một security group trong bảng điều khiển của nhà cung cấp, hoặc chính mạng của bạn chặn cổng 22 chiều đi (thử qua điểm phát sóng điện thoại để loại trừ khả năng này). ssh -v username@SERVER_IP cho thấy quá trình bắt tay bị kẹt ở đâu.

Permission denied (publickey)

Máy chủ truy cập được và đang từ chối bạn. Hãy kiểm tra theo thứ tự: tên người dùng, authorized_keys của người dùng đó có chứa khóa bạn đang dùng không (ssh -i ~/.ssh/id_ed25519 -v buộc dùng một khóa cụ thể), quyền trên ~/.ssh, và tên đăng nhập có bị thiếu trong AllowUsers không. Trên máy chủ, journalctl -u ssh -n 30 nêu rõ lý do; Authentication refused: bad ownership or modes là vấn đề quyền truy cập đã mô tả ở trên.

Cảnh báo khóa máy chủ

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED sau khi cài lại máy là điều bình thường: chạy ssh-keygen -R SERVER_IP và kết nối lại. Nếu bạn không cài lại gì cả, hãy tìm hiểu nguyên nhân trước khi gõ mật khẩu ở bất cứ đâu. Bị khóa ngoài hoàn toàn? Console của nhà cung cấp là đường quay lại.

Mọi thứ ở trên đều giả định một máy mà bạn có quyền root và có thể làm hỏng sshd rồi sửa lại từ console. Một VPS Linux từ rdp.monster chính là chiếc máy đó: toàn quyền root, CPU và RAM riêng, băng thông không giới hạn (sử dụng hợp lý), không cần KYC, thanh toán bằng crypto hoặc tiền pháp định, từ $8.99/tháng, và máy chủ trực tuyến trong khoảng 10 giây sau khi thanh toán được xác nhận, dư thời gian để đặt khóa xong trước khi máy quét đầu tiên tìm thấy cổng 22.

Câu hỏi thường gặp

Ubuntu có bật sẵn SSH theo mặc định không?

Ubuntu Desktop thì không; Ubuntu Server và phần lớn cloud image thì có.

Ubuntu Desktop chỉ cài SSH client, nên không có gì lắng nghe trên cổng 22 cho đến khi bạn chạy sudo apt install openssh-server. Ubuntu Server hỏi trong lúc cài đặt có cài OpenSSH server không và có thể nhập khóa GitHub hoặc Launchpad của bạn cùng lúc. Các image cloud và VPS gần như luôn kèm openssh-server đã cài, đã bật và đang nhận kết nối, vì đó là cách duy nhất để nhà cung cấp bàn giao máy cho bạn. Kiểm tra bằng systemctl status ssh.

Làm sao kiểm tra SSH có đang chạy trên Ubuntu không?

Chạy systemctl status ssh, rồi xác nhận cổng 22 đang lắng nghe bằng ss.

systemctl status ssh cho biết dịch vụ đang hoạt động hay đã được bật. Vì Ubuntu 22.10 trở đi dùng kích hoạt qua socket, dịch vụ có thể hiển thị inactive (dead) kèm TriggeredBy: ssh.socket một cách hoàn toàn bình thường khi không ai kết nối, nên phép thử đáng tin hơn là sudo ss -tlnp | grep ssh: một dòng hiển thị 0.0.0.0:22 hoặc [::]:22 nghĩa là SSH đang lắng nghe. Từ một máy khác, ssh -v username@SERVER_IP xác nhận toàn bộ đường kết nối.

Để SSH ở cổng 22 có an toàn không?

Có, miễn là mật khẩu đã bị tắt và dùng khóa; số cổng không mang lại sự bảo vệ nào.

Cổng 22 liên tục hứng các lần thử đăng nhập tự động, nhưng những lần thử đó không thể thành công trước một máy chủ có PasswordAuthentication no và một cặp khóa, và fail2ban loại bỏ phần lớn nhiễu. Chuyển sshd sang 2222 hoặc 22222 chỉ giấu nó khỏi những máy quét lười nhất; các công cụ quét cổng như nmap và masscan tìm ra nó trong vài phút, và các chỉ mục quét toàn Internet vẫn liệt kê nó. Hãy coi cổng không mặc định là biện pháp giữ nhật ký gọn gàng, không phải biện pháp bảo mật, và đừng bao giờ bỏ qua khóa chỉ vì đã đổi cổng.

ssh và sshd trên Ubuntu khác nhau thế nào?

ssh là chương trình client; sshd là daemon máy chủ, có unit trên Ubuntu tên ssh với sshd là tên bí danh.

ssh là client bạn chạy trên laptop để mở kết nối; nó đến từ gói openssh-client. sshd là daemon phản hồi trên máy chủ, đến từ openssh-server, được cấu hình trong /etc/ssh/sshd_config (client đọc ssh_config). Ubuntu và Debian đặt tên unit systemd là ssh.service và khai báo sshd.service là bí danh, nên systemctl restart ssh và systemctl restart sshd làm cùng một việc; trên Fedora, RHEL và Arch unit đơn giản có tên sshd.