# Смена оператора GPU: реестр выдачи и отзыва ключей доступа

Как передать GPU-сервер другому оператору: реестр персональных доступов, согласованные права, отзыв старых ключей, текущие сессии и фиксация завершения передачи.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/gpu-operator-key-handover/
Language: ru

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

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

## Найдите все виды доступа

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

[OpenSSH sshd](https://man.openbsd.org/sshd) описывает разрешённые публичные ключи и их параметры. Но сервер может использовать не только один файл ключей: важна фактическая конфигурация. Поэтому список нужно собирать по существующей системе, а не по предположению, что все права устроены одинаково.

## Согласуйте порядок передачи

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

Пример реестра без секретных значений:

| Объект | Получатель | Назначение | Статус |
| --- | --- | --- | --- |
| Публичный ключ по отпечатку | Оператор А | Пилот | К отзыву |
| Отдельная учётная запись | Оператор Б | Согласованные задачи | Подготовлена |
| Токен наблюдения | Назначенная служба | Метрики | Требует проверки |
| Административный доступ | Владелец | Контроль передачи | Сохраняется |

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

## Проверьте механизм отзыва

[OpenSSH ssh-keygen](https://man.openbsd.org/ssh-keygen) описывает работу с отпечатками и механизмами отзыва ключей. Конкретный способ зависит от того, как настроена аутентификация вашей машины. Нельзя считать удаление произвольной строки универсальным завершением всей передачи.

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

## Зафиксируйте состояние после передачи

Сохраните время, список изменённых прав и результат контрольной проверки. Новый оператор должен подтвердить только согласованные возможности. Старый доступ проверяется как отдельный пункт, а не выводится из успешного входа нового участника.

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

## Подготовьте разговор о новом пилоте

Передача прав не подтверждает техническую пригодность GPU и не определяет коммерческую модель. Эти вопросы обсуждаются отдельно. Для первичного описания оборудования новому оператору секреты не нужны: достаточно конфигурации и ограничений.

Подготовиться помогут [безопасность оборудования](/ru/journal/hardware-security/) и [условия завершения работы в пуле](/ru/journal/gpu-exit-plan/). Права доступа согласуются под конкретные задачи и срок участия.