Tunnel SSH suspendu

J'essaie d'utiliser un tunnel SSH à partir de chez moi via un ordinateur de l'université pour pouvoir accéder à des articles.

Les deux machines exécutent Ubuntu 11.04. La machine de l'université exécute openssh-server .

A la maison, j'ai suivi ces instructions:

  1. ouvrir une session ssh:

     ssh -D 9999 -C user@my_addr.com 
  2. Ensuite, j'ai configuré Firefox pour la connection SOCKS5 user sur le port 9999 de localhost .

Cela fonctionne depuis un certain time. Ensuite, il bloque soudainement la connection et le terminal se fige.

Qu'est-ce que j'oublie ici?

Je suggère également d'utiliser autossh avec while script par exemple:

J'ai ceci dans crontab:

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

tout en essayant toujours de se connecter, et établir la connection, créer un port de chaussettes, et forword port de calmar. Cela a prouvé être très stable pour moi.

Vous pouvez essayer de définir les variables ClientAliveInterval et ClientAliveCountMax dans votre file de configuration sshd à des valeurs qui vous conviennent.

Du manuel:

 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. 

Essayez autossh . Il détecte les connections suspendues et se reconnecte automatiquement. Je l'ai utilisé dans une situation similaire dans le passé et cela a bien fonctionné pour moi.

MODIFIER

  1. J'avais l'habitude de l'exécuter dans l' screen , ce qui a deux avantages: courir en arrière-plan et revenir à la session plus tard pour vérifier son état et déboguer si nécessaire, comme ceci:

     screen -d -m -S my-autossh-tunnel autossh your_autossh_args 

    Cela démarrera l'écran en arrière-plan. Si vous voulez vérifier le process autossh , vous pouvez vous reconnecter à cette session d' screen -R my-autossh-tunnel avec l' screen -R my-autossh-tunnel

  2. J'ai utilisé la phrase secrète vide pour plus de commodité, mais pour plus de security j'ai utilisé les options suivantes dans les authorized_keys à l'extrémité distante:

     command="/bin/false",no-agent-forwarding,no-X11-forwarding,no-pty` 

    De cette façon, le tunnel peut être établi avec la key, et le shell ne peut pas être utilisé pour autre chose.

J'ai eu le même problème avec l'utilisation de VNC sur le tunnel SSH. Les gelées se sont produites fréquemment, à la fois avec mastic (windows) et openssh (linux).

Avec mastic j'ai copié le profil de connection et changé quelques options juste pour voir ce qui s'est passé et ne gèle plus! Les changements dans le mastic sont les suivants:

login: UNCHECK "désactiver l'algorithm de Nagle" (j'ai laissé "activer TCP keepalives" coché et "secondes entre keepalives" à 30) SELECT "version de protocole internet" IPv4 (au lieu de "auto")

login – SSH: Cochez "Activer la compression"

Je ne suis pas sûr de quelle option a fait l'affaire, mais je suis un heureux campeur maintenant. Je ne peux pas le faire geler, mais quand je suis returnné à l'ancien profil pour vérifier, il a gelé dans quelques secondes.

Les blocages se sont produits principalement lors de l'envoi de grandes mises à jour sur VNC, comme le défilement d'une window. Peut-être l'algorithm Nagle désactivé a inondé le server avec trop de petits packages ou peut-être parce que ipv6 était désactivé sur le server VNC distant, mais pas sur les autres hôtes. Il faudrait plus de tests avec les différentes options pour comprendre cela.