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

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

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

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

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

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

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

When you need to give a client the ability to conduct or trigger actions on a server, security is important. You must ensure the identity of the client; this is authentication. This identity usually consists of a password or passphrase that must be kept secret, or any other client could it. This is the purpose of encryption, which is a form of encoding that allows two systems to communicate confidential information on a public channel while protecting it from being readable to others.

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

В состав 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 is split into two packages: the client part is in the openssh-client package, and the server is in the openssh-server package. The ssh meta-package depends on both parts and facilitates installation of both (apt install ssh), while the task-ssh-server, often chosen during the initial installation, depends on the server package only.

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

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

The user generates a key pair on the client machine with ssh-keygen -t rsa; the so generated public key is stored in ~/.ssh/id_rsa.pub, while the corresponding private key is stored in ~/.ssh/id_rsa. The user can then use ssh-copy-id server to add their public key to the ~/.ssh/authorized_keys file on the server, or, if SSH access hasn't been enabled yet, they have to ask the administrator to add their key manually.

If the private key was not protected with a “passphrase” at the time of its creation, all subsequent logins on the server will work without a password. Otherwise, the private key must be decrypted each time by entering the passphrase. Fortunately, ssh-agent allows us to keep private keys in memory to not have to regularly re-enter the password. For this, you simply use ssh-add (once per work session) provided that the session is already associated with a functional instance of ssh-agent. Debian activates it by default in graphical sessions, but this can be deactivated by changing /etc/X11/Xsession.options and commenting out use-ssh-agent. For a console session, you can manually start the agent with eval $(ssh-agent).

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

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

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

The OpenSSL library, as initially provided in Debian Etch, had a serious problem in its random number generator (RNG). Indeed, the Debian maintainer had made a change so that applications using it would no longer generate warnings when analyzed by memory testing tools like valgrind. Unfortunately, this change also meant that the RNG was employing only one source of entropy corresponding to the process number (PID) whose 32,000 possible values do not offer enough randomness.

→ 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, затем свалены в один патч во время создания пакета с исходным кодом.

It is difficult under such conditions to find the corrective measures to prevent such incidents from recurring. The lesson to be learned here is that every divergence Debian introduces to upstream software must be justified, documented, submitted to the upstream project when possible, and widely publicized. It is from this perspective that the new source package format (“3.0 (quilt)”) and the Debian sources webservice were developed.

→ https://sources.debian.org

9.2.1.2. Cert-Based Authentication

SSH keys cannot just be protected by a password (or not). An often unknown feature is that they can also be signed via certificate, both the host as well as the client keys. This approach comes with several advantages. Instead of maintaining an authorized_keys file per user as described in the previous section, the SSH server can be configured to trust all client keys signed by the same certificate (see also Раздел 10.2.2, «Инфраструктура открытых ключей: easy-rsa») by using the TrustedUserCAKeys and HostCertificate directives in /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

Vice-versa the clients can also be configured to trust the host key signed by the same authority, making it easier to maintain the known_hosts file (even system wide via /etc/ssh/known_hosts).

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

Both, public key and certificate authentication, can be used alongside each other.

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

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

GOING FURTHER Magic cookies in .Xauthority

When a user connects via SSH and starts a remote X11 session, a so-called magic cookie is created and stored in the .Xauthority file in the user's home directory that initiated the connection. This cookie is used by xauth to authenticate the user during the X session. If the user impersonates another user on the system, e.g. using su or sudo, then the cookie is not copied automatically to the target user and the X server will refuse to start graphical applications under the target user's context. You will have to copy the magic cookie into the target user's home directory (by exporting and re-importing the cookie via xauth) to allow another user to start graphical programs as well during the X session.

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 - Виртуальный Сетевой Компьютер) позволяет удалённо получить доступ к графическим столам пользователей.

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

First, the user must authorize sharing their session. The GNOME graphical desktop environment includes that option via Settings → Sharing (contrary to previous versions of Debian, where the user had to install and run vino). For this to work network-manager must be managing the network used (e.g. enable the managed mode for devices handled by ifupdown in /etc/NetworkManager/NetworkManager.conf). KDE Plasma still requires using krfb to allow sharing an existing session over VNC. For other graphical desktop environments, the x11vnc or tightvncserver commands (from the Debian packages of the same name) or tigervncserver (tigervnc-standalone-server) serve the same purpose and provide the vnc-server virtual package; you can make either of them available to the user with an explicit menu or desktop entry.

When the graphical session is made available by VNC, the administrator must connect to it with a VNC client. GNOME has vinagre and remmina for that, while the KDE project provides krdc (in the menu at K → Internet → Remote Desktop Client). There are other VNC clients that use the command line, such as xtightvncviewer from the homonym package or xtigervncviewer from the tigervnc-viewer Debian package. Once connected, the administrator can see what is going on, work on the machine remotely, and show the user how to proceed.

БЕЗОПАСНОСТЬ 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.