SSH: Enables the sharing of multiple sessions over a single network connection.

Маленький нотаток щодо організації багатьох з'єднань (сесій) через один конект.
Ну всі ми часто-густо кудись ходимо по ssh і можливо навіть відкриваємо декілька з'єднань (звісно, якщо не є прихильниками screen). Так от, сам процес з'єднання можна значно прискорити. ;)
Редагуємо .ssh/config і десь на його початку описуємо загальні вимоги щодо з'єднань з використанням можливостей "sharing of multiple sessions":

host *
        ControlMaster auto
        ControlPath ~/.ssh/control/%r@%h:%p
        ControlPersist 10m

Що ми при цьому отримуємо? Значне прискорення підключення по ssh при повторному з'єднанні з віддаленим хостом!

Про опції:

• ControlMaster - вмикає саму можливість "sharing of multiple sessions". Може приймати параметр auto, ask або autoask.
• ControlPath - місце де буде створюватися сокет
• ControlPersist - можна вказати який час будемо пам'ятати про попереднє з'єднання, якщо його було "розірвано". Може також приймати параметр no, тобто не пам'ятати й розривати одразу як останній клієнт покинув віддалене місце призначення. А можна вказати 0, тоді навпаки про з'єднання будемо пам'ятати доти доки не скажемо:

  ssh -O exit

Хочете дізнатися більше? man ssh_config ;)

Ограничение входа по SSH с конкретных IP адресов

Многие используют вход по ssh с использованием ключей авторизации (в блоге немного рассказывалось об этом), но мало кто знает о том, что при этом можно ограничить вход с заведомо доверенных ip-адресов.

В принципе если есть права администратора то подобные ограничения легко и просто вносятся при помощи незабвенного iptables-а. Однако если прав администратора нет, а ограничение ввести надо то на помощь может прийти нижеследующий механизм.

Для введения ограничений доступа с конкретного ip, как и для авторизации по ключу, используется .ssh/authorized_keys. Например если мы хотим чтобы доступ с конкретным ключом авторизации осуществлялся только лишь с ip-адреса 1.2.3.4 то в начало соответствующей ключу строки файла .ssh/authorized_keys необходимо добавить значение from:

from="1.2.3.4" ssh-rsa  ....

Если хочется чтобы таких адресов было несколько или это была сеть то перечисляем нужные значения:

from="1.2.3.0/24,44.55.66.77" ssh-rsa ...

Таким-же образом можно ввести и другие ограничения, например:

from="1.2.3.4",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-rsa ...

это ограничит agent-forwarding, port-forwarding и т.д., оставив только интерактивный вход в систему. ssh можно ограничить ещё больше, например запретив интерактивный вход, заставив выполнить заданную команду:

command="/usr/local/bin/my-prog" ssh-rsa ..

Это может быть полезным для организации удалённого резервного копирования rsync + ssh, когда будет запущен строго определённый скрипт и ничего более.

Восстановление openssh public key из private key

Случается, что теряется (удаляется или перезаписывается по ошибке) публичная часть ключа (та, которая обычно имеет суффикс ".pub"), но если секретная часть жива ("id_rsa" или "id_dsa") то восстановить публичную — как два пальца:

$ ssh-keygen -y -f id_rsa > id_rsa.pub

или

$ ssh-keygen -y -f id_dsa > id_dsa.pub

Исходная заметка.

SSH: запретить shell, но разрешить sftp, scp...

Ставим пакет rssh. Редактируем /etc/rssh.conf на предмет разрешения тех или иных сервисов. Меняем у пользователя shell:

usermod -s /usr/bin/rssh user

SSH-туннели

Продолжим тему туннелей. Не всегда есть возможность, да и не всегда надо, строить полноценный туннель с интерфейсной парой адресов. Иногда нам нужно лишь "прокинуть" вполне определённые порты.

Тут важно понимать, что туннель можно организовать как изнутри сети, к ресурсам которой вы хотите получить доступ, на внешний ssh-сервер. Также можно организовать туннель с хоста в Интернете на пограничный ssh-сервер сети, чтобы получить доступ к внутренним ресурсам.

Итак. По-порядку.

Строим туннель из сети в мир.

$ ssh -f -N -R 2222:10.11.12.13:22 username@99.88.77.66

теперь введя на хосте 99.88.77.66:

$ ssh -p2222 localhost

мы попадём на хост 10.11.12.13.

Таким-же образом можно получить доступ к любому другому ресурсу, например:

$ ssh -f -N -R 2080:10.11.12.14:80 username@99.88.77.66

Введя на хосте 99.88.77.66:

$ w3m -dump http://localhost:2080

получим дамп web-ресурса на 10.11.12.14.

Строим туннель из мира в сеть.

$ ssh -f -N -L 4080:192.168.0.10:80 nameuser@88.77.66.55

Аналогично, вводим на своём хосте:

$ w3m -dump http://localhost:4080

и получаем доступ к web-ресурсу узла 192.168.0.10, который находится за хостом 88.77.66.55.

Поддерживаем туннели в поднятом состоянии
Ни для кого не секрет, что связь иногда обрывается, туннели при этом будут отваливаться по таймауту.
Чтобы не утруждать себя дополнительным монотонным вбиванием команды на поднятие туннеля и мониторингом этого процесса, автоматизируем его. Смело вводим:

$ crontab -e

и создаём расписание примерно следующего вида:

TUNCMD1='ssh -f -N -R 2222:10.11.12.13:22 username@99.88.77.66'
TUNCMD2='ssh -f -N -R 2080:10.11.12.14:80 username@99.88.77.66'

*/5 * * * * pgrep -f "$TUNCMD1" &>/dev/null || $TUNCMD1
*/5 * * * * pgrep -f "$TUNCMD2" &>/dev/null || $TUNCMD2

Сохраняемся. Проверяем по

$ crontab -l

что расписание принято.

Это лишь ещё один момент особой админской магии... Надеюсь, что лишних вопросов не должно водникнуть. С дополнительными опциями ssh можно ознакомиться в

$ man 1 ssh

Собственно на этом всё

Замечания от sash-kan'а
По практическому опыту — cron-задания на перезапуск абсолютно недостаточно.
Разве что соединение абсолютно стабильно. В реальной жизни встречается в 0% случаев.
Даже соединённые напрямую кабелем две сетевые карты легко могут потерять n-ное количество пакетов и tcp-соединение «упадёт».
Клиент и сервер будут пребывать в святой уверенности, что всё в порядке, просто вторая сторона ничего не передаёт.
Нужен keepalive.
Примерно так:

CODE

TCPKeepAlive yes
ServerAliveInterval 300
ServerAliveCountMax 3

Интервал и счётчик — по вкусу.
Добавлять их надо либо в /etc/ssh_config, либо в ~/.ssh/config, либо прямо в команде через опцию -o.
В принципе, судя по man ssh_config, первую из опций можно и опустить. но, на всякий случай, пусть будет.

Организация SSH Layer 3 туннеля

Достаточно свободная интерпретация статьи "Setting up a Layer 3 tunneling VPN with using OpenSSH".

В данном разделе постараемся описать как использовать возможности появившиеся в OpenSSH v4.3 для создания туннелей, применительно к OS Debian GNU/Linux (наверняка без особых проблем заработает и в Ubuntu).

SSH v4.3 включает layer-2 и layer-3 туннелирование для простой организации VPN, используя механизм аутентификации SSH.

Примерно так выглядит схема, которую мы построим:

----------        /\_/-\/\/-\       -----------------
| Клиент |~~~~~~~/ Интернет /~~~~~~~|    Сервер     |
----------       \_/-\/\_/\/      / -----------------
||\                           \          ||\
|| {tun0}                      {vlan8}   || {tun1}
||                                       ||
\-================= tunnel ==============-/

• vlan8 - 212.90.160.1/27
• tun0 - 10.254.254.2/30
• tun1 - 10.254.254.1/30

Подготовительные работы на клиентской стороне.

В нашей схеме будем использовать аутентификацию по ключу, для этого сначала сгенерируем сам ключ (тип ключа rsa, размер 4Кбита) и скопируем его в учётную запись root'а на сервере (на сервере, при этом, придётся на время открыть возможность логиниться root'ом - PermitRootLogin yes):

# sudo ssh-keygen -t rsa -b 4096
# ssh-copy-id -i .ssh/id_rsa.pub root@212.90.160.1

На этом этапе мы уже будем иметь сохранённый ключ ssh в .ssh/known_hosts, дав ответ "yes" примерно на такой вопрос:

The authenticity of host '212.90.160.1 (212.90.160.1)' can't be established.
RSA key fingerprint is aa:fe:a0:38:7d:11:78:60:01:b0:80:78:90:ab:6a:d2.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '212.90.160.1' (RSA) to the list of known hosts.

и уже скопированный в .ssh/authorized_keys на стороне сервера ключ авторизации клиента.

Далее прописываем на стороне клиента сам интерфейс в /etc/network/interfaces:

auto tun0
iface tun0 inet static
pre-up ssh -S /var/run/ssh-myvpn-tunnel-control -M -f -w 0:1 212.90.160.1 true
pre-up sleep 5
post-up ip l s tun0 mtu 1300
address 10.254.254.2
netmask 255.255.255.252
pointopoint 10.254.254.1
post-down ssh -S /var/run/ssh-myvpn-tunnel-control -O exit 212.90.160.1

На этом этапе прекратим работы с клиентом и приступим к серверу.

Подготовительные работы на стороне сервера.

На стороне сервера перво-наперво вносим следующие изменения в /etc/ssh/sshd_config:

PermitTunnel point-to-point
PermitRootLogin forced-commands-only

Теперь отредактируем /root/.ssh/authorized_keys, добавив в него команду на организацию туннеля:

tunnel="1",command="/sbin/ifdown tun1;/sbin/ifup tun1" ssh-rsa AAAA......X9vc= root@ipclub

После этого отредактируем /etc/network/interfaces:

auto vlan8
iface vlan8 inet static
address 212.90.160.1
netmask 255.255.255.224
network 212.90.160.0
broadcast 212.90.160.31
gateway 212.90.160.30
vlan_raw_device eth0
mtu 1400

iface tun1 inet static
address 10.254.254.1
netmask 255.255.255.252
pointopoint 10.254.254.2
post-up ip l s tun0 mtu 1300

Не забываем определить в /etc/sysctl.conf состояние net.ipv4.conf.default.forwarding:

Код

net.ipv4.conf.default.forwarding=1

ну или перед использование туннеля:

$ sudo sysctl net.ipv4.conf.default.forwarding=1

Важно! Если не устанавливать net.ipv4.conf.default.forwarding в значение 1, то туннели подниматься не будут!

Собственно на этом этапе все подготовительные работы закончены. Пробуем поднять наш туннель со стороны клиента:

$ sudo ifup tun0
$ ip a l dev tun0
9: tun0:  mtu 1300 qdisc pfifo_fast qlen 500
link/[65534]
inet 10.254.254.2 peer 10.254.254.1/30 scope global tun0
$ ping -c2 10.254.254.1
PING 10.254.254.1 (10.254.254.1): 56 data bytes
64 bytes from 10.254.254.1: icmp_seq=0 ttl=64 time=15.116 ms
64 bytes from 10.254.254.1: icmp_seq=1 ttl=64 time=16.454 ms
--- 10.254.254.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 15.116/15.785/16.454/0.669 ms

И наблюдаем icmp трафик на стороне сервера:

$ sudo tshark -tad -pni tun1
Running as user "root" and group "root". This could be dangerous.
Capturing on tun1
2009-03-10 11:25:53.927598 10.254.254.2 -> 10.254.254.1 ICMP Echo (ping) request
2009-03-10 11:25:53.927649 10.254.254.1 -> 10.254.254.2 ICMP Echo (ping) reply
2009-03-10 11:25:54.567857 10.254.254.2 -> 10.254.254.1 ICMP Echo (ping) request
2009-03-10 11:25:54.567910 10.254.254.1 -> 10.254.254.2 ICMP Echo (ping) reply

Дальше можете работать с этими интерфейсами как с обычными eth, vlan, gre и т.д. Маршрутизировать трафик через них, настраивать правила фильтрации и т.д. и т.п. Полёт мысли ограничивается лишь фантазией Однако не забываем, что туннель всё-таки построен на третьем уровне поэтому маркирование пакетов QoS вряд-ли даст тот результат который хотелось бы ожидать.

Собственно на этом можно было бы и закончить, но хочется обратить внимание на один "скользкий" момент, для тех кто хочет поднимать несколько SSH Layer 3 туннелей.
Клиент: pre-up ssh -S /var/run/ssh-myvpn-tunnel-control -M -f -w 0:1 212.90.160.1 true
Сервер: tunnel="1",command="/sbin/ifdown tun1;/sbin/ifup tun1" ssh-rsa AAAA......X9vc= root@ipclub
0 - это номер туннеля на стороне клиента
1 - это номер туннеля на стороне сервера

Вот, чуть не забыл.
Есть ещё один неприятный момент. Соединение, периодически может "отваливаться". Посему неплохо будет озаботиться где нидудь в cron'е выполнить примерно такой сценарий, на стороне клиента:

$ cat /etc/cron.d/tun0
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
*/5 *     * * *     root   fping -c4 10.254.254.1 || ( /sbin/ifdown tun0; sleep 5; /sbin/ifup tun0 )
$ sudo /etc/init.d/cron restart

Вот теперь, наверное, действительно всё!