Уровни выполнения. Безопасность.
Практика использования stunnel
Установим пакет stunnel командой apt-get install stunnel. Для этого, возможно, придется подключить дополнительные репозитории: stunnel не входит в состав ALT Linux Lite, но есть среди пакетов School Branch. Рассмотрим соответствующую программу "поближе". Stunnel, как указано в документации (man stunnel), может служить как клиентом, так и сервером при организации защищенного с помощью SSL туннеля. Отметим, что различные примеры использования stunnel можно найти на сайте.
Первый способ использования stunnel --- это запуск с клиентской машины для организации доступа к серверу, который принимает защищённые с помощью SSL подключения (например, некоторый клиент не умеет соединяться по SSL, а по тем или иным причинам необходимо использовать именно его). stunnel создаёт SSL-соединение с заданным сервером и открывает на клиентской машине специальный порт, к которому можно подключаться без SSL. При этом любые данные, отправленные по локальному соединению с созданным stunnel портом будут прозрачно для пользователя проходить на сервер через защищённое соединение. Вся работа с SSL при такой схеме осуществляется самой программой stunnel.
Второй способ использования stunnel состоит в организации защиты для не умеющего использовать SSL сервера. stunnel в таком случае работает подобно простым сервисам, которые можно описать средствами xinetd, то есть, пропускает через себя данные опекаемого им демона как фильтр командной строки. # я что-то не уверен насчёт современного imapd
Проиллюстрируем первый способ использования stunnel. Посмотрим на сайт --- web-интерфейс почтового сервера факультета ВМК МГУ. При подключении браузер обратит наше внимание на то, что соединение защищено с помощью SSL (в браузере Firefox, который входит в ПСПО, в адресной строке изменяется фон и появляется специальный значок):
Указанные на сайте "отпечатки пальцев" --- это значения двух различных хэш-функций от публичного ключа сервера. Если просмотреть свойства сайта, то среди административных сведений об используемом сертификате мы увидим такие же отпечатки:
Это совпадение и должно убеждать нас в том, что сайт "подлинный", иными словами --- что "разговаривает" с нами именно webmail.cs.msu.su. Конечно, злоумышленник может встать на пути между нами и доверенным сайтом и выполнить более сложную операцию: подменить не только сертификат, но и значения "отпечатков пальцев" на странице. Вероятность подобного, однако, значительно меньше: необходимо заранее найти место на сайте, где опубликованы соответствующие значения, и в дальнейшем при перехвате соединения фильтровать содержимое http-трафика, подменяя опубликованные "отпечатки" своими.
Попробуем использовать stunnel в режиме клиента. Посмотрим для этого в документацию и обратим внимание на следующие параметры:
- -P --- каталог для хранения PID-файла;
- -c --- работа в режиме клиента (первый из описанных нами способов использования);
- -d --- работа в режиме демона и приём соединений на указанный порт;
- -r --- адрес и порт сервера.
Пусть PID-файл хранится в нашем домашнем каталоге ~. Подключаться мы будем к машине webmail.cs.msu.su по порту https --- он имеет номер 443 (информация об этом хранится в файле /etc/services). В качестве локального порта укажем 8088: стандартный порт http (80) может быть занят обычным web-сервером, а порт 8080 в нашем случае используется web-интерфейсом конфигуратора Alterator.
$ /usr/sbin/stunnel -P ~ -c -d 8088 -r webmail.cs.msu.su:https
Поскольку мы указали программе stunnel работать в режиме демона, то она закроет стандартный поток ввода и перед нами снова окажется приглашение командной строки. Проверим, принимает ли теперь stunnel соединения. Воспользуемся для этого утилитой netstat. Нам понадобится список "слушающих" (ключ -l, listening) TCP-сокетов (ключ -t), причём удобнее использовать числовую форму (ключ -n, numeric) записи портов и Интернет-адресов. Главным для нас будет ключ -p, заставляющий netstat выводить PID и имя "слушающих" программ:
$ netstat -ltnp | grep stunnel (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp 0 0 0.0.0.0:8088 0.0.0.0:* LISTEN 4667/stunnel
Программа grep отфильтровала стандартный вывод netstat, оставив в нем лишь строку, содержащую слово stunnel (первые две строки были выведены в стандартный поток ошибок и поэтому не были отброшены). Как видно, stunnel успешно запустилась и принимает соединения на порту 8088 локальной машины.
Если мы теперь попробуем выполнить с помощью браузера подключение по адресу localhost:8088, то увидим обычный, "незащищенный" по мнению браузера сайт:
Зачем может пригодиться такая схема? В результате наших действий незащищенное подключение устанавливается только к локальной машине (localhost). Считается, что подсмотреть трафик в этом случае очень сложно. Те, у кого такая возможность есть, обычно обладают "полноценными" правами суперпользователя на данной машине, а значит, имеют практически неограниченные возможности обхода любой защиты. Если же этот вариант исключить, то останется лишь "подсматривать" внутрь защищённого SSL подключения по сети, что в большинстве случаев совершенно бесполезно.
SSH: основы
SSH (Secure Shell) --- это возможность получить терминальный доступ к удалённой машине, при этом с точки зрения системы просто создаётся ещё один терминал. Для нас он будет выглядеть так же, как обычный терминал и обладать всеми его свойствами: обработка сигналов, превращение спецсимволов и так далее. На удалённой машине, к которой осуществляется подключение, запущен SSH-демон, который доступен по сети, и к которому можно подключиться при помощи специального клиента. Долгое время эта разработка была отчасти несвободной, потому что в ней использовались патентованные алгоритмы шифрования, однако в 2000-х годах основные патенты открыли, и с тех пор семейство OpenSSH активно развивается.
Как и любая клиент-серверная архитектура, SSH состоит из двух частей: сервер и клиент. Как работает SSH? Точно так же, как SSL, за исключением того, что ключ, генерируемый SSH, --- только ключ, без дополнительных полей. Используется ассиметричное шифрование, чтобы обеспечить идентификацию связывающихся субъектов и для шифрования пароля. Однако шифрование основного потока данных симметричное, потому что ассиметричное шифрование ключами того размера, которые используются в SSH было бы слишком медленным.
Краткая история удалённого терминального доступа
Раньше для реализации доступа к удалённой машине использовались службы telnet и rsh. Служба rsh была достаточно просто организована: она просто эмулировала терминал удалённой машины. Программа telnet была более сложной, однако также не шифровала передаваемые данные. Сейчас в некоторых ОС типа FreeBSD шифруется траффик telnet'a, но, если нет ассиметричной схемы, нельзя гарантировать аутентичность. В целом, службу telnet не рекомендуется использовать. Клиент telnet обычно используют вместо netcat для проверки работоспособности сервисов на заданных портах.
Использование, ассиметричные ключи
Для подключения к SSH-демону на удалённой машине необходимо, чтобы у него были сгенерированы ключи. Их генерирует sshd при первом запуске ( запуск можно осуществить, выполнив команду service sshd start). Это же он сделает при старте системы, если выполнить команду chkconfig sshd on. Всего генерируется три пары ключей (закрытый, открытый) на разные случаи жизни: ключи протокола ssh1, который уже упразднён, и два ключа протокола ssh2: более лёгкий rsa и тяжёлый dsa.
[root@localhost ~]# service sshd start Generating SSH2 RSA host key: DONE Generating SSH2 DSA host key: DONE Generating SSH1 RSA host key: DONE Starting sshd service: DONE
Посмотрим содержимое каталога /etc/openssh. Ничего сложного тут нет. .pub-файлы --- открытые ключи, остальные --- закрытые, есть каталог authorized_keys, и два конфигурационных файла --- от сервера и клиента. Внутрь мы лезть не будем, изучим опции.
Использование, соединение, проверка ключей
Попробуем совершить ssh. Обратите внимание, во что мы упёрлись. В ту же самую картинку, что и с ssl-сертификатами. В отличие от сертификатов, взаимного подписывания ключей тут нету, только возможность проверки fingerprint'а. Для узнавания отпечатка на сервере можно сказать ssh-keygen -l -f <открытый ключ>.
[root@localhost openssh]# ssh-keygen -l -f /etc/openssh/ssh_host_rsa_key.pub 2048 2a:33:88:23:87:5c:26:c4:f3:66:76:fc:0a:b1:fe:89 /etc/openssh/ssh_host_rsa_key.pub
Мы занялись тем, что надо, вобщем-то, делать --- передали информацию о ключе по другому каналу --- произнесли вслух (клиент и сервер в нашем случае находились в одной комнате). Даже позвонить и сверить отпечаток ключа по телефону будет вполне достаточной гарантией безопасности соединения именно к тому хосту, к которому планировалось. К сожалению, практика показывает, что никто эти ключи не сравнивает, люди просто давят yes. Обратите внимание, что просто y недостаточно.
[user@demo ~]$ ssh 10.30.5.197 The authenticity of host '10.30.5.197 (10.30.5.197)' can't be established. RSA key fingerprint is 2a:33:88:23:87:5c:26:c4:f3:66:76:fc:0a:b1:fe:89. Are you sure you want to continue connecting (yes/no)?
Убедимся, что это другой хост: /sbin/ip a.
[user@localhost ~]$ /sbin/ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:11:2f:1d:9d:0d brd ff:ff:ff:ff:ff:ff
inet 10.30.5.197/24 brd 10.30.5.255 scope global eth0Посмотрим, что случилось с каталогом .ssh.
[user@demo ~]$ ls .ssh agent known_hosts
На локальной машине есть каталог ~/.ssh; обратите внимание, что второй раз нас уже не спрашивали о ключе, поскольку host key сохранился в .ssh/known_hosts. Если в какой-то момент при подключении к удалённому хосту, который прописан в known_hosts, отпечаток ключа станет отличным от сохранённого, это значит, что либо мы их поменяли сами (если переустановили систему на сервере и забыли перенести ключи или сгенерировали их заново), или соединение слушается кем-то третьим, который подменяет соединение до сервера.
Смоделируем ситуацию изменения ключа: перегенерируем ключи и попытаемся подключиться:
[user@localhost ~]$ ssh 10.30.5.197 ssh: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ ssh: @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ ssh: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ ssh: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! ssh: Someone could be eavesdropping on you right now (man-in-the-middle attack)! ssh: It is also possible that the RSA host key has just been changed. ssh: The fingerprint for the RSA key sent by the remote host is 49:a9:8b:dd:68:6a:43:c1:d5:e5:af:e7:0f:6f:04:f3. ssh: Please contact your system administrator. ssh: Add correct host key in /home/user/.ssh/known_hosts to get rid of this message. ssh: Offending key in /home/user/.ssh/known_hosts:4 ssh: RSA host key for 10.30.5.197 has changed and you have requested strict checking. ssh: Host key verification failed.
Эта надпись очень угрожающая, но обычно это бывает именно по первой причине.
sshd может сам просматривать содержимое passwd и осуществлять авторизацию, как это делает login. Там могут быть некие нюансы, но важно именно это: фактически, защита по ключу обеспечивает возможность безбоязненно вводить пароль с клавиатуры, потому что при передаче по сети он скрыт ассиметричным шифрованием. Хотя, разумеется, никто не гарантирует, что на машине, на которой набирается пароль, не стоит кейлоггер.
Использование, удалённый запуск программ, копирование файлов
В целом, возможность запускать с той стороны программы (при этом их вывод будет с этой стороны) для Unix-подобных систем очень правильная штука. Далее мы поговорим про удалённый запуск графических программ (при помощи перенаправления X), но даже консольные приложения позволяют совершать множество интересных вещей. Линукс, в принципе, полностью управляется с консоли (особенно, если доступны su/sudo).
Таким способом легко передавать файлы (вариантов много).
[user@demo ~]$ ssh 10.30.5.197 'ls -l todolist.txt' todolist.txt user@10.30.5.197's password:
Что произошло? Мы осуществили соединения, при этом не заводится терминал, только перебрасываются байты.
[user@demo ~]$ ssh 10.30.5.197 'cat todolist.txt' > todolist.txt.local user@10.30.5.197's password: [user@demo ~]$ ssh 10.30.5.197 'md5sum todolist.txt' user@10.30.5.197's password: 3c7ab21a21fe51d291833db681af4d5f todolist.txt [user@demo ~]$ md5sum todolist.txt.local 3c7ab21a21fe51d291833db681af4d5f todolist.txt.local
Обратите внимание, что весь ввод-вывод организуется даже не с помощью stderr, а напрямую с терминальным устройством. Это, во-первых, надёжнее, во-вторых, обеспечивает разделение stdout. Контрольные суммы удалённого и полученного файлов совпадают, то есть с достаточной степенью достоверности копирование произошло без ошибок. Это следствие того, что символы при передаче не преобразуются (как бы это могло происходить в случае преобразования между различными терминалами). Вывод команды cat вообще без модификаций передаётся на эту сторону.
Вообще, для копирования есть специальная утилита scp, secure copy, она занимается передачей файлов с локального компьютера на удалённый и обратно. Команда scp работает как cp, если не находит в параметрах адреса удалённой машины вида <имя пользователя>@<хост>:<путь на хосте>.
Со стороны sshd можно разрешить sftp (по умолчанию в ПСПО он выключен), который более удобен для копирования файлов. sftp --- это протокол на основе ssh, который с виду похож на ftp. На самом деле, sftp не имеет отношения к ftp и является совершенно другим протоколом прикладного уровня. Для защиты ftp ssl-ем, используется ftp/tls, не поддерживаемый повсеместно и потому редкий. Ещё есть sshfs (монтирование удалённой файловой системы через ssh).
SSH: использование ключей
Как видно, при каждой передаче информации нам приходится вводить пароль. В чем здесь может таиться опасность? Будучи ответственным за безопасность данных, администратор обязан принимать во внимание тот факт, что пароль может быть подсмотрен во время набора, или попросту подобран. Каждый набор пользователем пароля --- лишнее беспокойство для администратора.
Стоит добавить, что пользоваться по ssh учетной записью суперпользователя просто-напросто небезопасно.
Есть альтернативный способ аутентификации. До этого мы имели дело только с ключами со стороны хоста. Но пользователь имеет право обладать собственным ssh-ключом (закрытым и открытым) и раздавать открытые ключи, чтобы система аутентификации хоста могла затем просмотреть список имеющихся у неё ключей, найти его и убедиться в подлинности запрашивающего клиента.
Утечка ключей возможна и здесь, но ключи не передаются и не набираются вручную. Разумеется, утеря носителя с ключом равносильна открытому разглашению ключа, но ключи можно защищать.
Незащищённые ключи
Попробуем сгенерировать ssh-ключ:
$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_rsa. Your public key has been saved in /home/user/.ssh/id_rsa.pub. The key fingerprint is: 38:7b:6c:46:bd:44:77:45:47:ef:6c:a0:3b:e2:1b:a1 user@class305.mpgu.edu.ru
Заглянем в локальный каталог .ssh:
$ ls .ssh agent id_rsa id_rsa.pub known_hosts
Теперь там есть файлы id_rsa и .pub. Стоит обратить внимание на права доступа к этим файлам: публичный ключ доступен всем, закрытый - только владельцу:
$ ls -l .ssh/ итого 16 srw------- 1 user user 0 Июл 30 14:54 agent -rw------- 1 user user 1675 Июл 30 16:13 id_rsa -rw-r--r-- 1 user user 406 Июл 30 16:13 id_rsa.pub -rw-r--r-- 1 user user 2046 Июл 30 15:51 known_hosts
Для того, чтобы по ключу можно было соединиться с удалённой машиной, надо добавить открытый ключ в файл authorized_keys на удалённом компьютере. Изначально данный файл не существует. Необходимо выполнить команду ssh-copy-id (AltLinux-специфичная утилита). Это скрипт shell, который создаёт этот файл в случае его отсутствия и добавляет ключ в файл:
$ ssh-copy-id user@10.30.5.197 Adding 1 SSH2 identity... user@10.30.5.197's password: done. Now try logging to the remote host, with "ssh user@10.30.5.197", and check in: .ssh/authorized_keys2 to make sure we haven't added extra keys that you weren't expecting.
Если мы повторим команду ls на удаленном компьютере, то увидим, что файл authorized_keys появился:
$ ssh 10.30.5.197 'ls -l .ssh' итого 8 srw------- 1 user user 0 Июл 30 14:13 agent -rw-r--r-- 1 user user 406 Июл 30 16:17 authorized_keys2 -rw-r--r-- 1 user user 393 Июл 19 17:41 known_hosts
Защита ключа с помощью парольной фразы (''passphrase'')
Очевидно, что ключом без пароля можно пользоваться только в пределах локальной сети, поскольку он хранится в файле и может "утечь" легче, чем набираемый пароль. К примеру, любой, кто имеет права суперпользователя на машине, на которой хранится ваш ключ, может найти его и воспользоваться им. Поэтому ключ следует защищать парольной фразой (passphrase). Пароль, которым мы защищаем ключ, очень ценен, так как он позволяет воспользоваться вашим логином на всех машинах, на которых этот ключ хранится. Потому желательно, чтобы пассфраза не совпадала с паролем. Создание ключа, защищённого парольной фразой, в целом аналогично созданию незащищённого ключа.
Поместим теперь и пароль на удалённую машину и попробуем туда войти:
$ ssh 10.30.5.197 Enter passphrase for key '/home/user/.ssh/id_rsa': Last login: Wed Jul 30 15:52:19 2008 from 10.30.5.1
Замечаем требование ввести кодовую фразу. Так в чем же удобство? В том, что, несмотря на ощущение того, что мы вернулись к тому, с чего начали, есть особенность: пароль всего один, его вполне можно использовать для 10 разных машин, на которых в противном случае пришлось бы заводить 10 разных паролей. Более того, можно на удалённых машинах можно вообще стереть пароль, запретив таким образом локальный вход и оставив только удалённый доступ по ssh. Вдобавок, парольная фраза не передаётся по сети. Но можно обнаружить один существенный недостаток --- если машина, за которой вы сидите, небезопасна, и там вдруг есть кейлоггер, то злоумышленник с помощью фразы получит доступ не только к данному конкретному компьютеру, а ко всем компьютерам, на которых хранится ваш открытый ключ.
Существует интересный вариант ношения ключа с собой на специальной флеш-карте -- есть модуль ssh, который умеет с ней работать. Очевидное достоинство --- ключ нигде на машине не хранится, и считать его нельзя. Недостаток в том, что часть программной реализации перекладывается на устройство (флешку), которое где-то может и не поддерживаться.
Тем не менее, в каком-то смысле мы всё равно закончили тем же, с чего и начали --- добившись-таки наконец беспарольного входа, мы заполучили необходимость каждый раз вводить парольную фразу, которая в идеале должна быть ещё более надёжной, чем ваш обычный пароль.
Ssh-агент
Ssh-агент позволяет не вводить кодовую фразу множество раз. При использовании агента вы вводите фразу один раз, и далее при каждом подключении программа ssh обращается к агенту с вопросом, содержится ли в нем нужная фраза.
Агент запускается автоматически, его запуск входит в стартовые сценарии ПСПО:
$echo set | grep SSH SSH_AGENT_PID=4328 SSH_AUTH_SOCK=/home/user/.ssh/agent
При необходимости можно установить такой запуск вручную.
Первоначально ssh-агент, разумеется, не хранит никаких ключей, и вы можете в этом убедиться, набрав команду ssh-add -L:
$ ssh-add -L The agent has no identities.
Добавим наш ключ:
$ ssh-add .ssh/id_rsa Enter passphrase for .ssh/id_rsa: Identity added: .ssh/id_rsa (.ssh/id_rsa)
Зайдём теперь снова на удалённый компьютер:
$ ssh 10.30.5.197 Last login: Wed Jul 30 16:23:00 2008 from 10.30.5.
Ввод кодовой фразы на этот раз не потребовался. Но, если запустить ssh с ключом -v, то можно увидеть, что она, тем не менее, использовалась:
$ ssh -v 10.30.5.197 OpenSSH_5.0p1, OpenSSL 0.9.8d 28 Sep 2006 debug1: Reading configuration data /etc/openssh/ssh_config debug1: Applying options for * debug1: Connecting to 10.30.5.197 [10.30.5.197] port 22. debug1: Connection established. debug1: identity file /home/user/.ssh/id_rsa type 1 debug1: identity file /home/user/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7 debug1: match: OpenSSH_4.7 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.0 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes256-ctr hmac-md5 none debug1: kex: client->server aes256-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<4096<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host '10.30.5.197' is known and matches the RSA host key. debug1: Found key in /home/user/.ssh/known_hosts:4 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering public key: /home/user/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 277 debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = ru_RU.UTF-8 Last login: Wed Jul 30 16:37:02 2008 from 10.30.5.1
Проброс (''forwarding'') агента
Если запустить ssh с ключом -A, то при запросе списка ключей с помощью утилиты ssh-add на удаленной машине будет видно локальный ключ. При заходе на удаленную машину можно задать порт, по которому надо обратиться к ssh-агенту, с помощью соответствующей переменной окружения. Этот способ потенциально опасен, потому что root на удалённой машине может без помех воспользоваться вашим агентом для получения доступа к хостам, на которых используется агент. С другой стороны, "носить с собой" агента удобно, потому что легко организовать доступ со второй машины на третью, и так далее.
Другой вариант --- выделить некий доверенный компьютер, такой, что закрытый ключ хранится на нём и только на нём. Режим работы в таком случае будет: зайти по паролю на доверенный хост, запустить на нем ssh-агент, выполнить ssh-add, чтобы на локальную машину пришел ключ, и использовать этот ключ подобающим образом. Разумеется, это имеет смысл только в уверенности, что на текущей машине нет кейлоггера или иных средств слежения за клавиатурой.
SSH: forwarding трафика
Протокол X11 не считается надёжным сетевым протоколом. Алгоритм шифрования там следующий: вырабатывается ключ для сеанса, этим ключом сервер и терминал обмениваются и для обеспечения связи используется именно этот ключ. Гарантии, что этот ключ нельзя вычислить или перехватить, нет.
Соответственно, мы знаем, что в переменной DISPLAY хранится адрес сервера, и вы можете запустить приложение на удалённой машине --- грубо говоря, на сервере приложений, а X-сервер на вашей локальной машине будет отрисовывать. Вы всегда можете это настроить, но по умолчанию в ПСПО X-сервер запускается с ключом --no-listen-tcp (за исключением Линукс Терминал), и соединения с удалённого компьютера невозможны. Однако совершенно необязательно проводить подключение по протоколу X11, а можно воспользоваться более надёжным протоколом ssh. Если к удалённой машине можно подключиться по ssh, то можно также запустить удалённое графическое приложение так, что результаты будут выводиться на локальный X-сервер. Делается это с помощью ключа команды ssh -Y. Есть также похожий по действию ключ -X, но он не позволяет делать многие вещи, которые считаются небезопасными (подробнее о них можно узнать из документации sshd, опция ForwardX11Trusted).
Посмотрим содержимое $DISPLAY на локальной машине.
[user@demo ~]$ echo $DISPLAY :0.0
Это значение означает следующее: часть до двоеточия --- адрес машины. Если там ничего не указанно то используется значение по умолчанию --- unix domain socket на локальном компьютере. Часть до точки --- номер X-сервера, после точки --- номер экрана. Если вписать адрес удалённого компьютера и на нем не запрещены соединения по X11, то можно попробовать получить доступ к этому хосту. Совершим ssh -Y на другую машину и посмотрим содержимое переменной:
[user@localhost ~]$ echo $DISPLAY localhost:10.0
Обратите внимание, что в графе адрес стоит адрес, т.е. соединение будет происходить через сеть, однако этот адрес --- localhost, то есть слушается он локально. Далее указан 10 сервер и экран 0. 10 сервер --- это ретранслятор, все программы, которые присоединяются к этому X-серверу по протоколу X11, на самом деле обрабатываются ssh-демоном, который все эти запросы по защищённому протоколу передает на ту машину, с которой было инициировано соединение по ssh, и на ней выводятся результаты программы.
Проброс портов
По протоколу ssh можно осуществлять не только соединение для X-сессии, но и вообще пробрасывать любой порт. Фактически, для проброса X11 организовали на удалённой машине демон так, что пакеты, которые приходили на порт 6010 (6000+номер X-сервера), передавались на локальную машину и обратно. Точно так же мы можем прокинуть подключение к локальному порту на удалённую машину или наоборот.
Пара ssh/sshd позволяет проделать эти операции. Сейчас мы попробуем отдать наш локальный 80 порт на удалённую машину на порт 8089.
[user@demo ~]$ ssh -R 8089:localhost:80 10.30.5.197
Теперь если в браузере на удалённой машине 10.30.4.197 посмотреть localhost:8089 то мы увидим что нас пробрасывает на локальную машину на порт 80, где находится вебсервер.
Однако из-за настроек sshd на удаленной машине она позволяет зайти на 8089 порт только самой себе. Отвечающая за это опция в файле ssh_config по умолчанию выключена:
GatewayPorts no
Логин суперпользователем
По умолчанию запрещено входить суперпользователю по ssh по паролю. Было бы очень неправильно давать человеку сначала логиниться обычным пользователем, а затем использовать su, поскольку при пароль суперпользователя будет передан по сети. Поэтому считается нормальной практикой давать возможность логина суперпользователя по сети только по ключу, без пароля и с криптостойкой пассфразой. В этом случае в логах остается запись о том, чей ключ был использован. Это безопаснее, чем другие схемы.