Я использую ssh-туннель для получения данных с удаленного сервера на локальном оборудовании newtork следующим образом:
su -s /bin/bash -c "autossh -f -M 3333 -C -N -R 0.0.0.0:2222:y.y.y.y:1111 user@x.x.x.x-l k1001 -i /home/dbuser/.ssh/id_dsa" dbuser
Иногда я работаю, иногда нет. Это не очень надежно.
Есть ли у кого-нибудь лучшее решение?
Некоторые параметры sshd работают лучше?
# Package generated configuration file # See the sshd(8) manpage for details # What ports, IPs and protocols we listen for Port 22 # Use these options to restrict which interfaces/protocols sshd will bind to #ListenAddress :: #ListenAddress 0.0.0.0 Protocol 2 # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key #Privilege Separation is turned on for security UsePrivilegeSeparation yes # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768 # Logging SyslogFacility AUTH LogLevel INFO # Authentication: LoginGraceTime 120 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile %h/.xxx/authorized_keys # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication no # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes # To enable empty passwords, change to yes (NOT RECOMMENDED) PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no # Change to no to disable tunnelled clear text passwords #PasswordAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosGetAFSToken no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes #UseLogin no #MaxStartups 10:30:60 #Banner /etc/issue.net # Allow client to pass locale environment variables AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server UsePAM yes
Спасибо
SSH-туннели - довольно хорошее «быстрое» решение для передачи данных через брандмауэры, но они предназначены для интерактивных вещей, таких как X-forwarding. Они не подходят для долгосрочных или массовых переводов.
Вам, вероятно, следует подумать о настройке постоянного VPN, если это возможно. Если нет, я бы посмотрел, как уменьшить объем работы, выполняемой над туннелем, и сделать его более ориентированным на партии. (собирать немного данных каждый час и отключать соединение между прогонами)
Вы также можете поэкспериментировать с настройками ClientAlive и ServerAlive. Это приведет к тому, что система будет периодически проверять связь по зашифрованному каналу. Это часто будет удерживать брандмауэры от отключения незанятого TCP-соединения.
Взгляните на инструменты демона Дэна Дж. Бернштейна.
Он может отслеживать любой процесс и мгновенно перезапускать его в случае сбоя. Идеально подходит для поддержания жизни в туннелях. Настроить можно за 5 минут.
http://cr.yp.to/daemontools.html
Чтобы получить простой HOWTO, проверьте:
http://www.nightbluefruit.com/blog/2014/04/how-to-use-dj-bernsteins-daemontools/