SSH đường hầm treo

7

Tôi đang cố gắng sử dụng một đường hầm SSH từ nhà qua một máy tính trong trường đại học để tôi có thể truy cập một số bài viết.

Cả hai máy đều chạy Ubuntu 11.04. Máy của trường đại học chạy openssh-server.

Ở nhà tôi làm theo những hướng dẫn sau:

mở một phiên ssh:
```
ssh -D 9999 -C user@my_addr.com 
```
Sau đó, tôi đã cấu hình Firefox cho người dùng kết nối SOCKS5 trên cổng 9999của localhost.

Điều này hoạt động trong một thời gian. Sau đó, nó đột nhiên treo kết nối và thiết bị đầu cuối chỉ đóng băng.

Tôi đang thiếu gì ở đây?

ssh ssh-tunneling

— lcguida
nguồn

2

Kết nối SSH có còn hoạt động tại thời điểm điều này xảy ra không? Có lẽ tường lửa giảm kết nối "không hoạt động"?

— Bram

Yeap. Tôi đã nghĩ về điều đó. Vì vậy, tôi đã tạo một tập lệnh nhỏ để chỉ ping google cứ sau 10 giây, để "giữ kết nối sống", nhưng nó không hoạt động.

— lcguida

1

Liệu một phiên ssh thẳng có hoạt động theo cùng một cách, nghĩa là nếu bạn kết nối với máy từ xa và sau đó sử dụng nó một chút, cuối cùng nó có bị treo không? Điều đó sẽ cai trị trong hoặc ngoài phần tử đường hầm.

— EightBitTony

Có thể chạy ssh với -vvà xem những gì được in ra khi kết nối chết.

— ckhan

Tôi đã kiểm tra điều đó bây giờ. Phiên ssh thẳng dường như không treo. Tôi cũng đã thử autossh -D <port> -c <user @ host>. Khi chỉ sử dụng thiết bị đầu cuối cho các lệnh, đã đi tốt. Bắt đầu trình duyệt, thiết bị đầu cuối bị đóng băng.

— lcguida

2

Tôi cũng đề nghị sử dụng autossh với while script chẳng hạn:

Tôi có cái này trong crontab:

@reboot while true; do sleep 10; autossh -i /some/location_not_default.pem -D 9999 -L 1028:localhost:3128; done

trong khi sẽ luôn cố gắng kết nối và thiết lập kết nối, tạo cổng vớ và từ bỏ cổng mực. Điều này đã được chứng minh là rất ổn định đối với tôi.

— c2h2
nguồn

Trông bạn có một lỗi chính tả. Nó nên là sự thật

— Robin

Tôi sẽ thử cái này Đặt fedback sau.

— lcguida

làm việc cho tôi trong một thời gian dài. quá trình ở lại 300 ngày +

— c2h2

2

Bạn có thể thử thiết lập ClientAliveInterval và ClientAliveCountMax biến trong tập tin cấu hình sshd của bạn để giá trị phù hợp với bạn.

Từ hướng dẫn:

ClientAliveInterval 

Sets a timeout interval in seconds after which if no data has been received
from the client, secshd will send a message through the encrypted channel 
to request a response from the client.
The default is 0, indicating that these messages will not be sent to the 
client. This option applies to protocol version 2 only.

— Ksiresh
nguồn

1

Tôi đã thử nó. Không thành công.

— lcguida

2

Hãy thử autossh. Nó phát hiện các kết nối treo và kết nối lại tự động. Tôi đã sử dụng nó trong một tình huống tương tự trong quá khứ và nó hoạt động tốt cho tôi.

BIÊN TẬP

Tôi đã từng chạy nó trong screenđó, có hai lợi ích: chạy (sắp xếp) trong nền và có thể quay lại phiên sau để kiểm tra trạng thái của nó và gỡ lỗi nếu cần, như thế này:
```
screen -d -m -S my-autossh-tunnel autossh your_autossh_args
```
Điều này sẽ bắt đầu màn hình trong nền. Nếu bạn muốn kiểm tra autosshquy trình, bạn có thể kết nối lại với screenphiên này vớiscreen -R my-autossh-tunnel
Tôi đã sử dụng cụm mật khẩu trống để thuận tiện, nhưng để bảo mật hơn, tôi đã sử dụng các tùy chọn sau trong ủy quyền_key ở đầu từ xa:
```
command="/bin/false",no-agent-forwarding,no-X11-forwarding,no-pty`
```
Bằng cách này, đường hầm có thể được thiết lập bằng chìa khóa và vỏ không thể bị lạm dụng cho bất cứ điều gì khác.

— janos
nguồn

1

autossh hoạt động, nhưng không phải trên nền. Tôi cũng đã phải sử dụng khóa công khai để tránh mật khẩu, nếu không, atussh sẽ tiếp tục hỗ trợ tôi cho nó.

— lcguida

Tôi chạy autosshtrong một screenphiên. Tốt hơn là nền, vì tôi có một "cửa sổ" dành riêng cho nó để tôi có thể tách ra và gắn lại sau để kiểm tra trạng thái.

— janos

1

Tôi gặp vấn đề tương tự với việc sử dụng VNC qua đường hầm SSH. Việc đóng băng xảy ra thường xuyên, cả với putty (windows) và openssh (linux).

Với putty tôi đã sao chép hồ sơ kết nối và thay đổi một vài tùy chọn chỉ để xem những gì đã xảy ra và không còn bị đóng băng nữa! Những thay đổi trong putty là:

Kết nối: UNCHECK "vô hiệu hóa thuật toán của Nagle" (Tôi đã bỏ qua "bật các thủ tục TCP" và "giây giữa các lần giữ" ở 30) CHỌN "phiên bản giao thức internet" IPv4 (thay vì "tự động")

Kết nối - SSH: KIỂM TRA "Kích hoạt tính năng nén"

Tôi không chắc lựa chọn nào đã lừa, nhưng bây giờ tôi là một người cắm trại hạnh phúc. Tôi không thể làm cho nó đóng băng, nhưng khi tôi quay lại hồ sơ cũ để kiểm tra, nó bị đóng băng trong vài giây.

Việc đóng băng xảy ra chủ yếu khi gửi các bản cập nhật lớn trên VNC, như cuộn một cửa sổ. Có lẽ thuật toán Nagle bị vô hiệu hóa đã làm ngập máy chủ với quá nhiều gói nhỏ hoặc có thể do ipv6 bị vô hiệu hóa trên máy chủ VNC từ xa nhưng không phải trên các máy chủ khác. Nó sẽ yêu cầu một số thử nghiệm thêm với các tùy chọn riêng lẻ để tìm ra điều đó.

— Joost
nguồn