The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Раздел полезных советов: Использование SSH поверх UNIX-сокета вместо sudo"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Использование SSH поверх UNIX-сокета вместо sudo"  +/
Сообщение от auto_tips (?), 20-Дек-23, 12:08 
Тимоти Равье (Timothee Ravier) из компании Red Hat, мэйнтейнер проектов Fedora Silverblue и Fedora Kinoite, [[https://tim.siosm.fr/blog/2023/12/19/ssh-over-unix-socket/ предложил]] заслуживающий внимания способ ухода от применения утилиты sudo, использующей  suid-бит для повышения привилегий. Вместо sudo для выполнения обычным пользователем команд с правами root предлагается задействовать утилиту ssh с локальным соединением к той же системе через UNIX-сокет.

Проверка полномочий осуществляется на основе SSH-ключей. Для ограничения доступ дополнительно может быть задействовано подтверждение полномочий при помощи USB-токена (например, Yubikey). Использование ssh вместо sudo позволяет избавиться от suid-программ в системе и организовать  выполнение привилегированных команд в хост-окружении дистрибутивов, использующих контейнерную изоляцию компонентов, таких как Fedora Silverblue, Fedora Kinoite, Fedora Sericea и Fedora Onyx.

Настраиваем серверные компоненты OpenSSH для доступа через локальный Unix-сокет (будет запускаться отдельный экземпляр sshd со своим файлом конфигурации):

/etc/systemd/system/sshd-unix.socket:

   [Unit]
   Description=OpenSSH Server Unix Socket
   Documentation=man:sshd(8) man:sshd_config(5)

   [Socket]
   ListenStream=/run/sshd.sock
   Accept=yes

   [Install]
   WantedBy=sockets.target

/etc/systemd/system/sshd-unix@.service:

   [Unit]
   Description=OpenSSH per-connection server daemon (Unix socket)
   Documentation=man:sshd(8) man:sshd_config(5)
   Wants=sshd-keygen.target
   After=sshd-keygen.target

   [Service]
   ExecStart=-/usr/sbin/sshd -i -f /etc/ssh/sshd_config_unix
   StandardInput=socket


/etc/ssh/sshd_config_unix:

   # Оставляет только аутентификацию по ключам
   PermitRootLogin prohibit-password
   PasswordAuthentication no
   PermitEmptyPasswords no
   GSSAPIAuthentication no

   # ограничиваем доступ выбранным пользователям
   AllowUsers root adminusername

   # Оставляем только использование .ssh/authorized_keys (без .ssh/authorized_keys2
   AuthorizedKeysFile .ssh/authorized_keys

   # включаем sftp
   Subsystem sftp /usr/libexec/openssh/sftp-server


Активируем и запускаем юнит systemd:

   sudo systemctl daemon-reload
   sudo systemctl enable --now sshd-unix.socket


Добавляем свой SSH-ключ в /root/.ssh/authorized_keys


Настраиваем работу SSH-клиента.

Устанавливаем утилиту socat:

   sudo dnf install socat

Дополняем /.ssh/config, указав socat в качестве прокси для доступа через UNIX-сокет:

   Host host.local
       User root
       # Используем /run/host/run вместо /run для работы из контейнеров
       ProxyCommand socat - UNIX-CLIENT:/run/host/run/sshd.sock

       # Путь к SSH-ключу
       IdentityFile ~/.ssh/keys/localroot

       # Включаем поддержку TTY для интерактивной оболочки
       RequestTTY yes

       # Убираем лишний вывод
       LogLevel QUIET

В текущем виде пользователь adminusername теперь сможет выполнить команды с правами root без ввода пароля. Проверяем работу:

   $ ssh host.local
   [root ~]#


Создаём в bash псевдоним sudohost для запуска "ssh host.local" по аналогии с sudo:

   sudohost() {
       if [[ ${#} -eq 0 ]]; then
           ssh host.local "cd \"${PWD}\"; exec \"${SHELL}\" --login"
       else
           ssh host.local "cd \"${PWD}\"; exec \"${@}\""
       fi
   }

Проверяем:

   $ sudohost id
   uid=0(root) gid=0(root) groups=0(root)


Добавляем проверку полномочий и включаем двухфакторную аутентификацию, допускающую доступ к root только при вставке USB-токена Yubikey.

Проверяем, какие алгоритмы поддерживает  имеющийся Yubikey:

   lsusb -v 2>/dev/null | grep -A2 Yubico | grep "bcdDevice" | awk '{print $2}'

Если выведено 5.2.3 или большее значение, используем ed25519-sk при генерации ключей, иначе - ecdsa-sk:

   ssh-keygen -t ed25519-sk
или
   ssh-keygen -t ecdsa-sk

Добавляет открытый ключ в /root/.ssh/authorized_keys

Добавляем привязку к типу ключа в конфигурацию sshd:

/etc/ssh/sshd_config_unix:

   PubkeyAcceptedKeyTypes sk-ecdsa-sha2-nistp256@openssh.com,sk-ssh-ed25519@openssh.com

Ограничиваем доступ к Unix-сокету только пользователя, которому можно повышать привилегии (в нашем примере - adminusername). В /etc/systemd/system/sshd-unix.socket добавляем:

   [Socket]
   ...
   SocketUser=adminusername
   SocketGroup=adminusername
   SocketMode=0660

URL: https://tim.siosm.fr/blog/2023/12/19/ssh-over-unix-socket/
Обсуждается: https://www.opennet.ru/tips/info/3239.shtml

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от x3who (?), 20-Дек-23, 12:08   +4 +/
Как пример того, что вот можно вот так извернуться - интересное.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3

3. Сообщение от Аноним (3), 20-Дек-23, 15:11   +/
Позитив в том, что такие штуки возможны, что возможно дорабатывать и менять.

В остальном, такое себе... Изнутри изолированного потребовались повышенные привилегии, которые потом захочется изолировать, но так, чтобы были повышенные привилегии для ...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #6

4. Сообщение от Аноним (3), 20-Дек-23, 15:14   +2 +/
Как охранять ключ?

Хэш от пароля хоть лежит в /etc/shadow, туда ещё добраться надо и побрутфорсить после, а ключ валяется под ногами у браузера, у некоторых без пароля.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10, #17, #19

5. Сообщение от Аноним (5), 20-Дек-23, 15:15   +/
Проблема только в том, что пароль к sudo - в голове у пользователя, а ключ SSH лежит в файле на диске, и процессы, запущенные с правами этого пользователя, имеют права доступа на чтение к нему. Имхо, это ещё менее секьюрно, чем использование suid в sudo.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7

6. Сообщение от x3who (?), 20-Дек-23, 16:20   +/
> Позитив в том, что такие штуки возможны, что возможно дорабатывать и менять.

Именно!

С ssh там можно накрутить опупенной логики - добавляешь command="скрипт" в .ssh/authorized_keys (пример тут:  https://www.ubuntumint.com/restrict-ssh-user-commands/ ) и этот будет принудительно выполняться. Можно извращаться как по ссылке, можно как-то по-сложному анализировать чо там юзер хотел выполнить и принимать решение нужно ли это выполнять, или выполнить что-то другое, в конце концов можно просто отдельный аудит вести что там вызывали и что возвращено юзеру.

Но, гонять это всё через сокет и на каждый чих стартовать индивидуальный OpenSSH демон - КМК так себе идея :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

7. Сообщение от x3who (?), 20-Дек-23, 16:49   +2 +/
> Проблема только в том, что пароль к sudo - в голове у
> пользователя, а ключ SSH лежит в файле на диске, и процессы,
> запущенные с правами этого пользователя, имеют права доступа на чтение к
> нему. Имхо, это ещё менее секьюрно, чем использование suid в sudo.

Второй абзац статьи: "дополнительно может быть задействовано подтверждение полномочий при помощи USB-токена (например, Yubikey)"

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

8. Сообщение от Аноним (8), 20-Дек-23, 17:44   +4 +/
Заслуживающий внимания пример костыля, решающего высосанную из пальца проблему.
Даем полноценного рута по локальному ссш, потому что боимся, что юзер с судо поднимет привилегии до рута? Я ничего не упускаю?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9

9. Сообщение от Аноним (8), 20-Дек-23, 17:49   +/
Вообще, чтобы было совсем красношапково и поттерингоугодно, команды нужно отправлять через сервер красной шапки. Локальный демон от рута читает и выполняет все команды, которые с него приходят. Судо не нужно! Корпоративный контроль над всеми выполняемыми командами!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #11

10. Сообщение от Арчевод (?), 20-Дек-23, 17:55   +/
Поэтому голый SSH ключ не нужно использовать (как впрочем и для других SSH соединений). Можно настроить пароль/токен/пароль+токен и проблема решена.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

11. Сообщение от Аноним (11), 20-Дек-23, 17:57   +1 +/
Не корпоративный, а "ориентированный на пользователя (с заботой о пользователе", такой себе ssh-антивирус. Не пропустит злонамеренные команды в шелл!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

12. Сообщение от Аноним (11), 20-Дек-23, 18:00   +/
> заслуживающий внимания способ ухода

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15

14. Сообщение от swarus (ok), 21-Дек-23, 14:56   +/
примерно так использую
$ ssh -X secret@localhost torfi firefox-esr
/home/secret - закриптован
для скрытого сидения в инете, но sudo не отменяет
Ответить | Правка | Наверх | Cообщить модератору

15. Сообщение от Kuromi (ok), 21-Дек-23, 18:19   +1 +/
Ну так логично, идут по пути Андроида. Хотят чтобы никаких рутов и рут доступа к начинке. Софтик вот уже в флатпаках и снапах, по сути, вне классической системы пакетов. Магазинчики приложений красивые для того же делают, чтобы меньше нос совали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

16. Сообщение от Аноним (16), 23-Дек-23, 12:53   +/
Почему не использовать современную дыру от поцтеринга: dbus+polkit: https://www.linux.org.ru/forum/security/15600248?cid=15601109

Правельный путь CAP:  https://www.opennet.ru/openforum/vsluhforumID3/132366.html#85

Ответить | Правка | Наверх | Cообщить модератору

17. Сообщение от Аноним (17), 23-Дек-23, 13:08   +/
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Для хранения ключей рекомендуют использовать апаратные ключи безопасности:
https://www.nitrokey.com/news/2018/nitrokey-partners-linux-f...
https://www.nitrokey.com/news/2019/nitrokey-partners-gentoo-...
https://www.nitrokey.com/news/2021/nitrokey-equips-arch-linu...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

18. Сообщение от Ph0zzy (ok), 24-Дек-23, 00:30   +/
А ещё вместо классического ssh, использовать вот этот https://github.com/francoismichel/ssh3
Ответить | Правка | Наверх | Cообщить модератору

19. Сообщение от Аноним (19), 24-Дек-23, 09:55   +/
можно например защитить его паролем пользователя, а при входе автоматически разблокировать с помощью pam_ssh
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

20. Сообщение от Аноним (20), 27-Фев-24, 22:46   +/
Идея красивая, спору нет. Но во-первых - оверхед (ssh-у нужно как ни крути туда-сюда все шифровать), во-вторых уже помянутая проблема необходимости второго фактора, в-третьих - плюс одна пара токенов, которые нужно менеджить и регулярно ротировать.
Ответить | Правка | Наверх | Cообщить модератору

21. Сообщение от Аноним (21), 01-Апр-24, 14:58   +/
Способ интересный, но мне кажется лучше всего использовать, если вдруг нужно, не вместо судо а вместе с ним
Особенно с внешними железными ключами
Хз, имеет ли вообще смысл такой сценарий где нибудь на особо секретных предприятиях, где например на проходной тебе каждый день дают новую юсб флешку с ключом
Ответить | Правка | Наверх | Cообщить модератору


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру