Тимоти Равье (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=0660URL: https://tim.siosm.fr/blog/2023/12/19/ssh-over-unix-socket/
Обсуждается: http://www.opennet.dev/tips/info/3239.shtml
Как пример того, что вот можно вот так извернуться - интересное.
Позитив в том, что такие штуки возможны, что возможно дорабатывать и менять.В остальном, такое себе... Изнутри изолированного потребовались повышенные привилегии, которые потом захочется изолировать, но так, чтобы были повышенные привилегии для ...
> Позитив в том, что такие штуки возможны, что возможно дорабатывать и менять.Именно!
С ssh там можно накрутить опупенной логики - добавляешь command="скрипт" в .ssh/authorized_keys (пример тут: https://www.ubuntumint.com/restrict-ssh-user-commands/ ) и этот будет принудительно выполняться. Можно извращаться как по ссылке, можно как-то по-сложному анализировать чо там юзер хотел выполнить и принимать решение нужно ли это выполнять, или выполнить что-то другое, в конце концов можно просто отдельный аудит вести что там вызывали и что возвращено юзеру.
Но, гонять это всё через сокет и на каждый чих стартовать индивидуальный OpenSSH демон - КМК так себе идея :)
Как охранять ключ?Хэш от пароля хоть лежит в /etc/shadow, туда ещё добраться надо и побрутфорсить после, а ключ валяется под ногами у браузера, у некоторых без пароля.
Поэтому голый SSH ключ не нужно использовать (как впрочем и для других SSH соединений). Можно настроить пароль/токен/пароль+токен и проблема решена.
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...
можно например защитить его паролем пользователя, а при входе автоматически разблокировать с помощью pam_ssh
Проблема только в том, что пароль к sudo - в голове у пользователя, а ключ SSH лежит в файле на диске, и процессы, запущенные с правами этого пользователя, имеют права доступа на чтение к нему. Имхо, это ещё менее секьюрно, чем использование suid в sudo.
> Проблема только в том, что пароль к sudo - в голове у
> пользователя, а ключ SSH лежит в файле на диске, и процессы,
> запущенные с правами этого пользователя, имеют права доступа на чтение к
> нему. Имхо, это ещё менее секьюрно, чем использование suid в sudo.Второй абзац статьи: "дополнительно может быть задействовано подтверждение полномочий при помощи USB-токена (например, Yubikey)"
Заслуживающий внимания пример костыля, решающего высосанную из пальца проблему.
Даем полноценного рута по локальному ссш, потому что боимся, что юзер с судо поднимет привилегии до рута? Я ничего не упускаю?
Вообще, чтобы было совсем красношапково и поттерингоугодно, команды нужно отправлять через сервер красной шапки. Локальный демон от рута читает и выполняет все команды, которые с него приходят. Судо не нужно! Корпоративный контроль над всеми выполняемыми командами!
Не корпоративный, а "ориентированный на пользователя (с заботой о пользователе", такой себе ssh-антивирус. Не пропустит злонамеренные команды в шелл!
> заслуживающий внимания способ уходаОчередное "упрощение", которое в итоге выливается во всё бОльшую огороженность системы от модифицирования локальным пользователем (с такими уходами останется одна консоль с клавой и монитором)
Ну так логично, идут по пути Андроида. Хотят чтобы никаких рутов и рут доступа к начинке. Софтик вот уже в флатпаках и снапах, по сути, вне классической системы пакетов. Магазинчики приложений красивые для того же делают, чтобы меньше нос совали.
примерно так использую
$ ssh -X secret@localhost torfi firefox-esr
/home/secret - закриптован
для скрытого сидения в инете, но sudo не отменяет
Почему не использовать современную дыру от поцтеринга: dbus+polkit: https://www.linux.org.ru/forum/security/15600248?cid=15601109Правельный путь CAP: https://www.opennet.dev/openforum/vsluhforumID3/132366.html#85
А ещё вместо классического ssh, использовать вот этот https://github.com/francoismichel/ssh3
Идея красивая, спору нет. Но во-первых - оверхед (ssh-у нужно как ни крути туда-сюда все шифровать), во-вторых уже помянутая проблема необходимости второго фактора, в-третьих - плюс одна пара токенов, которые нужно менеджить и регулярно ротировать.
Способ интересный, но мне кажется лучше всего использовать, если вдруг нужно, не вместо судо а вместе с ним
Особенно с внешними железными ключами
Хз, имеет ли вообще смысл такой сценарий где нибудь на особо секретных предприятиях, где например на проходной тебе каждый день дают новую юсб флешку с ключом