Назад | Перейти на главную страницу

Ssh autorestart проблемы надежности удаленного туннеля

Я использую 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/