gvy

В свете текущих обсуждений демонстративного нежелания ipnet продолжать работать со своими наиболее технически компетентными и нередко старыми клиентами, и так уж немало им давшими и немало перетерпевшими, предлагаю вниманию пользователей этой, а заодно и других, домосетей следующую КакСде:

Как пробросить ssh-туннель, пока меняешь ipnet на более разумного провайдера

Приборы и материалы

1) ssh-аккаунт на сервере с публичным ip (желательно не свой, а дополнительный)
2) возможность привязаться к "левому" порту (потребует изменения одной директивы в sshd_config)
3) линукс с ssh (другие варианты -- фря, макось, винда с putty -- мной не рассматриваются, "сделай сам")

Ход работы

1) исходя из желательности изоляции по правам, создаём у себя на машинке и на удалённом сервере (возможно, просим создать) дополнительного пользователя -- например, forwarder
2) локально: su - forwarder
3) ssh-keygen -t dsa -b 2048, на вопросы отвечаем энтером (дефолтное положение ключей, пустой пароль)
4) создаём удалённому forwarder каталог ~/.ssh; chown forwarder:forwarder ~forwarder/.ssh; chmod 700 ~forwarder/.ssh
5) ставим на всякий в /etc/passwd для обоих forwarder шеллом /bin/rbash (можно и жёстче, но тогда придётся su - -s /bin/sh; права на домашник тоже есть куда зажимать, но это уж дело личного вкуса, не мне таких учить)
6) копируем содержимое локального ~forwarder/.ssh/id_dsa.pub тем или иным образом (ssh-copy-id, scp, copy-paste...) в удалённый ~forwarder/.ssh/authorized_keys2 (возможно, authorized_keys)
7) добавляем в начало полученного authorized_keys* (до ssh-dsa) следующее: "no-X11-forwarding,no-agent-forwarding,no-pty ", тем самым отключая с прочим ненужным и возможность получения интерактивного шелла по данному ключу
8) находим в sshd_config на сервере директиву GatewayPorts, выставляем значение clientspecified; если вы не администратор хоста (или VPS), может иметь смысл зачитать также и ему соответствующий кусок sshd_config(5) и обдумать, приемлемо ли такое для основного экземпляра или лучше запустить отдельный с отдельными ограничениями _и_ этой опцией; запускаем отдельный или reload'им основной с этим в конфиге
9) добавляем локально куда-нить -- желающие могут оформить сервисом, я засунул в исполняемый файл /etc/rc.d/rc.local примерно следующее:
su - forwarder -c "nohup sh -c 'while :; do ssh -C -p SERVERPORT -R SERVERIP:OURPORT:127.0.0.1:22 SERVERIP; sleep 5; done'" > /var/log/sshd-forwarder.log &
где SERVERIP, SERVERPORT -- то, куда можно прицепиться к sshd на сервере (в случае VPS+NAT два значения SERVERIP в принципе могут различаться, но у кого так -- сами знают или проконсультируются), OURPORT -- левый порт, который должен быть разрешён на файрволе и в случае VPS+NAT просунут в нужный контейнер
10) переза... ой, что это я -- запускаем ту же команду от рута руками, проверяем на своём конце netstat -pan | grep :22, на удалённом -- netstat -pan | grep :OURPORT

Применение

ходим к себе снаружи посредством ssh -p OURPORT user@SERVERIP, соответственно scp -P OURPORT ..., а лучше почитать ssh_config(5) и нарисовать ~/.ssh/config примерно такого вида:

Host myhome
	Hostname SERVERIP
	Port OURPORT
	User user
	Compression yes

и просто ssh myhome; scp file myhome:

Возможно, что-то упустил -- воссоздаю вчерашнее по памяти и глядя в результаты; просьба при обнаружении недостатков указывать таковые.