Product SiteDocumentation Site

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

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

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

Протокол SSH ("Secure SHell" — защищённая командная оболочка) был разработан из соображений безопасности и надёжности. Соединения, использующие SSH, защищены: другая сторона аутентифицируется, а весь обмен данными зашифрован.
В состав SSH также входят две транспортных службы. scp — это инструмент командной строки, который можно использовать наподобие cp с той разницей, что любой путь к другой машине начинается с указания её имени, за которым следует двоеточие.
$ scp file machine:/tmp/
sftp is an interactive command, similar to ftp. In a single session, sftp can transfer several files, and it is possible to manipulate remote files with it (delete, rename, change permissions, etc.). Many FTP clients, including filezilla, support it.
В Debian используется OpenSSH — свободная реализация SSH, развиваемая в рамках проекта OpenBSD (свободной операционной системы, основанной на ядре BSD и делающей акцент на безопасности), и являющаяся ответвлением оригинальной программы SSH, разработанной финской компанией SSH Communications Security Corp. Эта компания изначально разрабатывала SSH как свободное ПО, но впоследствии решила продолжить разработку под собственнической лицензией. Тогда проект OpenBSD создал OpenSSH, чтобы развивать свободную версию SSH.
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).

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. Combining authentication methods

Besides the already mentioned password based, key based, and the certificate based authentication, other methods like using a TOTP exist as well. Not only is this an abundance of options. They can also be combined. On the server side, the AuthenticationMethods directive can define an order of authentication methods a user has to successfully pass, before they are allowed to enter the system. It is even possible to define multiple alternative sequences:
AuthenticationMethods publickey,password publickey,keyboard-interactive:pam
This setting, for example, allows users to login after initially completing the public key authentication, followed by either a successful password authentication or entering a valid TOTP set up via PAM. On the user side, the sequence of methods can be defined using the PreferredAuthentications directive.

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

The SSH protocol allows forwarding of graphical data (“X11” session, from the name of the most widespread graphical system in Unix); the server then keeps a dedicated channel for those data. Specifically, a graphical program executed remotely can be displayed on the X.org server of the local screen, and the whole session (input and display) will be secure. Since this feature allows remote applications to interfere with the local system, it is disabled by default. You can enable it by specifying X11Forwarding yes in the server configuration file sshd_config(5) or by prepending the public key with the X11-forwarding keyword in the authorized_keys(5) file. Finally, the user must also request it by adding the -X option to the ssh command-line.

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

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

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

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

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

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

VNC (Virtual Network Computing - Виртуальный Сетевой Компьютер) позволяет удалённо получить доступ к графическим столам пользователей.
Этот инструмент используется в основном для технической помощи; администратор может видеть ошибки, с которыми сталкивается пользователь, и показывать ему правильный путь их решения без необходимости стоять у него за спиной.
Во-первых, пользователь должен разрешить совместное использование своего сеанса. Графическая среда рабочего стола GNOME включает эту опцию через SettingsSharing (в отличие от предыдущих версий 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. После подключения, администратор может видеть что происходит, работать на машине удалённо и показать пользователю как действовать.