Comments 17
Для автоматического перезапуска SSH-туннеля можно воспользоваться утилитой
autossh— она создает SSH-туннель и отслеживает его работоспособность.
И где этот autossh брать и чем он лучше mosh?
$ autossh
Команда «autossh» не найдена, но может быть установлена с помощью:
sudo snap install autossh # version 1.4, or
sudo apt install autossh # version 1.4g-1
See 'snap info autossh' for additional versions.(Это про первую часть вопроса.)
mosh совсем о другом. Почитайте сайт проекта
Кто использует autossh для поддержания туннелей — расскажите, каков он в сравнении с запуском через systemd/launchd ?
Использую autossh несколько лет под debian на BananaPi M1, прокидывает 443й порт с ультрадешевой VPS со статическим IP на домашний микросервер с динамическим IP.
Ну как использую... Настроил автозапуск в рутовом crontab и оно работает.
При указанном использовании никаких подводных камней или проблем за несколько лет. В debian ставится одной командой.
не использую, но ответить могу
autossh будет пытаться возродить сессию, в то время как ssh будет создавать новую. тоесть в system юните можно использовать autossh вместо ssh и это будет ещё надёжнее (в теории)
Что-то я прочитал, перечитал, перечитал третий раз.
Фичи autossh:
autossh is a program to start a copy of ssh and monitor it, restarting it as necessary should it die or stop passing traffic. The idea is from rstunnel (Reliable SSH Tunnel), but implemented in C.
The author's view is that it is not as fiddly as rstunnel to get to work.
Connection monitoring using a loop of port forwardings or a remote echo service.
Backs off on rate of connection attempts when experiencing rapid failures such as connection refused.
Фичи mosh:
Mosh adjusts its frame rate so as not to fill up network queues on slow links, so "Control-C" always works within an RTT to halt a runaway process.
Mosh warns the user when it has not heard from the server in a while.
Mosh supports lossy links that lose a significant fraction of their packets.
Mosh handles some Unicode edge cases better than SSH and existing terminal emulators by themselves, but requires a UTF-8 environment to run.
Mosh leverages SSH to set up the connection and authenticate users. Mosh does not contain any privileged (root) code.
Mosh keeps the session alive if the client goes to sleep and wakes up later, or temporarily loses its Internet connection.
Mosh allows the client and server to "roam" and change IP addresses, while keeping the connection alive. Unlike SSH, Mosh can be used while switching between Wi-Fi networks or from Wi-Fi to cellular data to wired Ethernet.
The Mosh client runs a predictive model of the server's behavior in the background and tries to guess intelligently how each keystroke will affect the screen state. When it is confident in its predictions, it will show them to the user while waiting for confirmation from the server. Most typing and uses of the left- and right-arrow keys can be echoed immediately.
mosh совсем о другом.
О чем он?
mosh --ssh="ssh -R 2048:localhost:22 user@server" user@serverне то же самое?
ну брать, видимо, в репозиториях, чем лучше - не требует установки на "другой стороне"
Можно ли для опции JumpHost указать путь к приватному ключу не через конфиг, а как опцию к команде ssh ?
-i identity_file
Selects a file from which the identity (private key) for public key authentication is read. You can also specify a public key file to use the corresponding private
key that is loaded in ssh-agent(1) when the private key file is not present locally. The default is ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk,
~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk and ~/.ssh/id_dsa. Identity files may also be specified on a per-host basis in the configuration file. It is possible to
have multiple -i options (and multiple identities specified in configuration files). If no certificates have been explicitly specified by the CertificateFile di‐
rective, ssh will also try to load certificate information from the filename obtained by appending -cert.pub to identity filenames.То есть через «multiple -i options».
что-то можете сказать про скорость ssh туннеля?
можно ли через него прямое соединение пускать для SteamLink? там скорости от 15 мбит/с и пинг критичны.
для примера такой коннект
Узел 1 Узел 2 Узел 3 Узел 4
192.168.5.0/24 -> роутер с инетом и серым IP -> роутер с инетом и белым IP -> 192.168.2.0/24
получаются варианты ssh-тунеля:
Узел 1..Узел 3
Узел 2..Узел 3
Есть ли смысл рассматривать ssh? OpenVPN пинг дает не стабильный. WireGuard прокинул но еще не собрал статистику.
Я себе сделал fork утилиты, которая через SSH SOCKS поднимает TUN туннель. Эдакий sshuttle, но намного быстрее, отсутствует баг https://github.com/sshuttle/sshuttle/issues/563 и работает на всех популярных OS. Для Windows требуется TUN драйвер от Wireguard.
Использую ежедневно, сбоев не замечено. Кому интересно: https://github.com/kayrus/go-tun2socks
Спасибо за перевод очень полезной статьи.
Но у меня возникла пара вопросов:
Вопрос 1:
В разделе Проброс удаленного порта есть команда ssh -R 8080:example.org:80 ssh-server и в описании говорится
"Переадресует трафик с порта 8080 SSH-сервера для всех интерфейсов на localhost:80 в локальной системе. Далее трафик из локальной системы направляется на example.org:80."
Не понятно откуда тут появляется локальная система, или тут имеется ввиду что ssh-server и локальная система это один и тот же хост?
Вопрос 2:
В разделе Дополнительные примеры и сценарии использования
В команде
ssh -L 127.0.0.1:22:127.0.0.1:2222 intermediate-host Похоже перепутаны местами порты. А в описании говорится
Команда выше пробрасывает порт 2222 на промежуточном хосте на порт 22 выделенного сервера. Теперь можно подключиться к SSH-серверу на выделенном сервере, несмотря на то, что он недоступен из Интернета.
Но в таком виде если судить по разделу "Проброс локального порта" получается мы пробрасываем 2222 порт локальной системы на 22 порт промежуточной, но не как не 2222 порт промежуточной на 22 порт приватного сервера.
Не понятно откуда тут появляется локальная система, или тут имеется ввиду что ssh-server и локальная система это один и тот же хост?
Думаю, что да — SSH-сервер поднят на локальном хосте, к нему коннектятся снаружи, а дальше запрос уходит уже от лица «локального хоста». Думаю, что здесь имеют место быть тонкости перевода или не совсем корректное формулирование мысли в исходном посте.
Но в таком виде если судить по разделу "Проброс локального порта" получается мы пробрасываем 2222 порт локальной системы на 22 порт промежуточной, но не как не 2222 порт промежуточной на 22 порт приватного сервера.
Да, похоже, что здесь перепутаны местами порты. Сейчас добавлю примечание в статью, спасибо.
В примерах упустили ещё один важный вид пробросов - проброс порта для дебаггер. Тот же xdebug.
Кроме того есть ssh vpn в том же Network Manager.
По умолчанию используется протокол SOCKS5, поддерживающий TCP и UDP.
Вот только OpenSSH реализует SOCKS5 не полностью, поэтому поддержки UDP вы не получите.
Наглядное руководство по SSH-туннелям