SSH-Tunnel hängt

7

Ich versuche, einen SSH-Tunnel von zu Hause aus über einen Computer an der Universität zu verwenden, damit ich auf einige Artikel zugreifen kann.

Auf beiden Computern wird Ubuntu 11.04 ausgeführt. Die Maschine der Universität läuft openssh-server.

Zu Hause habe ich diese Anweisungen befolgt:

Öffnen Sie eine SSH-Sitzung:
```
ssh -D 9999 -C user@my_addr.com 
```
Dann habe ich Firefox für die Benutzer-SOCKS5-Verbindung am Port 9999von konfiguriert localhost.

Dies funktioniert seit einiger Zeit. Dann hängt plötzlich die Verbindung und das Terminal friert einfach ein.

Was fehlt mir hier?

ssh ssh-tunneling

— lcguida
quelle

2

Ist die SSH-Verbindung zu diesem Zeitpunkt noch aktiv? Vielleicht trennt eine Firewall "inaktive" Verbindungen?

— Bram

Ja. Ich habe darüber nachgedacht. Also habe ich ein kleines Skript erstellt, um alle 10 Sekunden einen Ping-Befehl an Google zu senden, um "die Verbindung aufrechtzuerhalten", aber es hat nicht funktioniert.

— lcguida

1

Verhält sich eine reine SSH-Sitzung genauso, dh wenn Sie eine Verbindung zum Remote-Computer herstellen und ihn dann ein wenig verwenden, bleibt sie schließlich hängen? Das schließt das Tunnelelement ein oder aus.

— EightBitTony

Vielleicht ssh mit -vausführen und sehen, was ausgedruckt wird, wenn die Verbindung unterbrochen wird.

— Ckhan

Ich habe das jetzt überprüft. Gerade SSH-Sitzung scheint nicht zu hängen. Ich habe auch versucht, autossh -D <Port> -c <Benutzer @ Host>. Wenn Sie nur das Terminal für Befehle verwenden, ging es gut. Der Browser wurde gestartet, das Terminal fror ein.

— lcguida

2

Ich schlage auch vor, autossh mit while-Skript zu verwenden, zum Beispiel:

Ich habe das in crontab:

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

Während wird immer versucht, eine Verbindung herzustellen und die Verbindung herzustellen, einen Sockenport zu erstellen und den Tintenfischport zu formulieren. Dies hat sich für mich als sehr stabil erwiesen.

— c2h2
quelle

Sieht so aus, als hätten Sie einen Rechtschreibfehler. Es sollte wahr sein

— Robin

Ich werde es versuchen. Setzen Sie die Rückmeldung später.

— lcguida

arbeitet für mich schon lange. Der Prozess blieb 300 Tage +

— c2h2

2

Sie können versuchen, die Variablen ClientAliveInterval und ClientAliveCountMax in Ihrer sshd-Konfigurationsdatei auf die für Sie geeigneten Werte festzulegen.

Aus dem Handbuch:

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
quelle

1

Ich habe das versucht. Kein Erfolg.

— lcguida

2

Versuchen Sie es autossh. Es erkennt blockierte Verbindungen und stellt die Verbindung automatisch wieder her. Ich habe es in der Vergangenheit in einer ähnlichen Situation benutzt und es hat gut für mich funktioniert.

BEARBEITEN

Früher habe ich es ausgeführt screen, was zwei Vorteile hat: im Hintergrund ausführen (möglich) und später zur Sitzung zurückkehren, um den Status zu überprüfen und gegebenenfalls zu debuggen, wie folgt:
```
screen -d -m -S my-autossh-tunnel autossh your_autossh_args
```
Dies startet den Bildschirm im Hintergrund. Wenn Sie den autosshProzess überprüfen möchten , können Sie erneut eine Verbindung zu dieser screenSitzung mit herstellenscreen -R my-autossh-tunnel
Ich habe aus Bequemlichkeitsgründen eine leere Passphrase verwendet, aber für zusätzliche Sicherheit habe ich die folgenden Optionen in den autorisierten Schlüsseln am Remote-Ende verwendet:
```
command="/bin/false",no-agent-forwarding,no-X11-forwarding,no-pty`
```
Auf diese Weise kann der Tunnel mit dem Schlüssel eingerichtet werden, und die Shell kann nicht für andere Zwecke missbraucht werden.

— Janos
quelle

1

Autossh funktioniert, aber nicht im Hintergrund. Ich musste auch den öffentlichen Schlüssel verwenden, um ein Passwort zu vermeiden, sonst würde atussh mich weiterhin dafür vorschlagen.

— lcguida

Ich laufe autosshinnerhalb einer screenSitzung. Es ist besser als der Hintergrund, da ich ein spezielles "Fenster" dafür habe, von dem ich mich trennen und später wieder anhängen kann, um den Status zu überprüfen.

— Janos

1

Ich hatte das gleiche Problem mit der Verwendung von VNC über SSH-Tunnel. Die Einfrierungen traten häufig auf, sowohl bei Kitt (Windows) als auch bei OpenSh (Linux).

Mit Putty habe ich das Verbindungsprofil kopiert und einige Optionen geändert, um zu sehen, was passiert ist und nicht mehr einzufrieren! Die Änderungen im Kitt sind:

Verbindung: Deaktivieren Sie "Nagles Algorithmus deaktivieren" (ich habe "TCP-Keepalives aktivieren" aktiviert und "Sekunden zwischen Keepalives" bei 30 aktiviert). Wählen Sie "Internetprotokollversion" IPv4 (anstelle von "Auto").

Verbindung - SSH: PRÜFEN Sie "Komprimierung aktivieren"

Ich bin mir nicht sicher, welche Option den Trick gemacht hat, aber ich bin jetzt ein glücklicher Camper. Ich kann es nicht zum Einfrieren bringen, aber als ich zur Überprüfung zum alten Profil zurückgeschaltet habe, ist es innerhalb weniger Sekunden eingefroren.

Das Einfrieren trat hauptsächlich beim Senden großer Updates über VNC auf, z. B. beim Scrollen eines Fensters. Möglicherweise hat der deaktivierte Nagle-Algorithmus den Server mit zu vielen kleinen Paketen überflutet, oder möglicherweise, weil IPv6 auf dem Remote-VNC-Server deaktiviert wurde, jedoch nicht auf den anderen Hosts. Es würde einige weitere Tests mit den einzelnen Optionen erfordern, um dies herauszufinden.

— Joost
quelle