Lỗi Gặp Phải
Bạn chạy một lệnh SSH thông thường và nhận được thông báo:
$ ssh user@192.168.1.100
ssh: connect to host 192.168.1.100 port 22: Connection refused
Không có timeout, không có prompt nhập mật khẩu — chỉ là từ chối kết nối ngay lập tức. Server vẫn phản hồi ping bình thường, nhưng SSH đóng sập cửa. Sự từ chối tức thì này thực ra là một tín hiệu hữu ích: hệ điều hành đang chủ động từ chối kết nối, giúp thu hẹp nguyên nhân xuống còn một trong ba thủ phạm: sshd không chạy, tường lửa đang chặn cổng 22, hoặc SSH đã chuyển sang cổng không chuẩn.
Chẩn Đoán Trước
Đừng bắt đầu thay đổi mọi thứ một cách mù quáng. Hai kiểm tra nhanh từ phía client sẽ cho bạn biết rất nhiều:
# Kiểm tra xem cổng 22 có mở không
nc -zv 192.168.1.100 22
# Hoặc dùng nmap nếu nc không có sẵn
nmap -p 22 192.168.1.100
Connection refused từ nc có nghĩa là cổng đang bị đóng chủ động — chính hệ điều hành đang gửi lại gói TCP RST. Điều này khác với kiểu drop âm thầm (gây ra timeout). Một tường lửa drop gói âm thầm sẽ treo khoảng 30–60 giây trước khi từ bỏ. Từ chối ngay lập tức có nghĩa là có điều gì đó khác đang xảy ra.
Nếu bạn có quyền truy cập console hoặc VNC vào server, hãy chạy thêm:
# Kiểm tra cái gì đang lắng nghe trên cổng 22
ss -tlnp | grep 22
# Hoặc trên các hệ thống cũ hơn
netstat -tlnp | grep 22
Cách Sửa 1: SSH Daemon Không Chạy
Chín trong mười trường hợp, đây chính là nguyên nhân. Dịch vụ sshd bị crash, chưa bao giờ được bật, hoặc bị lỗi âm thầm sau khi thay đổi cấu hình.
# Kiểm tra trạng thái dịch vụ
sudo systemctl status sshd
# Trên một số distro tên là ssh thay vì sshd
sudo systemctl status ssh
Nếu hiện thị inactive hoặc failed, hãy khởi động nó:
# Khởi động ngay lập tức
sudo systemctl start sshd
# Bật để tự khởi động khi reboot
sudo systemctl enable sshd
Nếu dịch vụ từ chối khởi động, log sẽ cho bạn biết lý do:
sudo journalctl -u sshd -n 50 --no-pager
Các nguyên nhân thường gặp: lỗi đánh máy trong /etc/ssh/sshd_config, thiếu host keys (thường xảy ra sau khi migration bị lỗi), hoặc một tiến trình khác đang chiếm cổng 22. Hãy sửa vấn đề gốc rễ, rồi khởi động lại dịch vụ.
Cách Sửa 2: Tường Lửa Đang Chặn Cổng 22
sshd có thể đang chạy bình thường trong khi một quy tắc tường lửa âm thầm chặn mọi kết nối đến. Hãy kiểm tra tường lửa trước.
UFW (Ubuntu/Debian)
# Kiểm tra các quy tắc hiện tại
sudo ufw status
# Cho phép SSH
sudo ufw allow ssh
# Hoặc chỉ định rõ theo cổng
sudo ufw allow 22/tcp
firewalld (CentOS/RHEL/Fedora)
# Kiểm tra xem dịch vụ SSH có được cho phép không
sudo firewall-cmd --list-services
# Thêm SSH vĩnh viễn
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload
iptables (quy tắc thô)
# Kiểm tra các quy tắc hiện có
sudo iptables -L INPUT -n -v
# Cho phép cổng 22
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Lưu quy tắc (Debian/Ubuntu)
sudo iptables-save | sudo tee /etc/iptables/rules.v4
Cách Sửa 3: SSH Đang Lắng Nghe Trên Cổng Khác
Nhiều server được bảo mật tốt sẽ chuyển SSH ra khỏi cổng 22 để giảm tiếng ồn từ các trình quét tự động. Cổng 2222 là một lựa chọn phổ biến. Hãy tìm hiểu cổng nào mà sshd đang thực sự sử dụng:
# Kiểm tra cổng được cấu hình (chạy lệnh này trên server)
sudo grep -i ^Port /etc/ssh/sshd_config
Không có output có nghĩa là vẫn đang dùng cổng mặc định 22. Nếu bạn thấy một số khác, hãy kết nối với tùy chọn -p:
ssh -p 2222 user@192.168.1.100
Chán phải gõ cổng mỗi lần? Thêm một mục host vào ~/.ssh/config trên client của bạn:
Host myserver
HostName 192.168.1.100
User user
Port 2222
Sau đó, chỉ cần ssh myserver là đủ.
Cách Sửa 4: SSH Chưa Được Cài Đặt Trên Server
Các container mới và bản cài đặt server tối giản thường bỏ qua OpenSSH hoàn toàn. Đáng để kiểm tra nếu không có gì khác giải thích được lỗi từ chối này.
# Debian/Ubuntu
sudo apt update && sudo apt install openssh-server -y
# CentOS/RHEL
sudo dnf install openssh-server -y
# Khởi động và bật trong một lệnh duy nhất
sudo systemctl enable --now sshd
Xác Minh
Sau khi áp dụng bất kỳ cách sửa nào, hãy xác nhận cổng 22 đang chấp nhận kết nối trước khi thử SSH:
# Từ phía client
nc -zv 192.168.1.100 22
# Kết quả mong đợi: Connection to 192.168.1.100 22 port [tcp/ssh] succeeded!
# Sau đó thử SSH
ssh user@192.168.1.100
Ở phía server, xác nhận sshd đang thực sự gắn với cổng đó:
ss -tlnp | grep sshd
# Nên hiển thị: LISTEN 0 128 0.0.0.0:22 ...
Mẹo Thêm
- Cloud VM (AWS/GCP/Azure): Tường lửa bên trong hệ điều hành không phải là lớp duy nhất. Security groups và network ACL nằm hoàn toàn bên ngoài VM, và một cổng 22 bị chặn ở cấp độ cloud sẽ tạo ra chính xác lỗi tương tự bất kể UFW hay iptables bên trong nói gì. Hãy luôn kiểm tra cả hai lớp.
- Bị fail2ban chặn? Nếu bạn vừa có chuỗi lần đăng nhập thất bại liên tiếp, các công cụ như fail2ban có thể đã tự động chặn IP của bạn. Kiểm tra bằng
sudo fail2ban-client status sshd. Nếu IP của bạn trong danh sách bị chặn, hãy bỏ chặn nó:sudo fail2ban-client set sshd unbanip YOUR_IP. - Lập kế hoạch mạng: Khi thiết lập truy cập SSH qua các subnet hoặc VPN, việc tính toán dải CIDR nào cần đưa vào whitelist có thể rất mất công. Subnet Calculator tại ToolCraft xử lý phép tính ngay trên trình duyệt — không cần cài đặt.