9.2. Удалённый вход

Для администратора крайне важно иметь возможность подключиться к компьютеру удалённо. Серверы, заключённые в своей собственной комнате, редко оснащаются постоянными клавиатурами и мониторами — но они подключены к сети.

К ОСНОВАМ Клиент, сервер

Система, в которой несколько процессов взаимодействуют друг с другом, часто описывается с помощью терминов «клиент» и «сервер». Сервер — это программа, принимающая запрос от клиента и выполняющая его. Все действия контролируются клиентом, сервер сам по себе не проявляет никакой инициативы.

9.2.1. Защищённый удалённый вход: SSH

Протокол SSH ("Secure SHell" — защищённая командная оболочка) был разработан из соображений безопасности и надёжности. Соединения, использующие SSH, защищены: другая сторона аутентифицируется, а весь обмен данными зашифрован.

СЛОВАРЬ Аутентификация, шифрование

Безопасность важна, когда необходимо дать клиенту возможность управления или выполнения действий на сервере. Необходимо надёжно идентифицировать клиента; это называется аутентификацией authentication. Для идентификации обычно используется пароль, который должен храниться в секрете, иначе другой клиент мог бы воспользоваться им. Для этого служит шифрование encryption — форма кодирования, позволяющая двум системам обмениваться конфиденциальной информацией по публичному каналу, защищая её от чтения другими.

Аутентификация и шифрование часто упоминаются вместе, потому что они часто используются совместно, и потому что они обычно основываются на сходных математических принципах.

В состав SSH также входят две транспортных службы. scp — это инструмент командной строки, который можно использовать наподобие cp с той разницей, что любой путь к другой машине начинается с указания её имени, за которым следует двоеточие.

$ scp file machine:/tmp/

sftp — это интерактивная команда, похожая на ftp. В рамках одной сессии sftp может передать несколько файлов, а также с её помощью можно манипулировать удалёнными файлами (удалять, переименовывать, менять права доступа и т. д.).

В Debian используется OpenSSH — свободная реализация SSH, развиваемая в рамках проекта OpenBSD (свободной операционной системы, основанной на ядре BSD и делающей акцент на безопасности), и являющаяся ответвлением оригинальной программы SSH, разработанной финской компанией SSH Communications Security Corp. Эта компания изначально разрабатывала SSH как свободное ПО, но впоследствии решила продолжить разработку под собственнической лицензией. Тогда проект OpenBSD создал OpenSSH, чтобы развивать свободную версию SSH.

К ОСНОВАМ Ответвление (fork)

В области программного обеспечения «ответвление» или «форк» означает новый проект, начатый как клон существующего проекта и конкурирующий с ним. В дальнейшем оба программных продукта как правило быстро расходятся в плане новых доработок. Форк часто является результатом конфликтов внутри команды разработчиков.

Возможность создать ответвление прямо следует из самой природы свободного ПО; форк — это здоровое явление, если оно позволяет продолжить развитие проекта как свободного ПО (например в случае изменения лицензии). Форк, возникающий из-за технических или личных разногласий зачастую является транжирством человеческого ресурса; другое решение было бы более предпочтительным. Случаются и слияния двух проектов, ранее разошедшихся вследствие форка.

OpenSSH разделён на два пакета: клиент openssh-client и сервер openssh-server. Мета-пакет ssh устанавливает оба (apt install ssh), тогда как task-ssh-server, часто выбираемый при первоначальной установке, зависит только от пакета сервера.

9.2.1.1. Аутентификация по ключу

При каждом входе по SSH удалённый сервер запрашивает пароль, чтобы аутентифицировать пользователя. Это может создать проблему, если хочется автоматизировать соединение, или если используется некий инструмент, которому нужно часто устанавливать соединения через SSH. По этой причине в SSH предусмотрен механизм аутентификации по ключу.

Пользователь генерирует пару ключей на клиентском компьютере с помощью ssh-keygen -t rsa, сгенерированный таким образом открытый ключ хранится в ~/.ssh/id_rsa.pub, а соответствующий закрытый ключ - в ~/.ssh/id_rsa. Затем пользователь может использовать ssh-copy-id server чтобы добавить свой открытый ключ в файл ~/.ssh/authorized_keys на сервере, если доступ по SSH ещё не включен, им придется попросить администратора добавить ключ вручную.

Если приватный ключ не был защищен «парольной фразой» во время его создания, все последующие входы на сервер будут работать без пароля. В противном случае закрытый ключ придется каждый раз расшифровывать путем ввода парольной фразы. К счастью, ssh-agent позволяет нам хранить закрытые ключи в памяти, чтобы не приходилось регулярно вводить пароль повторно. Для этого вы просто используете ssh-add (один раз за рабочий сеанс) при условии, что сеанс уже связан с функциональным экземпляром ssh-agent. Debian активирует его по умолчанию в графических сеансах, но его можно отключить, изменив /etc/X11/Xsession.options и закомментировав use-ssh-agent. Для сеанса консоли вы можете запустить агент вручную с помощью командой eval $(ssh-agent).

БЕЗОПАСНОСТЬ Защита секретного ключа

Кто угодно, имеющий секретный ключ, может войти в настроенную таким образом учётную запись. Поэтому доступ к секретному ключу защищается «парольной фразой». Некто, получивший копию секретного ключа (например ~/.ssh/id_rsa) всё равно должен знать эту фразу, чтобы иметь возможность воспользоваться им. Эта дополнительная защита не является, однако, неприступной, и если есть основания полагать, что данный файл был скомпроментирован, лучше отключить этот ключ на компьютерах, на которые он был установлен, (путём удаления его из файлов authorized_keys) и заменить его вновь созданным ключом.

КУЛЬТУРА Уязвимость OpenSSL в Debian Etch

У библиотеки OpenSSL в том виде, в каком она поставлялась в Debian Etch, была серьёзная проблема с генератором случайных чисел (RNG - ГСЧ). На самом деле сопровождающий Debian внёс изменение, чтобы приложения, используемые библиотекой, перестали выводить предупреждения при анализе их инструментами тестирования памяти вроде valgrind. К сожалению, это изменение также привело к тому, что ГСЧ стал использовать только один источник энтропии, соответствующий идентификатору процесса (PID), 32.000 возможных значений которого не обеспечивают должного уровня случайности.

→ https://www.debian.org/security/2008/dsa-1571

В частности, когда OpenSSL использовалась для генерации ключа, она всегда создавала ключ из известного набора нескольких сотен тысяч ключей (32.000, помноженные на небольшое число длин ключей). Это затронуло ключи SSH и SSL, а также сертификаты X.509, используемые многочисленными приложениями, такими как OpenVPN. Взломщику оставалось только перепробовать все ключи, чтобы получить неавторизованный доступ. Чтобы уменьшить последствия этой проблемы, демон SSH был модифицирован таким образом, чтобы отклонять проблемные ключи, перечисленные в пакетах openssh-blacklist и openssh-blacklist-extra. Кроме того, команда ssh-vulnkey позволяет обнаружить возможно скомпроментированные ключи в системе.

Более детальный анализ выявил, что это результат нескольких (небольших) проблем и в проекте OpenSSL и у сопровождающего пакет Debian. Такие широко используемые библиотеки как OpenSSL должны без изменений проходить тест valgrind без предупреждений. Более того, код (особенно чувствительные части, как RNG) должен быть лучше сопровождён комментариями для предотвращения таких ошибок. Сопровождающий пакета Debian хотел согласовать изменения вместе с разработчиками OpenSSL, но просто объяснил их, не предоставив соответствующий патч для проверки и не уведомил о своей роли в Debian. Наконец, его выбор не был оптимальным: изменения в исходном коде не были отчётливо сопровождены комментариями. Они были сохранены в репозитории Subversion, затем свалены в один патч во время создания пакета с исходным кодом.

При таких условиях трудно найти средства для предотвращения подобных инцидентов в будущем. Урок, который можно вынести из этого — каждое изменение, внесённое Debian в апстрим программное обеспечение, должно быть подтверждено, документировано, внесено в проект и широко оглашено. В соответствии с этим разработан новый формат для исходников («3.0 (quilt)») и были разработаны веб-сервисы исходного кода Debian.

→ https://sources.debian.org

9.2.1.2. Аутентификация по сертификату

Ключи SSH могут быть защищены не только паролем. Их также можно подписать с помощью сертификата, как хостового, так и клиентского ключа. Этот подход имеет несколько преимуществ. Вместо того, чтобы поддерживать файл authorized_keys для каждого пользователя, как описано в предыдущем разделе, сервер SSH можно настроить так, чтобы он доверял всем клиентским ключам, подписанным одним и тем же сертификатом (см. Раздел 10.2.2, «Инфраструктура открытых ключей: easy-rsa») используя TrustedUserCAKeys и HostCertificate директивы в /etc/ssh/sshd_config.

TrustedUserCAKeys /etc/ssh/ssh_users_ca.pub

HostKey /etc/ssh/ssh_host_ecdsa_key
HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub

И наоборот, клиенты также могут быть настроены так, чтобы доверять ключу хоста, подписанному тем же центром сертификации, что упрощает поддержку файла known_hosts (даже в масштабе всей системы через /etc/ssh/known_hosts).

@cert-authority *.falcot.com ssh-rsa AAAA[..]

И аутентификация с открытым ключом, и аутентификация по сертификату могут использоваться вместе.

9.2.1.3. Использование удалённых приложений X11

Протокол SSH позволяет пересылать графические данные (сессию «X11», по названию наиболее широко распространённой в Unix графической системы); в таком случае сервер сохраняет выделенный канал для этих данных. Так, графическая программа, запущенная удалённо, может быть отображена сервером X.org на локальном экране, и вся сессия (ввод и отображение) будет защищена. Поскольку эта возможность позволяет удалённым приложениям перекрываться с локальной системой, она отключена по умолчанию. Её можно включить, указав X11Forwarding yes в конфигурационном файле сервера (/etc/ssh/sshd_config). Пользователь также должен явно запросить её, добавив опцию -X к командной строке ssh.

УГЛУБЛЯЕМСЯ Волшебные файлы cookie в .Xauthority

Когда пользователь подключается через SSH и запускает удалённый сеанс X11, так называемый magic cookie создаётся и хранится в файле .Xauthority в домашнем каталоге пользователя, который инициировал соединение. Этот файл cookie используется xauth для аутентификации пользователя во время сеанса X. Если пользователь выдает себя за другого пользователя в системе, например. с использованием su или sudo, тогда файл cookie не копируется автоматически целевому пользователю, и X-сервер откажется запускать графические приложения в контексте целевого пользователя. Вам придется скопировать волшебный файл cookie в домашний каталог целевого пользователя (путем экспорта и повторного импорта файла cookie с помощью команды xauth), чтобы другой пользователь также мог запускать графические программы во время сеанса X.

9.2.1.4. Создание шифрованных туннелей

Опции -R и -L указывают ssh, что нужно создать «шифрованный туннель» между двумя машинами, безопасно перенаправив локальный порт TCP (см. врезку К ОСНОВАМ TCP/UDP) на удалённую машину или наоборот.

СЛОВАРЬ Туннель

Интернет, как и большинство подключённых к нему локальных сетей, работает в пакетном режиме, а не в подключённом. Это означает, что пакет, отправленный одним компьютером другому, будет останавливаться на нескольких промежуточных маршрутизаторах для выяснения пути к его месту назначения. Но всё же можно симулировать подключённую работу, энкапсулируя поток в обычные пакеты IP. Эти пакеты следуют своим обычным путём, а поток восстанавливается в неизменном виде в месте назначения. Это называется «туннелем» по аналогии с дорожным туннелем, по которому автомобили следуют напрямую от въезда (ввод) к выезду (вывод) без каких бы то ни было перекрёстков, в противоположность движению по поверхности, где встречались бы перекрёстки и менялось направление движения.

Эту возможность можно использовать, чтобы добавить шифрование в туннель: поток, идущий через него, не распознаваем извне, но возвращается к расшифрованному виду на выходе из туннеля.

ssh -L 8000:server:25 intermediary устанавливает сессию SSH с узлом intermediary и слушает локальный порт 8000 (см. Рисунок 9.3, «Перенаправление локального порта с помощью SSH»). Для любого соединения, установленного на этом порту, ssh инициирует соединение с машиныintermediary на порт 25 машины server и свяжет оба соединения друг с другом.

ssh -R 8000:server:25 intermediary также устанавливают сессию SSH с intermediary компьютером, но на этой машине находится ssh и уже слушает порт 8000 (см. Рисунок 9.4, «Перенаправление удалённого порта с помощью SSH»). Любое соединение с этим портом заставит ssh открыть соединение с локальной машины на порт 25 машины server и связать между собой два соединения.

В обоих случаях соединения устанавливаются с портом 25 узла server, проходя через туннель SSH между локальной машиной и машиной intermediary. В первом случае входом в туннель является локальный порт 8000, и данные идут на машину intermediary перед тем, как направиться на server в «публичной» сети. Во втором случае вход и выход из туннеля меняются местами; входом является порт 8000 на машине intermediary, а выход расположен на локальном узле, и данные затем направляются на server. На практике сервером обычно является либо локальная машина, либо промежуточная. В таком случае SSH защищает соединение от одного конца до другого.

Рисунок 9.3. Перенаправление локального порта с помощью SSH

Рисунок 9.4. Перенаправление удалённого порта с помощью SSH

9.2.2. Использование удалённых графических рабочих столов

VNC (Virtual Network Computing - Виртуальный Сетевой Компьютер) позволяет удалённо получить доступ к графическим столам пользователей.

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

Во-первых, пользователь должен разрешить совместное использование своего сеанса. Графическая среда рабочего стола GNOME включает эту опцию через Settings → Sharing (в отличие от предыдущих версий Debian, где пользователю приходилось устанавливать и запускать vino). Для этой работы network-manager необходимо управлять используемой сетью (например, включить режим managed для устройств, обслуживаемых ifupdown в /etc/NetworkManager/NetworkManager.conf). KDE Plasma всё ещё требует использования krfb чтобы разрешить общий доступ к существующему сеансу через VNC. Для других графических сред рабочего стола команды x11vnc или tightvncserver (из одноименных пакетов Debian) или tigervncserver (tigervnc-standalone-server) служат той же цели и обеспечиваются виртуальным пакетом vnc-server; вы можете сделать любой из них доступным пользователю с помощью явной записи в меню или на рабочем столе.

Когда графический сеанс доступен через VNC, администратор должен подключиться к нему с помощью клиента VNC. В GNOME есть vinagre и remmina, проект KDE предоставляет krdc (в меню K → Интернет → Клиент удалённого рабочего стола). Существуют другие VNC-клиенты, использующие терминал, например xtightvncviewer — из одноимённого пакета Debian или xtigervncviewer из tigervnc-viewer. После подключения, администратор может видеть что происходит, работать на машине удалённо и показать пользователю как действовать.

БЕЗОПАСНОСТЬ VNC через SSH

Если хочется подключиться по VNC, но так, чтобы данные не передавались по сети в открытом виде, можно энкапсулировать их в SSH-туннель (см. Раздел 9.2.1.4, «Создание шифрованных туннелей»). Для этого нужно только знать, что по умолчанию VNC использует порт 5900 для первого экрана (называемого «localhost:0»), 5901 — для второго (называемого «localhost:1») и т. д.

Команда ssh -L localhost:5901:localhost:5900 -N -T machine создаёт туннель между портом 5901 локального интерфейса и портом 5900 узла machine. Первое слово «localhost» указывает SSH, что надо слушать только этот интерфейс на локальной машине. Второе вхождение «localhost» указывает интерфейс на удалённой машине, который будет получать трафик, входящий в «localhost:5901». В таком случае команда vncviewer localhost:1 установит подключение клиента VNC к удалённому экрану, хотя ей и указано имя локальной машины.

После закрытия сессии VNC не забудьте также закрыть туннель путём выхода из соответствующей сессии SSH.

К ОСНОВАМ Менеджер дисплея

gdm3, kdm, lightdm, и xdm — дисплейные менеджеры (все из метапакета x-display-manager). Они берут на себя управление графическим интерфейсом вскоре после загрузки, чтобы предоставить пользователю экран входа в систему. После входа в систему пользователя дисплейные менеджеры запускают программы, необходимые для старта графического сеанса.