Поддерживать ssh-соединение, если интернет ненадолго отключается
Вы забыли добавить $перед именем переменных, поэтому они не расширяются до правильных значений, которые вы установили.
попробуй
scp "$somepath/${file}.zip" "$ftp_user"@"$ftp_server":upload/
Возможное решение, в зависимости от назначения ваших сеансов ssh и прав, которые у вас есть на них, заключается в том, чтобы иметь еще один интерфейс поверх него, который не будет отключен.
Этого можно добиться с помощью VPN . Например, полноценный -полноценный VPN (openvpn, wireguard, коммерческий )или построенный на sshи tun.
Конец ответа
Теперь о том, как я это настроил (есть много, много других):
В моем случае интерфейс теперь только отключается, каждые несколько часов появляется новый общедоступный IP-адрес. Сеансы, которые меня интересуют, принадлежат хостам в одной сети, поэтому мое решение — это туннель с устройством tunна моей стороне,и еще один в сети, к которой я хочу обратиться.
Только один раз, например, при загрузке, создайте устройства на каждой стороне (вы должны быть пользователем root):
ip tuntap add dev tun5 mode tun user youruser group yourgrup
ip address add 10.0.0.1/32 peer 10.0.0.2/32 dev tun5
(инвертировать адреса на другой стороне)
Затем используйте опцию -w local_tun[:remote_tun](в данном случае-w 5:5)для обычного подключения вашего хоста к другому хосту. Вам больше не нужны специальные разрешения, потому что вы создали устройства tunдля этого пользователя/группы.
В настоящее время вы можете отправлять эхо-запросы между вашими хостами по альтернативным адресам 10.0.0.x, а также настраивать политики, nating, маршрутизацию и все остальное на своих tun5устройствах, как и на любом другом сетевом устройстве.
Итак, что происходит теперь, когда ваша ссылка не работает? В это время сеанс ssh, связывающий два устройства tun, умирает, но сами устройства tun— нет, они просто буферизуют данные, и как только вы снова подключитесь, трафик возобновится.
Перезапуск сеанса связывания sshбыл бы утомительным, и здесь в игру вступает autossh. Он будет перезапускать этот сеанс всякий раз, когда это необходимо.
Вам просто нужно убедиться, что процессы, которые вы хотите пережить после отключения, используют этот интерфейс (будь то IP, маршрут, NAT... ). Вся настройка может показаться излишней, но она работает даже с DDNS-клиентами. После того, как DNS уловит изменения, сеанс будет восстановлен, и клиенты, использующие устройства tun, возобновят работу.
У меня тоже была такая проблема. Запуск tmuxсеансов на рабочих серверах, а затем повторное подключение к ним после повторного установления соединения позволили мне продолжить с того места, где я остановился, с минимальным раздражением.
Как правило, TCP-соединения устойчивы к коротким разрывам связи -в зависимости от настроек, но я думаю, что по умолчанию TCP должен выдерживать не менее 60 с.
Но это предполагает, что ваш IP-адрес (/адрес NAT-маршрутизатора )не меняется. Если это не так, TCP не может с этим справиться.
Для таких ненадежных подключений есть удобный инструмент под названием mosh, который превосходно поддерживает SSH-соединение при частых повторных подключениях, смене IP-адреса и других помехах.
Это достигается за счет реализации протокола управления потоком, отличного от TCP, поверх UDP и открытия сокета UDP на сервере. Итак, для этого требуется, чтобы ваш удаленный хост мог открыть порт UDP, что обычно не является серьезным ограничением.