---
title: "Вход и авторизация"
id: "1846"
type: "page"
slug: "login"
published_at: "2026-09-09T10:19:12+00:00"
modified_at: "2026-09-22T15:01:36+00:00"
url: "https://pastukhov.com/agents/agent/docs/login"
markdown_url: "https://pastukhov.com/agents/agent/docs/login.md"
excerpt: "Попасть в Pastukhov Agent можно несколькими способами. Через браузер — обычным входом по логину и…"
---

# Вход и авторизация

[https://pastukhov.com/agents/agent/docs/login.md](https://pastukhov.com/agents/agent/docs/login.md)

**Попасть в Pastukhov Agent можно несколькими способами.** Через браузер — обычным входом по логину и паролю либо **единым входом через сервер**, когда агент открывается сам, без формы. Программно — по **API-ключу** для команд из других программ и через **живые подключения** для событий в реальном времени. Какой бы способ вы ни выбрали, агент выдаёт один и тот же «цифровой пропуск» (JWT-токен) на 90 дней — он поддерживает сеанс, пока не истечёт, повторно проходить регистрацию. Ниже — как устроен каждый способ и что для него настроить.

## Обычный вход

Самый простой способ — ввести логин и пароль на странице входа. Учётные данные задаются переменными окружения `AGENT_LOGIN` (логин) и `AGENT_PASSWORD` (пароль). Пароль хранится в виде SHA256-«отпечатка», а если переменные не заданы, приложение само сгенерирует временный пароль (логин — `code`) и покажет его в консоли.

Обычный вход даёт роль **пользователя**. Подробно о том, откуда берутся учётные данные, как задать переменные и что такое «цифровой пропуск», — на странице [Начало работы](/agents/agent/docs/getting-started)
.

## Единый вход через сервер (SSO)

**Единый вход** (SSO — от англ. single sign-on, «вошёл один раз — везде авторизован») избавляет от ввода пароля в каждый агент. Он включается, когда агент развёрнут на сервере через [Pastukhov MultiAgent](/agents/multiagent)
: на сервере ставится **центральный вход** (Authelia за nginx-шлюзом). Пользователь входит один раз на сервер — и каждый агент открывается сразу, без повторной авторизации.

### Как это работает

Разобрать по шагам:

- **Шлюз пропускает только вошедших.** nginx проверяет центральный вход и пропускает к агенту только авторизованных пользователей. Заодно он добавляет к запросу служебные заголовки: `Remote-User` (имя пользователя), `Remote-Groups` (группы через запятую) и `X-SSO-Token` (общий секрет шлюза);
- **Агент сверяет секрет.** Получив запрос, агент проверяет, совпадает ли `X-SSO-Token` с его переменной окружения `SSO_PROXY_TOKEN`. Если совпадает и `Remote-User` непустой — агент выдаёт свой обычный «цифровой пропуск»;
- **Роль по группе.** Если в `Remote-Groups` есть группа `manager` (без учёта регистра), пользователь получает роль Manager, иначе — обычного пользователя;
- **Тихий вход.** При открытии приложение молча пробует этот вход (не дольше ~5 секунд). Получило токен — сразу открылось, форма входа не показывается. Если входа нет (агент работает без центрального входа или шлюз перенаправил на свою страницу) — как раньше показывается обычная форма входа.

### Что настроить

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

### Почему это безопасно

- Заголовки учитываются только при совпадении секрета `X-SSO-Token` и `SSO_PROXY_TOKEN`; сравнение идёт за постоянное время, поэтому по несовпадению нельзя подобрать секрет;
- nginx перезаписывает эти заголовки, поэтому подделать их из браузера нельзя — они добавляются только самим шлюзом;
- Секрет не хранится в базе данных и не попадает в журналы — его нельзя прочитать изнутри системы;
- Прямой доступ по адресу `host:port` (мимо шлюза) не проходит центральный вход и работает как раньше — с формой авторизации.

## Авторизация через API

Чтобы другие программы управляли агентом без браузера, задайте переменную окружения `AGENT_API_KEY` — это SHA256-«отпечаток» ключа доступа. Программа передаёт сам ключ заголовком `X-API-Key`, и по нему действует роль **Manager** — полный доступ, как при входе менеджером. Подробности и примеры запросов — на странице [API](/agents/agent/docs/api)
.

## Авторизация живых подключений (SignalR)

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

- **Интерфейс браузера** при подключении передаёт свой JWT-токен параметром адреса `access_token` — WebSocket-соединение не умеет заголовки;
- **Внешние программы** передают тот же API-ключ — заголовком `X-API-Key` или параметром адреса `api_key` (для WebSocket параметр адреса обязателен, так как заголовки задать нельзя).

Подробности о живых событиях и авторизации — на странице [API](/agents/agent/docs/api)
.

## Сводная таблица способов доступа

Коротко о каждом способе — когда он нужен и чем подтверждается доступ:

| Способ | Когда используется | Чем подтверждается | Подробнее |
| --- | --- | --- | --- |
| Обычный вход | вход в интерфейс по логину и паролю | AGENT_LOGIN / AGENT_PASSWORD | Начало работы |
| Единый вход (SSO) | интерфейс за шлюзом MultiAgent-сервера | заголовки шлюза + секрет SSO_PROXY_TOKEN | эта статья |
| Вход менеджером | внешнее управление флотом из MultiAgent | MANAGER_PASSWORD | API |
| API-ключ | команды из других программ | X-API-Key / AGENT_API_KEY | API |
| Живые подключения | события в реальном времени | токен access_token или api_key | API |

## Связанные разделы

- [Начало работы](/agents/agent/docs/getting-started) — установка, учётные данные и первый вход;
- [API](/agents/agent/docs/api) — программный доступ: команды, живая подписка и авторизация по ключу;
- [Модели](/agents/agent/docs/models) — переменные окружения, включая ключи и секреты.
- [Обвязки](/agents/agent/docs/backends) — вход в ИИ по подписке Claude (Pro/Max): это оплата ИИ, а не доступ в сам агент.

**← Назад:** [Метки чатов](/agents/agent/docs/chat-labels)

**Далее:** [API](/agents/agent/docs/api)
 →