Chuyển tiếp cổng từ xa SSH không thành công

Theo dõi: Có vẻ như một loạt các ngắt kết nối nhanh chóng trùng hợp với một vài tháng chạy mỗi máy chủ có lẽ là ngẫu nhiên và chỉ phục vụ để tiết lộ vấn đề thực tế. Lý do nó không kết nối lại gần như chắc chắn là do các giá trị AliveInterval (câu trả lời của kasperd). Sử dụng tùy chọn ExitOnForwardFailure sẽ cho phép thời gian chờ xảy ra đúng trước khi kết nối lại, điều này sẽ giải quyết vấn đề trong hầu hết các trường hợp. Đề xuất của MadHatter (kịch bản giết) có lẽ là cách tốt nhất để đảm bảo rằng đường hầm có thể kết nối lại ngay cả khi mọi thứ khác không thành công.

Tôi có một máy chủ (A) phía sau tường lửa khởi tạo một đường hầm ngược trên một số cổng tới một VPS kỹ thuật số nhỏ (B) để tôi có thể kết nối với A qua địa chỉ IP của B. Đường hầm đã hoạt động ổn định trong khoảng 3 tháng, nhưng đột nhiên thất bại bốn lần trong 24 giờ qua. Điều tương tự cũng xảy ra một thời gian trước trên một nhà cung cấp VPS khác - nhiều tháng hoạt động hoàn hảo, sau đó đột nhiên xảy ra nhiều lỗi nhanh chóng.

Tôi có một tập lệnh trên máy A tự động thực hiện lệnh đường hầm ( ssh -R *:X:localhost:X address_of_Bcho mỗi cổng X) nhưng khi nó thực thi, nó nói Warning: remote port forwarding failed for listen port X.

Đi vào sshd /var/log/securetrên máy chủ cho thấy các lỗi sau:

bind: Address already in use
error: bind: Address already in use
error: channel_setup_fwd_listener: cannot listen to port: X

Việc giải quyết yêu cầu khởi động lại VPS. Cho đến lúc đó, tất cả các nỗ lực để kết nối lại đều đưa ra thông báo "chuyển tiếp cổng từ xa không thành công" và sẽ không hoạt động. Bây giờ đến lúc đường hầm chỉ kéo dài khoảng 4 giờ trước khi dừng lại.

Không có gì thay đổi trên VPS và nó là một máy sử dụng một lần, chỉ sử dụng làm điểm cuối đường hầm ngược. Nó đang chạy OpenSSH_5.3p1 trên CentOS 6.5. Có vẻ như sshd không đóng các cổng khi kết nối bị mất. Tôi không thể giải thích được tại sao, hoặc tại sao nó lại đột nhiên xảy ra sau nhiều tháng hoạt động gần như hoàn hảo.

Để làm rõ, trước tiên tôi cần tìm hiểu tại sao sshd từ chối nghe trên các cổng sau khi đường hầm thất bại, điều này dường như là do sshd để các cổng mở và không bao giờ đóng chúng. Đó dường như là vấn đề chính. Tôi chỉ không chắc điều gì sẽ khiến nó hoạt động theo cách này sau nhiều tháng hành xử như tôi mong đợi (tức là đóng các cổng ngay lập tức và cho phép tập lệnh kết nối lại).

Tôi đồng ý với MadHatter, có khả năng đó là chuyển tiếp cổng từ các kết nối ssh không còn tồn tại. Ngay cả khi vấn đề hiện tại của bạn hóa ra là một vấn đề khác, bạn có thể mong đợi chạy vào các kết nối ssh không còn tồn tại sớm hay muộn.

Có ba cách kết nối không còn tồn tại như vậy có thể xảy ra:

• Một trong hai điểm cuối đã được khởi động lại trong khi đầu kia của kết nối hoàn toàn không hoạt động.
• Một trong hai điểm cuối đã đóng kết nối, nhưng tại thời điểm kết nối bị đóng, đã có sự cố tạm thời về kết nối. Sự cố ngừng hoạt động trong vài phút sau khi kết nối được đóng lại, và do đó đầu kia không bao giờ biết về kết nối đóng.
• Kết nối vẫn hoàn toàn hoạt động ở cả hai điểm cuối của kết nối ssh, nhưng ai đó đã đặt một thiết bị trạng thái ở đâu đó giữa chúng, đã hết thời gian kết nối do không hoạt động. Thiết bị có trạng thái này sẽ là NAT hoặc tường lửa, tường lửa bạn đã đề cập là một nghi phạm chính.

Chỉ ra điều nào trong ba điều trên đang xảy ra không quan trọng lắm, bởi vì có một phương pháp, sẽ giải quyết cả ba. Đó là việc sử dụng các thông điệp cố định.

Bạn nên xem xét ClientAliveIntervaltừ khóa cho sshd_configvà ServerAliveIntervalkhoảng cho ssh_confighoặc ~/.ssh/config.

Chạy sshlệnh trong một vòng lặp có thể hoạt động tốt. Đó là một ý tưởng tốt để chèn một giấc ngủ trong vòng lặp để bạn không bị ngập máy chủ khi kết nối vì một số lý do không thành công.

Nếu máy khách kết nối lại trước khi kết nối kết thúc trên máy chủ, bạn có thể gặp phải tình huống kết nối ssh mới hoạt động, nhưng không có chuyển tiếp cổng. Để tránh điều đó, bạn cần sử dụng ExitOnForwardFailuretừ khóa ở phía máy khách.

Bạn có thể tìm thấy quy trình ràng buộc cổng trên máy chủ đó với

sudo netstat -apn|grep -w X

Có vẻ như rất có thể là một nửa không còn tồn tại sshd, nhưng tại sao lại đưa ra các giả định khi bạn có thể có dữ liệu? Đây cũng là một cách tốt để tập lệnh tìm một PID để gửi tín hiệu 9 đến trước khi cố gắng đưa đường hầm trở lại.

Đối với tôi khi một sshđường hầm bị ngắt kết nối, phải mất một thời gian để kết nối được thiết lập lại để sshquá trình tiếp tục chặn khiến tôi không có đường hầm hoạt động và tôi không biết tại sao. Một giải pháp khắc phục là đưa sshvào nền với -fvà tạo ra các kết nối mới mà không cần chờ kết nối cũ để thiết lập lại. Có -o ExitOnForwardFailure=yesthể được sử dụng để giới hạn số lượng các quy trình mới. Việc -o ServerAliveInterval=60cải thiện độ tin cậy của kết nối hiện tại của bạn.

Bạn có thể lặp lại sshlệnh thường xuyên, giả sử, trong một cronhoặc trong một vòng lặp trong tập lệnh của bạn, ví dụ như sau, chúng tôi sẽ chạy sshlệnh cứ sau 3 phút:

while (1)
do
    ssh -f user@hostname -Rport:host:hostport -N -o ExitOnForwardFailure=yes -o ServerAliveInterval=60
    sleep 180
done

Theo kinh nghiệm của tôi, ssh có một thói quen hơi khó chịu là không thoát ra một cách sạch sẽ nếu "cái gì đó" vẫn đang chạy trên hệ thống từ xa. Ví dụ: bắt đầu trong nền. Bạn có thể tái tạo điều này bằng cách:

ssh <server>
while true; do  sleep 60; done&
exit

Ssh của bạn sẽ đăng xuất, nhưng thực tế sẽ không đóng phiên - cho đến khi quá trình từ xa thoát (điều này sẽ không xảy ra, vì đó là vòng lặp 'trong khi đúng'). Nó có thể là một cái gì đó tương tự đang xảy ra - phiên của bạn có một quá trình 'bị mắc kẹt' được sinh ra bởi ssh. Cổng vẫn được sử dụng và do đó nó không thể được sử dụng lại bởi quy trình địa phương của bạn.