Teleport на VPS: доступ команды к Linux-серверам с журналом сессий

Новому инженеру нужно добраться до трёх Linux-серверов, и самый короткий путь известен всем: взять его публичный ключ и дописать в authorized_keys на каждой машине. Потом приходит второй инженер, подрядчик на две недели, дежурный из соседней команды. Ключи копируются так же буднично, как файлы конфигурации. Через год кто-то спрашивает: «А у кого сейчас есть вход на сервер сборки?», и выясняется, что честный ответ звучит как «надо пройтись по всем машинам и посмотреть». Причём смотреть придётся не только файлы пользователей: ключи могли попасть в общую учётную запись, в скрипт развёртывания, в образ, из которого поднимали новые серверы.

Проблема не в самом SSH. Протокол надёжен, а ключи удобны. Проблема в том, что SSH-ключ сам по себе ничего не знает ни о человеке, ни о задаче, ни о сроке. Он просто математически подходит к замку. Любые сведения «чей это ключ», «зачем выдан» и «когда его пора убрать» живут вне ключа: в чьей-то памяти, в тикете, в таблице, которую обновляли с разной степенью аккуратности. Teleport предлагает перенести эти сведения в центральное место, где доступ связан с идентичностью человека и ролью. Эта статья о том, как оценить такой подход на небольшом пилоте на VPS и что останется на вашей совести даже после установки.

Что на самом деле расползается: ключи, роли или память команды

Прежде чем ставить новый компонент, полезно честно сформулировать, какую именно боль он должен вылечить. У разрозненных ключей обычно три симптома.

• Нет единого ответа на вопрос «кто может войти». Список допущенных людей распределён по серверам и собирается вручную.
• Доступ не привязан к причине. Ключ выдан для конкретной работы, но ничто не напоминает, что работа закончилась.
• След действий неравномерен. Где-то настроен аудит, где-то нет, а общие учётные записи размывают ответственность: в журнале видно, что вошёл пользователь с общим именем, но не видно, какой человек за ним стоял.

Управляемая идентификация закрывает эти симптомы в разной степени. Первый решается централизацией: список людей и ролей хранится в одной системе. Второй решается тем, что допуск можно оформить как роль с понятным составом, а не как россыпь файлов. Третий решается сочетанием личной идентичности и записи сессий. Но «решается» не означает «решено сама собой». Каждый из пунктов требует конкретных решений команды, и дальше мы пройдём по ним на условном примере.

Один инженер, одна задача, три сервера

Возьмём вымышленную ситуацию, чтобы не говорить в пустоте. Инженер Анна на две недели подключается к проекту: ей нужно разобраться с медленной выгрузкой отчётов. В проекте есть тестовый сервер приложения, тестовая база данных и сервер сборки. Рабочий сервер приложения для неё не нужен, и вот здесь начинается интересная часть: старая привычка «дадим доступ к серверам проекта» сразу размывает границу.

Если мыслить ролями, а не ключами, вопрос меняется. Вместо «на какие машины положить ключ Анны» звучит «какая роль описывает работу аналитика производительности на тестовом контуре». Роль должна отвечать минимум на четыре вопроса.

1. К каким серверам разрешён вход. В нашем примере это тестовые машины, а рабочие остаются за пределами роли.
2. От имени каких системных пользователей. Если разрешён вход под привилегированной учётной записью, это нужно признать отдельным осознанным решением, а не побочным эффектом удобства.
3. Что человек увидит в записях и активных сессиях. Это отдельный вопрос, о нём ниже: права на просмотр записей тоже задаются ролями.
4. Когда допуск заканчивается. Срок мы определяем заранее и записываем в рабочий порядок, потому что от него зависит финал всей истории.

Обратите внимание на порядок. Сначала описывается задача, потом выбираются серверы, потом права. Старый подход шёл в обратную сторону: у человека уже есть ключ, и дальше всё держится на надежде, что он не зайдёт куда не следует. Роль переворачивает порядок и заставляет заранее сформулировать границу. Это не магия Teleport, а следствие того, что инструмент требует явного описания. Тот же эффект можно получить дисциплиной и таблицей, но дисциплина без принуждающего механизма склонна устаревать в первую же загруженную неделю.

Есть и обратная сторона. Роли тоже могут разрастаться. Если на каждую просьбу создавать новую роль «на всякий случай» или, наоборот, складывать всё в одну широкую роль «инженер», вы получите ту же россыпь ключей, только в новом формате. Разумная отправная точка для пилота: две-три роли, соответствующие реальным типам работ, например «наблюдатель тестового контура», «инженер тестового контура» и «администратор пилота». Названия условные. Их задача — чтобы любой участник команды мог за минуту объяснить, чем одна роль отличается от другой.

От команды подключения до записи: что именно остаётся после сессии

Теперь проследим путь Анны. Она аутентифицируется через систему идентификации, получает допуск согласно своей роли, выбирает разрешённый сервер и открывает терминальную сессию. Для команды ценность в том, что сам факт входа теперь отражается в журнале событий под её личным именем, а не под именем общей учётной записи. Если включена запись сессий, сохраняется и содержимое терминального сеанса.

И вот тут легко ошибиться в ожиданиях. Слово «запись» вызывает образ видеорегистратора, который фиксирует каждое нажатие. Документация Teleport описывает более скромную вещь. По разделу об записи сессий, для SSH обычная запись сохраняет то, что выводится в псевдотерминал (PTY output), а не гарантированный перечень всех выполненных команд. Разница принципиальна. Команда, которую вы видите на экране, попадает в вывод потому, что терминал отображает ввод пользователя обратно, то есть работает эхо. Если эхо отключено, то введённое может не появиться в записи.

Тот же источник отмечает несколько приёмов, которые способны скрыть детали от обычной записи: закодированная команда, запуск заранее подготовленного скрипта, изменение режима эха терминала. Разберём, что это значит на практике, без уклона в паранойю.

• Скрипт. Если Анна запускает файл, который лежит на сервере, в записи будет видно, что она его запустила и что он вывел в терминал. Что он делал внутри, запись не покажет, если это не попало в вывод. Содержимое файла нужно смотреть отдельно, а значит, вопрос «кто и когда положил этот скрипт» тоже должен иметь ответ.
• Закодированная команда. Строка, которая сама по себе выглядит как набор символов, в записи останется набором символов. Расшифровать её можно, но только вручную и при условии, что вы заметили, что что-то не так.
• Отключённое эхо. Это отдельная ситуация, где вывод терминала перестаёт отражать ввод.

Отсюда не следует, что запись бесполезна. Следует более трезвый вывод: запись сессии — это материал для расследования и разбора, а не доказательство полноты. Она отвечает на вопрос «что происходило на экране», и во многих разборах этого достаточно: видно, какой человек заходил на какую машину, в какое время, что он читал, какие утилиты запускал открыто. Но она не заменяет другие слои: журнал аудита на самих серверах, контроль изменений в репозитории, ограничение прав в самой роли. Если кто-то в команде скажет «у нас всё записывается», хорошо бы сразу уточнить: что именно записывается и что остаётся за кадром.

Практическое следствие для роли Анны: чем меньше у неё прав, тем меньше нужды надеяться на полноту записи. Если у человека нет возможности менять конфигурацию на тестовой базе, то вопрос «а не спрятал ли он изменение в скрипте» просто не возникает. Запись в таком случае работает как дополнительный слой наблюдения, а не как единственный забор.

Запись есть, а где она лежит и кто её может посмотреть

Следующая ловушка тоньше. Включить запись сессий и иметь возможность воспроизвести их спустя полгода — разные вещи. В документации по записи отмечено, что сами записи и журнал аудита могут храниться раздельно, и для воспроизведения нужны оба соответствующих компонента. Допустим, вы настроили хранение журнала событий на одном диске, а записи отправили куда-то ещё. Если потерять одно из двух, история станет неполной: либо вы знаете, что сессия была, но не видите её содержимого, либо видите набор записей, но не можете связать его с событиями и людьми.

Для пилота на одной виртуальной машине это превращается в конкретные вопросы, на которые нужно ответить до того, как кто-то получит первый доступ.

1. Где физически лежат записи и события. На том же VPS, что и управляющий компонент, или в отдельном месте. Первый вариант проще для пилота, но тогда потеря машины означает потерю и доступа, и истории.
2. Как долго вы их храните. Срок хранения — это решение команды, а не свойство инструмента. Чем он длиннее, тем больше места нужно, а записи терминальных сессий бывают объёмными, если люди запускают команды с обильным выводом.
3. Кто и как делает копию. На публичной странице MAATRIX не подтверждено, что автоматические резервные копии входят во все тарифы, поэтому копирование журнала и записей следует планировать самостоятельно и проверять восстановление, а не только создание копии.
4. Проверена ли пара «запись плюс журнал». Недостаточно убедиться, что файлы копируются. Нужно хотя бы раз взять копию и воспроизвести по ней тестовую сессию, имея на руках оба компонента.

Размер дискового пространства определяется не только числом людей, но и характером работы. Человек, который весь день читает логи через tail, породит больше вывода, чем тот, кто один раз зашёл поправить параметр. Поэтому в пилоте разумно сначала понаблюдать за приростом на реальной нагрузке небольшой группы и только потом экстраполировать. Любые заранее названные «гигабайты на человека» будут догадкой, а не расчётом.

Кто смотрит записи: роль для проверяющего

Запись сессии — чувствительный материал. В терминале мелькают имена таблиц, фрагменты конфигурации, иногда случайно выведенные значения секретов. Поэтому вопрос «кто имеет право смотреть записи» не менее важен, чем «кто имеет право входить». Справочник по ролям Teleport указывает, что RBAC позволяет ограничивать доступ к записям и активным сессиям по условиям. То есть право входить на сервер и право читать чужие сессии не обязаны идти в одном комплекте.

Теперь деталь, которую легко упустить. В том же справочнике отмечено: более широкая дополнительная роль может расширить доступ к записям. У человека обычно не одна роль, а несколько, и итоговые права складываются из всех. Представим, что для Анны вы аккуратно описали узкую роль инженера тестового контура. Затем ей временно назначили ещё одну роль, чтобы она могла помочь коллегам, и эта вторая роль оказалась шире по просмотру записей. В сумме Анна получает больше, чем вы задумывали, хотя каждая роль по отдельности выглядит разумно.

Отсюда простое правило проверки, которое мы предлагаем от себя, а не берём из документации: оценивайте не роли поодиночке, а совокупность ролей конкретного человека. Для пилота это можно оформить как небольшую таблицу, которую пересматривает кто-то, кроме автора ролей.

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

Что будет, если упадёт сам Teleport

Любая система централизованного доступа порождает неудобный вопрос: а если сломается центр? Пока доступ раздавался ключами, каждый сервер был независим, и потеря одной машины не отключала остальные. Когда вход идёт через управляющий компонент, он становится единой точкой, через которую проходит доступ. Диск заполнился, обновление пошло не так, администратор случайно удалил конфигурацию, виртуальная машина недоступна по причинам вне вашего контроля. И тогда ночью нужно попасть на сервер, а привычного пути нет.

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

• Какой путь аварийного входа остаётся. Например, ограниченное число аппаратных ключей у двух ответственных людей, а не общий файл с паролем.
• Где он хранится и кто знает, как им пользоваться. Запасной путь, о котором помнит только один человек, перестаёт быть запасным в день его отпуска.
• Как отличить аварийный вход от обычного. Такие входы не покрыты записью через управляющий компонент, поэтому их применение нужно фиксировать иначе: в журнале дежурств, в тикете, в журнале самого сервера.
• Как часто вы проверяете, что запасной путь работает. Лучше выяснить, что он сломан, на плановой проверке, чем в момент аварии.

Если вы хотите опереться на аппаратные ключи для такого входа, подробности настройки SSH с ключами FIDO2 и запасным способом доступа разобраны в отдельном материале: вход на Linux-сервер с ключом FIDO2 и запасной доступ. Он хорошо дополняет схему: центральная система удобна для повседневной работы, а аппаратный ключ в сейфе служит страховкой на случай, когда центр недоступен.

Здесь возникает честное противоречие, и его стоит проговорить. Аварийный путь по определению обходит ограничения роли и запись. Чем он шире, тем слабее выигрыш от всей затеи. Поэтому пусть он будет узким по числу людей, редким по применению и громким по следам: каждое использование должно оставлять заметный отпечаток. Идеальной формулы нет, есть компромисс, который команда выбирает осознанно.

Куда поставить пилот и сколько ему нужно ресурсов

Для пилота подойдёт отдельная виртуальная машина с root-доступом, на которой вы разворачиваете управляющий компонент. Отдельная — потому что смешивать центр доступа с чужими сервисами значит размывать границу, которую вы только что пытались провести. Если на той же машине живут рабочий сайт и база, компрометация одного из них задевает и систему допуска.

У MAATRIX в публичном предложении указаны VPS на NVMe с процессорами AMD EPYC и root-доступом; перечислены локации UK, US, RU и FR; оплата возможна картой РФ и через СБП, а VPS создаётся автоматически через пару минут после оплаты. Тарифная линейка начинается с Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) и идёт через Uab (2 vCPU, 4 ГБ, 80 ГБ), Heka (4 vCPU, 8 ГБ, 160 ГБ) и Maat (8 vCPU, 16 ГБ, 240 ГБ) до Djed (16 vCPU, 32 ГБ, 320 ГБ). Эти цифры описывают состав тарифа, а не гарантированную ёмкость под конкретное число пользователей и сессий. Сколько человек и записей выдержит ваш пилот, покажет только наблюдение за собственной нагрузкой.

Практический подход к выбору такой. Начните с небольшого плана и следите за тремя вещами: ростом занятого дискового пространства (особенно если записи лежат на той же машине), загрузкой памяти и временем отклика при подключении. Если место уходит быстрее ожиданий, вынесите хранение записей отдельно или перейдите на план с большим диском. Если подключение стало заметно медленнее, смотрите на процессор и память. Такой путь честнее, чем заранее называть «минимум для десяти человек»: у вас нет данных, чтобы это утверждать, и у автора статьи тоже.

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

Редакция, лицензия и техническая схема — три разных вопроса

Когда команда читает про возможности Teleport, возникает соблазн смешать всё в одну кучу: «умеет — значит, у нас будет». На деле здесь переплетены как минимум три разных слоя, и важно не путать их.

1. Техническая схема. Как устроено развёртывание: где работает управляющий компонент, где хранятся записи и события, как серверы подключаются к системе.
2. Редакция и лицензия. Какие функции входят в вариант, который вы действительно будете использовать. Установка на собственную виртуальную машину сама по себе не означает, что вам доступно всё, что описано в документации к коммерческим вариантам. Часть возможностей может быть привязана к определённой редакции, и это нужно проверять по условиям именно вашего варианта, а не по общему впечатлению от сайта.
3. Ваши процессы. Кто создаёт роли, кто их проверяет, как часто пересматриваются допуски. Ни одна редакция не заменяет эту работу.

Практический вывод: прежде чем обещать коллегам или руководству какую-то автоматизацию — например, согласование доступа по заявке, интеграцию с корпоративным каталогом пользователей или особые способы хранения журнала, — убедитесь, что она описана для той редакции, которую вы будете использовать. Документация, на которую мы ссылаемся в статье, проверялась на дату, указанную в источниках, и версия, установленная у вас, может отличаться. Рекомендуем сверять возможности с документацией вашей версии и с условиями редакции. Хорошая привычка для пилота: в плане рядом с каждой желаемой функцией записать, где именно подтверждена её доступность в вашем варианте, и поставить дату проверки.

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

Чего пилот не обещает

Хорошо оформленный пилот легко превратить в слишком громкое утверждение: «теперь у нас всё под контролем и всё соответствует требованиям». Резко остановим этот дрейф. Централизованный доступ с ролями и записью сессий делает картину доступа яснее и упрощает разбор событий. Но он не гарантирует полную судебную реконструкцию каждого действия: по документации, запись терминала не равна исчерпывающему списку команд, а часть приёмов может её обойти. Он не делает вашу инфраструктуру автоматически соответствующей какому-либо стандарту или закону: соответствие складывается из политик, процессов, обучения людей и многого другого. И он не отменяет базовой гигиены серверов: обновлений, ограничения сетевого доступа, разумных прав внутри самих систем.

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

Допуск, который закончился: как показать, что вход закрыт

Вернёмся к Анне. Две недели прошли, отчёты ускорены, задача закрыта. Старая схема на этом месте обычно ставила вопросительный знак: ключ остаётся в файлах, потому что «может ещё пригодиться», а убирать его никто не торопится. Пилот должен закончить иначе: допуск не просто «планируется закрыть», а закрыт и это можно показать.

Что считать доказательством? Мы предлагаем смотреть на три независимых признака, а не на одну галочку в интерфейсе.

1. Роль снята, учётная запись отключена или срок допуска истёк. Это состояние в самой системе. Но оно говорит о намерении, а не о результате.
2. Попытка входа от имени Анны не проходит. Пусть она сама, по заранее согласованной просьбе, попробует подключиться к тем же трём серверам и получит отказ. Отказ в журнале событий — лучшее подтверждение: видно и попытку, и её результат.
3. На серверах не осталось обходных путей. Это самое важное и самое неприятное. Если параллельно со схемой Teleport на серверах лежат старые личные ключи Анны, то закрытие допуска в центре ничего не значит: человек по-прежнему может войти по старому способу. Поэтому финальная проверка включает ревизию authorized_keys и других мест, где мог остаться прямой вход, на тех самых серверах, куда она ходила.

Третий пункт и есть настоящая проверка всей затеи. Пилот имеет смысл только тогда, когда параллельные пути постепенно закрываются, а не копятся рядом с новым. Если по итогам двух недель оказалось, что у Анны остался рабочий вход мимо центра, это не провал пилота, а ценная находка: вы увидели то самое место, откуда в будущем «вырастут» забытые доступы. Запишите, как её устранили, и повторите ту же проверку для следующего человека.

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