Consider the following network setup (which I live with by the way):
[main LAN] <-----------------------------------------------------> [remote datacenter LAN]
(192.168.0.0/16) <-------- leased point-to-point ------------> (192.168.0.0/16)
Both locations also have separate connections to the public Internet with different public IP subnets. However, for this discussion it's not necessary to have different public IP subnets. Under normal circumstances the local LAN and the remote LAN are the same logical LAN via the magic of the leased point to point line.
However, today that p2p connection broke (physically between the two locations, out of our control). This outage lasted several hours, but brought out an interesting use of SSH tunneling for ethernet bridging aka Layer-2 VPN or tunneling. For this to work, you'll need to have at least openSSH 4.3, a somewhat recent linux distro and the bridge-utils package for your distro. This also assumes you have a basic knowledge of IP and the linux command line. I use openSuSE 11.0, but this should work for almost any similar linux.
Let's say for example, the main location has a linux box (router1) with two NICs:
eth0: 1.1.1.1 (the public interface)
eth1: unassigned IP, but connected to your LAN (192.168.0.0/16 in my case)
On the other box, at the remote location (router2) we also have two NICs:
eth0: 2.2.2.2 (the public interface)
eth1: unassigned IP, but connected to your LAN (192.168.0.0/16 in my case)
Both routers should be set with it's public IP gateway as the default route, working DNS, etc. You'll want to enable IP forwarding (consult your specific distro) and in my case, I disabled the distro's firewall. On the remote side (consider it the "server"), you'll need to edit your sshd config to allow remote root logins and tunnels via SSH.
/etc/ssh/sshd_config:
PermitRootLogin yes
PermitTunnel yes
The root login is necessary to allow ssh to create the TAP devices for the bridge. Because of that, you'll also want to add your local side's IPs to /etc/hosts.allow for the sshd process. Now, on the local side (IP 1.1.1.1, which you might consider the client now) you'll want to "su root" and do the following:
ssh -o Tunnel=ethernet -f -w 0:0 2.2.2.2 true
The -o switch sets client options on the command line. We're specifying the tunnel type as ethernet (bridge) as opposed to point-to-point, which it'll do by default (for Layer-3 type VPN routing). The -f switch just forks ssh in the background so we're returned to our "client's" command line and not remote's. Since we've done that, ssh will expect a remote command of some kind, so we'll just run "true", effectively doing nothing. The -w 0:0 switch actually sets up our tap devices on either side as tap0. You can do -w 1:1 for tap1, -w 0:1 for tap0 on one side and tap1 on the other, etc.
On both sides now, you should be able to see via ifconfig -a your eth0, eth1 and tap0 devices. Make sure to call ifconfig with -a, or you'll only see interfaces with defined IPs. Now that the two boxes are connected via the public Internet to each other via SSH, you can finally start to establish the bridge interface. Now we'll use the bridge-utils binary to create a bridge interface called br0:
brctl addbr br0
brctl addif br0 eth1
brctl addif br0 tap0
Then you'll want to bring up all of your interfaces, if they aren't already:
ifconfig eth1 up
ifconfig tap0 up
ifconfig br0 up
Doing so will create the br0 interface, then bridge your eth1 and tap0 together and bring up the interfaces. Don't forget, YOU MUST RUN THE brctl and ifconfig COMANDS ON BOTH SIDES!!! Once you've done this, you can check the remote side to see if it knows about the MAC addresses (from Layer-2) on the local side:
brctl showmacs br0
This will report on the known MAC address from the ARP protocol. Depending on your network, you'll see a few or many. Depending on your setup, you can get a DHCP address on the "other side" of the tunnel now or configure an appropriate IP and ping across as if you were on the same physical broadcast domain!
As a final note, there's always a downside. TCP encapsulated TCP is bad and will put a STRAIN on your hardware. Make sure it's decent for the amount of anticipated traffic and use only as a quick and dirty solution or a temporary measure. The following is good reading for why this is not a long-term, permanent solution:
http://sites.inka.de/~W1011/devel/tcp-tcp.html
SSH - всегда делал то, что многие хотят сделать
19.12.2012
Управление ключами
Теория в нескольких словах: ssh может авторизоваться не по паролю, а по ключу. Ключ состоит из открытой и закрытой части. Открытая кладётся в домашний каталог пользователя, «которым» заходят на сервер, закрытая — в домашний каталог пользователя, который идёт на удалённый сервер. Половинки сравниваются (я утрирую) и если всё ок — пускают. Важно: авторизуется не только клиент на сервере, но и сервер по отношению к клиенту (то есть у сервера есть свой собственный ключ). Главной особенностью ключа по сравнению с паролем является то, что его нельзя «украсть», взломав сервер — ключ не передаётся с клиента на сервер, а во время авторизации клиент доказывает серверу, что владеет ключом (та самая криптографическая магия).
Генерация ключа
Свой ключ можно сгенерировать с помощью команды ssh-keygen. Если не задать параметры, то он сохранит всё так, как надо.
Ключ можно закрыть паролем. Этот пароль (в обычных графических интерфейсах) спрашивается один раз и сохраняется некоторое время. Если пароль указать пустым, он спрашиваться при использовании не будет. Восстановить забытый пароль невозможно.
Сменить пароль на ключ можно с помощью команды ssh-keygen -p.
Структура ключа
(если на вопрос про расположение ответили по-умолчанию).
~/.ssh/id_rsa.pub — открытый ключ. Его копируют на сервера, куда нужно получить доступ.
~/.ssh/id_rsa — закрытый ключ. Его нельзя никому показывать. Если вы в письмо/чат скопипастите его вместо pub, то нужно генерировать новый ключ. (Я не шучу, примерно 10% людей, которых просишь дать ssh-ключ постят id_rsa, причём из этих десяти процентов мужского пола 100%).
Копирование ключа на сервер
В каталоге пользователя, под которым вы хотите зайти, если создать файл ~/.ssh/authorized_keys и положить туда открытый ключ, то можно будет заходить без пароля. Обратите внимание, права на файл не должны давать возможность писать в этот файл посторонним пользователям, иначе ssh его не примет. В ключе последнее поле — user@machine. Оно не имеет никакого отношения к авторизации и служит только для удобства определения где чей ключ. Заметим, это поле может быть поменяно (или даже удалено) без нарушения структуры ключа.
Если вы знаете пароль пользователя, то процесс можно упростить. Команда ssh-copy-id user@server позволяет скопировать ключ не редактируя файлы вручную.
Замечание: Старые руководства по ssh упоминают про authorized_keys2. Причина: была первая версия ssh, потом стала вторая (текущая), для неё сделали свой набор конфигов, всех это очень утомило, и вторая версия уже давным давно переключилась на версии без всяких «2». То есть всегда authorized_keys и не думать о разных версиях.
Если у вас ssh на нестандартном порту, то ssh-copy-id требует особого ухищрения при работе:
ssh-copy-id '-p 443 user@server' (внимание на кавычки).Ключ сервера
Первый раз, когда вы заходите на сервер, ssh вас спрашивает, доверяете ли вы ключу. Если отвечаете нет, соединение закрывается. Если да — ключ сохраняется в файл ~/.ssh/known_hosts. Узнать, где какой ключ нельзя (ибо несекьюрно).
Если ключ сервера поменялся (например, сервер переустановили), ssh вопит от подделке ключа. Обратите внимание, если сервер не трогали, а ssh вопит, значит вы не на тот сервер ломитесь (например, в сети появился ещё один компьютер с тем же IP, особо этим страдают всякие локальные сети с 192.168.1.1, которых в мире несколько миллионов). Сценарий «злобной man in the middle атаки» маловероятен, чаще просто ошибка с IP, хотя если «всё хорошо», а ключ поменялся — это повод поднять уровень паранойи на пару уровней (а если у вас авторизация по ключу, а сервер вдруг запросил пароль — то паранойю можно включать на 100% и пароль не вводить).
Удалить известный ключ сервера можно командой ssh-keygen -R server. При этом нужно удалить ещё и ключ IP (они хранятся раздельно): ssh-keygen -R 127.0.0.1.
Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub. Их можно:
а) скопировать со старого сервера на новый.
б) сгенерировать с помощью ssh-keygen. Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет.
Заметим, если вы сервера клонируете (например, в виртуалках), то ssh-ключи сервера нужно обязательно перегенерировать.
Старые ключи из know_hosts при этом лучше убрать, иначе ssh будет ругаться на duplicate key.
Копирование файлов
Передача файлов на сервер иногда может утомлять. Помимо возни с sftp и прочими странными вещами, ssh предоставляет нам команду scp, которая осуществляет копирование файла через ssh-сессию.
scp path/myfile user@8.8.8.8:/full/path/to/new/location/ Обратно тоже можно:
scp user@8.8.8.8:/full/path/to/file /path/to/put/here Fish warning: Не смотря на то, что mc умеет делать соединение по ssh, копировать большие файлы будет очень мучительно, т.к. fish (модуль mc для работы с ssh как с виртуальной fs) работает очень медленно. 100-200кб — предел, дальше начинается испытание терпения. (Я вспомнил свою очень раннюю молодость, когда не зная про scp, я копировал ~5Гб через fish в mc, заняло это чуть больше 12 часов на FastEthernet).
Возможность копировать здорово. Но хочется так, чтобы «сохранить как» — и сразу на сервер. И чтобы в графическом режиме копировать не из специальной программы, а из любой, привычной.
Так тоже можно:
sshfs
sshfs - это клиент SSH?, который позволяет смонтировать файловую систему (или папку) удаленного сервера в любую (существующую) папку локальной файловой системы вашего компьютера.
Вообще, для GNU/Linux хватает клиентов SSH. Однако все они ограничиваются тем, что позволяют производить только базовые операции с файлами: копирование, перенос, удаление.
На мой взгляд, sshfs - незаменимое средство для любого веб-программиста (работающего с GNU/Linux), превосходящее на голову все (испробованные мной) клиенты SSH. Только представьте себе: после подключения при помощи sshfs к удаленному серверу, вы можете работать с файлами на нем, как будто они расположены в вашей домашней папке. Соответственно, с ними можно производить любые операции, как с любыми другими файлами в вашей локальной файловой системе: копировать, редактировать, сравнивать при помощи Meld Diff Viewer или искать в них текст при помощи regexxer Search Tool. При этом все данные передаются зашифрованными. Ваши приложения даже не будут догадываться, что они работают с файлами, которые, может быть, находятся на другом конце света! Удобно, не так ли?
УСТАНОВКА
Клиент sshfs входит в дистрибутивы Ubuntu 7.10, 7.04 и дистрибутив Debian Etch. Думаю, что он есть и в предыдующих версиях Ubuntu/Debian (однако я не проверял). И наверняка sshfs будет включен во все последующие дистрибутивы Ubuntu/Debian.
Установка клиента sshfs элементарна, как и установка любого приложения из пакета для Ubuntu/Debian. sshfs можно установить при помощи менеджера пакетов Synaptic?, а можно набрать команду в терминале:
sudo apt-get install sshfs
Для установки в CentOS нужно подключить RPMForge.
По умолчанию репозиторий RPMForge не подменяет апакетов из базового репозитория CentOS. Это было в прошлом, теперь данные пакеты выведенены в отдельный репозиторий (RPMForge-Extras), который по умолчанию отключен.Вы можете найти полный список пакетов RPMForge наhttp://packages.sw.be/.
Для CentOS 6 cкачайте установочный пакет репозитория. Выбрав одну из ссылок ниже, в соответствии со своей архитектурой. Если вы не знаете какая у вас архитектура, выполните команду: uname -i.
* i386 http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.i386.rpm
* x86_64 http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm
Импортирование ключа.
rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt
Теперь убедитесь, что вы скачали пакет без ошибок.
rpm -K rpmforge-release-0.5.2-2.el6.rf.*.rpm
Установите пакет.
rpm -i rpmforge-release-0.5.2-2.el6.rf.*.rpm
Это добавит конфигурационный файл репозитория и импорт соответствующих ключей GPG.
Для пробы установите что-то вроде:
yum install htop
Для CentOS 5
На данный момент более не требуется установки пакета priorities, для защиты системы от обновления не стабильными пакетами из данного репозитория.
Скачайте пакет rpmforge-release. Выберите одну из двух ссылок ниже, в зависимости от вашей архитектуры. Если не уверены, какую из них использовать, то узнайте свою архитектуру командой uname -i
* i386 http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.i386.rpm
* x86_64 http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm
Установка ключа Dag GPG
rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt
Убедитесь что вы скачали пакет без ошибок:
rpm -K rpmforge-release-0.5.2-2.el5.rf.*.rpm
Установите пакет
rpm -i rpmforge-release-0.5.1-1.el5.rf.*.rpm
Это позволит добавить файл конфигурации репозитория в YUM и импортировать соответствующие ключи GPG.
Можно попробовать установить что-нибудь, например:
yum install mplayer
НАСТРОЙКА
Вообще, после установки sshfs не требует настройки, однако одно действие все же нужно сделать: добавить вашего пользователя в группу fuse. Иначе при монтировании файловой системы удаленного сервера вы увидите ошибку:
fuse: failed to open /dev/fuse: Permission denied
Чтобы добавить пользователя в группу fuse, выполните в консоли команду:
sudo usermod -a -G fuse user
где user - логин вашего пользователя. После этого нужно перелогиниться, чтобы попасть в группу fuse.
Добавить своего пользователя в группу fuse можно также при помощи графической среды GNOME. Откройте меню System -> Administration -> Users and Groups. В появившемся окне со списком пользователей выберите своего пользователя и щелкните по кнопке Properties. В появившемся окне (Account Properties) откройте закладку User Privileges и поставьте галочку Allow user of fuse filesystems like LTSP Thin Client blockdevices. Сохраните изменения, нажав кнопку OK. Не забудьте перелогиниться, чтобы попасть в группу fuse.
ИСПОЛЬЗОВАНИЕ
Монтирование файловой системы удаленного сервера при помощи sshfs выполняется следующей командой:
sshfs -C -p 22 user@example.com:/ /home/user/mnt/example.com
Опция -C сообщает sshfs, чтобы он сжимал передаваемые данные, а опция -p задает номер рабочего порта. Номер порта можно опустить, если это стандартный порт SSH (22).
Обратите внимание, что папка /home/user/mnt/example.com, в которую монтируется удаленная файловая система, должна существовать.
Во время установки соединения sshfs спросит у вас пароль пользователя для подключения к серверу. Если имя пользователя и пароль указаны верно и нет проблем с доступом к папке /home/user/mnt/example.com, клиент sshfs не выдаст никаких сообщений после успешного монтирования ФС удаленного сервера.
Отмонтировать файловую систему удаленного сервера можно следующей командой:
fusermount -u /home/user/mnt/example.com
ПОЛЕЗНЫЙ СОВЕТ
Для более удобной работы с sshfs я использую свои скрипты Bash?. Они позволяют мне несколько упростить работу с sshfs. См. пример кода скриптаuser@example.com.sh ниже.
#!/bin/bash
MOUNT_PATH=/home/user/mnt/example.com
if [ "$1" = "-u" ]; then
fusermount -u -z $MOUNT_PATH
else
sshfs -C user@example.com:/home/user/public_html $MOUNT_PATH
fi
Чтобы смонтировать файловую систему удаленного сервера в локальную папку /home/user/mnt/example.com, я запускаю скрипт user@example.com.sh без параметров, указываю пароль и работаю.
/home/user/mnt/ user@example.com.sh
Когда нужно отключится, я запускаю скрипт с параметром -u и клиент sshfs немедленно рвет соединение с удаленным сервером.
/home/user/mnt/ user@example.com.sh -u
Собственно, исключение: O_DIRECT не поддерживается, увы (это проблема не sshfs, это проблема fuse вообще).
Использование: установить пакет sshfs (сам притащит за собой fuse).
Собственно, пример моего скрипта, который монтирует desunote.ru (размещающийся у меня на домашнем комьютере — с него в этой статье показываются картинки) на мой ноут:
#!/bin/bash sshfs desunote.ru:/var/www/desunote.ru/ /media/desunote.ru -o reconnect
Делаем файл +x, вызываем, идём в любое приложение, говорим сохранить и видим:
Параметры sshfs, которые могут оказаться важными: -o reconnect (говорит пытаться пересоединиться вместо ошибок).
Если вы много работаете с данными от рута, то можно (нужно) сделать idmap:
-o idmap=user. Работает она следующим образом: если мы коннектимся как пользователь pupkin@server, а локально работаем как пользователь vasiliy, то мы говорим «считать, что файлы pupkin, это файлы vasiliy». ну или «root», если мы коннектимся как root.
В моём случае idmap не нужен, так как имена пользователей (локальное и удалённое) совпадают.
Заметим, комфортно работать получается только если у нас есть ssh-ключик (см. начало статьи), если нет — авторизация по паролю выбешивает на 2-3 подключение.
Отключить обратно можно командой fusermount -u /path, однако, если соединение залипло (например, нет сети), то можно/нужно делать это из-под рута: sudo umount -f /path.
Удалённое исполнение кода
ssh может выполнить команду на удалённом сервере и тут же закрыть соединение. Простейший пример:
ssh user@server ls /etc/ Выведет нам содержимое /etc/ на server, при этом у нас будет локальная командная строка.
Некоторые приложения хотят иметь управляющий терминал. Их следует запускать с опцией -t:
ssh user@server -t remove_command Кстати, мы можем сделать что-то такого вида:
ssh user@server cat /some/file|awk '{print $2}' |local_app Это нас приводит следующей фиче:
Проброс stdin/out
Допустим, мы хотим сделать запрос к программе удалённо, а потом её вывод поместить в локальный файл
ssh user@8.8.8.8 command >my_file
Допустим, мы хотим локальный вывод положить удалённо
mycommand |scp — user@8.8.8.8:/path/remote_file
Усложним пример — мы можем прокидывать файлы с сервера на сервер: Делаем цепочку, чтобы положить stdin на 10.1.1.2, который нам не доступен снаружи:
mycommand | ssh user@8.8.8.8 «scp — user@10.1.1.2:/path/to/file»
Есть и вот такой головоломный приём использования pipe'а (любезно подсказали в комментариях в жж):
tar -c * | ssh user@server "cd && tar -x" Tar запаковывает файлы по маске локально, пишет их в stdout, откуда их читает ssh, передаёт в stdin на удалённом сервере, где их cd игнорирует (не читает stdin), а tar — читает и распаковывает. Так сказать, scp для бедных.
Алиасы
Скажу честно, до последнего времени не знал и не использовал. Оказались очень удобными.
В более-менее крупной компании часто оказывается, что имена серверов выглядят так: spb-MX-i3.extrt.int.company.net. И пользователь там не равен локальному. То есть логиниться надо так: ssh ivanov_i@spb-MX-i3.extrt.int.company.net. Каждый раз печатать — туннельных синдромов не напасёшься. В малых компаниях проблема обратная — никто не думает о DNS, и обращение на сервер выглядит так: ssh root@192.168.1.4. Короче, но всё равно напрягает. Ещё большая драма, если у нас есть нестандартный порт, и, например, первая версия ssh (привет цискам). Тогда всё выглядит так: ssh -1 -p 334 vv_pupkin@spb-MX-i4.extrt.int.company.net. Удавиться. Про драму с scp даже рассказывать не хочется.
Можно прописать общесистемные alias'ы на IP (/etc/hosts), но это кривоватый выход (и пользователя и опции всё равно печатать). Есть путь короче.
Файл ~/.ssh/config позволяет задать параметры подключения, в том числе специальные для серверов, что самое важное, для каждого сервера своё. Вот пример конфига:
Host ric
Hostname ооо-рога-и-копыта.рф
User Администратор
ForwardX11 yes
Compression yes
Host home
Hostname myhome.dyndns.org
User vasya
PasswordAuthentication no
Все доступные для использования опции можно увидеть в man ssh_config (не путать с sshd_config).
Опции по умолчанию
По подсказке UUSER: вы можете указать настройки соединения по умолчанию с помощью конструкции Host *, т.е., например:
Host * User root Compression yes
То же самое можно сделать и в /etc/ssh/ssh_config (не путать с /etc/ssh/sshd_config), но это требует прав рута и распространяется на всех пользователей.
Проброс X-сервера
Собственно, немножко я проспойлерил эту часть в примере конфига выше. ForwardX11 — это как раз оно.
Теория: Графические приложения в юникс обычно используют X-сервер (wayland в пути, но всё ещё не готов). Это означает, что приложение запускается и подключается к X-серверу для рисования. Иными словами, если у вас есть голый сервер без гуя и есть локальный x-сервер (в котором вы работаете), то вы можете дать возможность приложениям с сервера рисовать у вас на рабочем столе. Обычно подключение к удалённом X-серверу — не самая безопасная и тривиальная вещь. SSH позволяет упростить этот процесс и сделать его совсем безопасным. А возможность жать трафик позволяет ещё и обойтись меньшим трафиком (т.е. уменьшить утилизацию канала, то есть уменьшить ping (точнее, latency), то есть уменьшить лаги).
Ключики: -X — проброс X-сервера. -Y проброс авторизации.
Достаточно просто запомнить комбинацию ssh -XYC user@SERVER.
В примере выше (названия компании вымышленные) я подключаюсь к серверу ооо-рога-и-копыта.рф не просто так, а с целью получить доступ к windows-серверу. Безопасность microsoft при работе в сети мы все хорошо знаем, так что выставлять наружу голый RDP неуютно. Вместо этого мы подключаемся к серверу по ssh, а дальше запускаем там команду rdesktop:
ssh ric rdesktop -k en-us 192.168.1.1 -g 1900x1200 и чудо, окошко логина в windows на нашем рабочем столе. Заметим, тщательно зашифрованное и неотличимое от обычного ssh-трафика.
Socks-proxy
Когда я оказываюсь в очередной гостинице (кафе, конференции), то местный wifi чаще всего оказывается ужасным — закрытые порты, неизвестно какой уровень безопасности. Да и доверия к чужим точкам доступа не особо много (это не паранойя, я вполне наблюдал как уводят пароли и куки с помощью банального ноутбука, раздающего 3G всем желающим с названием близлежащей кафешки (и пишущего интересное в процессе)).
Особые проблемы доставляют закрытые порты. То джаббер прикроют, то IMAP, то ещё что-нибудь.
Обычный VPN (pptp, l2tp, openvpn) в таких ситуациях не работает — его просто не пропускают. Экспериментально известно, что 443ий порт чаще всего оставляют, причём в режиме CONNECT, то есть пропускают «как есть» (обычный http могут ещё прозрачно на сквид завернуть).
Решением служит socks-proxy режим работы ssh. Его принцип: ssh-клиент подключается к серверу и слушает локально. Получив запрос, он отправляет его (через открытое соединение) на сервер, сервер устанавливает соединение согласно запросу и все данные передаёт обратно ssh-клиенту. А тот отвечает обратившемуся. Для работы нужно сказать приложениям «использовать socks-proxy». И указать IP-адрес прокси. В случае с ssh это чаще всего localhost (так вы не отдадите свой канал чужим людям).
Подключение в режиме sock-proxy выглядит так:
ssh -D 8080 user@server
В силу того, что чужие wifi чаще всего не только фиговые, но и лагливые, то бывает неплохо включить опцию -C (сжимать трафик). Получается почти что opera turbo (только картинки не жмёт). В реальном сёрфинге по http жмёт примерно в 2-3 раза (читай — если вам выпало несчастье в 64кбит, то вы будете мегабайтные страницы открывать не по две минуты, а секунд за 40. Фигово, но всё ж лучше). Но главное: никаких украденных кук и подслушанных сессий.
Я не зря сказал про закрытые порты. 22ой порт закрывают ровно так же, как «не нужный» порт джаббера. Решение — повесить сервер на 443-й порт. Снимать с 22 не стоит, иногда бывают системы с DPI (deep packet inspection), которые ваш «псевдо-ssl» не пустят.
Вот так выглядит мой конфиг:
/etc/ssh/sshd_config:
(фрагмент)
Port 22
Port 443
А вот кусок ~/.ssh/config с ноутбука, который описывает vpn
Host vpn
Hostname desunote.ru
User vasya
Compression yes
DynamicForward 127.1:8080
Port 443
(обратите внимание на «ленивую» форму записи localhost — 127.1, это вполне себе законный метод написать 127.0.0.1)
Проброс портов
Мы переходим к крайне сложной для понимания части функционала SSH, позволяющей осуществлять головоломные операции по туннелированию TCP «из сервера» и «на сервер».
Для понимания ситуации все примеры ниже будут ссылаться на вот эту схему:
Комментарии: Две серые сети. Первая сеть напоминает типичную офисную сеть (NAT), вторая — «гейтвей», то есть сервер с белым интерфейсом и серым, смотрящим в свою собственную приватную сеть. В дальнейших рассуждениях мы полагаем, что «наш» ноутбук — А, а «сервер» — Б.
Задача: у нас локально запущено приложение, нам нужно дать возможность другому пользователю (за пределами нашей сети) посмотреть на него.
Решение: проброс локального порта (127.0.0.1:80) на публично доступный адрес. Допустим, наш «публично доступный» Б занял 80ый порт чем-то полезным, так что пробрасывать мы будем на нестандартный порт (8080).
Итоговая конфигурация: запросы на 8.8.8.8:8080 будут попадать на localhost ноутбука А.
ssh -R 127.1:80:8.8.8.8:8080 user@8.8.8.8 Опция -R позволяет перенаправлять с удалённого (Remote) сервера порт на свой (локальный).
Важно: если мы хотим использовать адрес 8.8.8.8, то нам нужно разрешить GatewayPorts в настройках сервера Б.
Задача. На сервере «Б» слушает некий демон (допустим, sql-сервер). Наше приложение не совместимо с сервером (другая битность, ОС, злой админ, запрещающий и накладывающий лимиты и т.д.). Мы хотим локально получить доступ к удалённому localhost'у.
Итоговая конфигурация: запросы на localhost:3333 на 'A' должны обслуживаться демоном на localhost:3128 'Б'.
ssh -L 127.1:333:127.1:3128 user@8.8.8.8 Опция -L позволяет локальные обращения (Local) направлять на удалённый сервер.
Задача: На сервере «Б» на сером интерфейсе слушает некий сервис и мы хотим дать возможность коллеге (192.168.0.3) посмотреть на это приложение.
Итоговая конфигурация: запросы на наш серый IP-адрес (192.168.0.2) попадают на серый интерфейс сервера Б.
ssh -L 192.168.0.2:8080:10.1.1.1:80 user@8.8.8.8 Вложенные туннели
Разумеется, туннели можно перенаправлять.
Усложним задачу: теперь нам хочется показать коллеге приложение, запущенное на localhost на сервере с адресом 10.1.1.2 (на 80ом порту).
Решение сложно:
ssh -L 192.168.0.2:8080:127.1:9999 user@8.8.8.8 ssh -L 127.1:9999:127.1:80 user2@10.1.1.2 Что происходит? Мы говорим ssh перенаправлять локальные запросы с нашего адреса на localhost сервера Б и сразу после подключения запустить ssh (то есть клиента ssh) на сервере Б с опцией слушать на localhost и передавать запросы на сервер 10.1.1.2 (куда клиент и должен подключиться). Порт 9999 выбран произвольно, главное, чтобы совпадал в первом вызове и во втором.
Реверс-сокс-прокси
Если предыдущий пример вам показался простым и очевидным, то попробуйте догадаться, что сделает этот пример:
ssh -D 8080 -R 127.1:8080:127.1:8080 user@8.8.8.8 ssh -R 127.1:8080:127.1:8080 user@10.1.1.2 Если вы офицер безопасности, задача которого запретить использование интернета на сервере 10.1.1.2, то можете начинать выдёргивать волосы на попе, ибо эта команда организует доступ в интернет для сервера 10.1.1.2 посредством сокс-прокси, запущенного на компьютере «А». Трафик полностью зашифрован и неотличим от любого другого трафика SSH. А исходящий трафик с компьютера с точки зрения сети «192.168.0/24» не отличим от обычного трафика компьютера А.
Туннелирование
Если к этому моменту попа отдела безопасности не сияет лысиной, а ssh всё ещё не внесён в список врагов безопасности номер один, вот вам окончательный убийца всего и вся: туннелирование IP или даже ethernet. В самых радикальных случаях это позволяет туннелировать dhcp, заниматься удалённым arp-спуфингом, делать wake up on lan и прочие безобразия второго уровня.
using openSSH as a layer-2 ethernet bridge (VPN)
Легко понять, что в таких условиях невозможно никаким DPI (deep packet inspection) отловить подобные туннели — либо ssh разрешён (читай — делай что хочешь), либо ssh запрещён (и можно смело из такой компании идиотов увольняться не ощущая ни малейшего сожаления).
Проброс авторизации
Если вы думаете, что на этом всё, то…… впрочем, в отличие от автора, у которого «снизу» ещё не написано, читатель заранее видит, что там снизу много букв и интриги не получается.
OpenSSH позволяет использовать сервера в качестве плацдарма для подключения к другим серверам, даже если эти сервера недоверенные и могут злоупотреблять чем хотят.
Для начала о простом пробросе авторизации.
Повторю картинку:
Допустим, мы хотим подключиться к серверу 10.1.1.2, который готов принять наш ключ. Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам. Компромиссным вариантом было бы иметь «другой» ssh-ключ, который бы авторизовывал user@8.8.8.8 на 10.1.1.2, но если мы не хотим пускать кого попало с 8.8.8.8 на 10.1.1.2, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).
ssh предлагает возможность форварда ssh-агента (это такой сервис, который запрашивает пароль к ключу). Опция ssh -A пробрасывает авторизацию на удалённый сервер.
Вызов выглядит так:
ssh -A user@8.8.8.8 ssh user2@10.1.1.2 Удалённый ssh-клиент (на 8.8.8.8) может доказать 10.1.1.2, что мы это мы только если мы к этому серверу подключены и дали ssh-клиенту доступ к своему агенту авторизации (но не ключу!).
В большинстве случаев это прокатывает.
Однако, если сервер совсем дурной, то root сервера может использовать сокет для имперсонализации, когда мы подключены.
Есть ещё более могучий метод — он превращает ssh в простой pipe (в смысле, «трубу») через которую насквозь мы осуществляем работу с удалённым сервером.
Главным достоинством этого метода является полная независимость от доверенности промежуточного сервера. Он может использовать поддельный ssh-сервер, логгировать все байты и все действия, перехватывать любые данные и подделывать их как хочет — взаимодействие идёт между «итоговым» сервером и клиентом. Если данные оконечного сервера подделаны, то подпись не сойдётся. Если данные не подделаны, то сессия устанавливается в защищённом режиме, так что перехватывать нечего.
Эту клёвую настройку я не знал, и раскопал её redrampage.
Настройка завязана на две возможности ssh: опцию -W (превращающую ssh в «трубу») и опцию конфига ProxyCommand (опции командной строки, вроде бы нет), которая говорит «запустить программу и присосаться к её stdin/out». Опции эти появились недавно, так что пользователи centos в пролёте.
Выглядит это так (циферки для картинки выше):
.ssh/config:
Host raep
HostName 10.1.1.2
User user2
ProxyCommand ssh -W %h:%p user@8.8.8.8
Ну а подключение тривиально:
ssh raep.Повторю важную мысль: сервер 10.1.1.2 не может перехватить или подделать трафик, воспользоваться агентом авторизации пользователя или иным образом изменить трафик. Запретить — да, может. Но если разрешил — пропустит через себя без расшифровки или модификации. Для работы конфигурации нужно иметь свой открытый ключ в authorized_keys как для user@8.8.8.8, так и в user2@10.1.1.2
Разумеется, подключение можно оснащать всеми прочими фенечками — прокидыванием портов, копированием файлов, сокс-прокси, L2-туннелями, туннелированием X-сервера и т.д.
