Sửa lỗi SSH mà vẫn giữ đường truy cập dự phòng

Ghi một lần lỗi và giữ đường phục hồi

Giữ phiên SSH thành công và tìm console phục hồi của nhà cung cấp. Lệnh client chạy trên Linux, macOS hoặc WSL của máy cá nhân; lệnh server chạy qua phiên đang có hoặc console đã xác thực. Không dán lệnh kiểm tra server vào terminal cá nhân.

Thay IP tài liệu 203.0.113.10, tài khoản ubuntu, cổng 22 và đường dẫn khóa theo cấu hình thật. In cấu hình client đã áp dụng, sau đó thử một kết nối mới:

ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Xem hostname, user, port, identityfile và proxy. Lệnh thứ hai tắt chia sẻ kết nối cho lần thử này. Ghi thời điểm và lỗi cuối. Xác minh host key mới theo mục bên dưới; che tên, địa chỉ và đường dẫn khi chia sẻ debug, không chia sẻ private key.

Phân loại theo bước kết nối thất bại

Cuộn bảng sang ngang để xem đủ các cột.

Đây là dấu hiệu thu hẹp nguyên nhân, không chứng minh một lỗi duy nhất. Nếu debug đã báo Connection established trước timeout, kiểm tra bắt tay SSH và log server, không kết luận mọi gói bị chặn.

Timeout: lần theo đường mạng thực

So IP trong ssh -v với panel hiện tại. Hostname có DNS cũ hoặc IPv6 khác có thể dẫn sang máy khác. Xác nhận cần IP công khai, VPN hay jump host.

Kiểm tra máy đang chạy, route công khai, cổng SSH thực và IP công khai hiện tại của bạn tại firewall nhà cung cấp. IP mạng nhà có thể đổi trong khi quy tắc /32 vẫn cũ. Kiểm tra guest firewall qua console.

Trên Oracle, security list, NSG, routing và guest firewall đều tham gia. Giữ quy tắc image; cài UFW hoặc flush iptables không phải bước chẩn đoán. Xem bố cục mạng Oracle. Ping thất bại riêng lẻ không chứng minh SSH không hoạt động.

Connection refused: kiểm tra nơi lắng nghe

Phản hồi từ chối không xác thực rằng đích là VPS mong muốn. Xác nhận máy và cổng, rồi chạy các kiểm tra chỉ đọc qua phiên server đang có hoặc console:

systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pager

Tìm listener đúng cổng và địa chỉ, đối chiếu log với giờ thử. Ubuntu có thể dùng socket activation; ssh.service inactive không đủ kết luận mất SSH nếu ssh.socket đang lắng nghe.

sshd -t kiểm tra cấu hình và host key mà không chạy daemon. Thành công im lặng không chứng minh truy cập mạng. Nếu có lỗi, xác định tệp hoặc thiết lập trước khi reload; không restart mù.

Khóa bị từ chối: kiểm tra tài khoản và khóa gửi

Dùng tài khoản ban đầu của nhà cung cấp hoặc quản trị viên đã tạo, không đoán tên. Tìm fingerprint khóa được gửi trong debug. Để giảm các khóa không liên quan do agent gửi, thử trên client:

ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

IdentityFile trong cấu hình vẫn có thể áp dụng; xem ssh -G. Nếu client không đọc được khóa hoặc báo quyền private key quá rộng, sửa quyền tệp tại máy cá nhân trước khi đổi server.

Trên server, kiểm tra tài khoản đích và public key được phép. Ví dụ home là /home/ubuntu; thay theo kết quả getent:

getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys

So fingerprint với khóa đã gửi. Xem journal về quyền sở hữu, quyền tệp và chính sách tài khoản. Kiểm tra AuthorizedKeysFile, tệp Include và Match nếu không dùng đường mặc định; dịch vụ quản lý khóa của nhà cung cấp cũng có thể thay cơ chế. Giữ các khóa hiện có, không tắt StrictModes hay bật mật khẩu để che nguyên nhân.

Host key đổi: xác minh trước khi kết nối

Dựng lại máy hoặc đổi chủ IP có thể đổi khóa; thay đổi bất ngờ cũng có thể là nhầm endpoint hoặc bị chặn giữa đường. Xác nhận ID instance và kế hoạch dựng lại qua panel đã xác thực.

Tại console tin cậy của guest, kiểm tra public host key có cùng thuật toán client nêu. Với Ed25519:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

So SHA256 với cảnh báo client. Đây là khóa máy chủ, không phải khóa đăng nhập hay gateway console nhà cung cấp. Sau khi xác minh, có thể cần cập nhật mục host đó đã lưu; sao lưu tệp và giữ mục không liên quan. Không xóa toàn bộ known_hosts hoặc bỏ xác minh. Nếu chưa giải thích được danh tính, dừng và điều tra.

Thử lại bằng phiên mới sau khi sửa đúng nguyên nhân

Sửa địa chỉ, user, khóa, quy tắc hẹp hoặc lỗi cấu hình đã xác định. Giữ đường truy cập độc lập và kiểm tra cấu hình SSH trước khi áp dụng. Đổi cổng có thể liên quan socket activation chứ không chỉ restart service.

Lặp lần thử với connection sharing tắt. Xác nhận đăng nhập mới đúng tài khoản và sudo cần thiết hoạt động. Phiên cũ vẫn mở không thay thế phép thử này. Ghi nguyên nhân và thay đổi, rồi quay lại quy trình triển khai.