Linux

Как предоставить доступ нескольким системным администраторам Linux, работающим от имени пользователя root?

В нашей команде есть три опытных сисадмина Linux, которым приходится администрировать несколько десятков серверов Debian. Ранее мы все работали под правами root, используя аутентификацию с открытым ключом SSH. Но мы обсудили, что является лучшей практикой для этого сценария, и не смогли прийти к единому мнению.

Все открытые ключи SSH помещены в ~root/.ssh/authorized_keys2.

Преимущество: простота использования, пересылка SSH агентов работает легко, небольшие накладные расходы.

Недостаток: отсутствие аудита (вы никогда не узнаете, какой «root» внес изменения). 

Использование персонализированных учетных записей и sudo

Таким образом, мы могли бы входить в систему с персонализированными учетными записями, используя открытые ключи SSH, и использовать sudo для выполнения отдельных задач с правами root. Кроме того, мы можем дать себе группу «adm», которая позволит нам просматривать файлы журналов.

Преимущество: хороший аудит, sudo не позволяет нам слишком легко делать опасные действия.

Недостаток: переадресация SSH-агента ломается, это хлопотно, потому что почти ничего нельзя сделать не под рутом.

Использование нескольких пользователей с UID 0

Это очень уникальное предложение от одного из сисадминов. Он предлагает создать трех пользователей в /etc/passwd, имеющих UID 0, но разные имена входа. Он утверждает, что на самом деле это не запрещено и позволяет всем иметь UID 0, но при этом иметь возможность аудита.

Преимущество: переадресация агентов SSH работает, аудит может работать (не проверено), нет проблем с sudo.

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

Что бы вы предложили?

Ответ 1

Что касается третьей предложенной стратегии, то, кроме изучения опций useradd -o -u userXXX, я не знаком с запуском нескольких пользователей с одним и тем же uid. 

Мое первое замечание относительно первого варианта «Все открытые ключи SSH помещаются в ~root/.ssh/authorized_keys2» заключается в том, что если вы абсолютно не собираетесь работать на других системах, то, по крайней мере, часть времени вам придется работать с учетными записями пользователей и sudo.

Второе замечание заключается в том, что если вы работаете с системами, которые стремятся к соответствию HIPAA, PCI-DSS, или таким вещам, как CAPP и EAL, то вам придется работать с sudo, потому что:

Это промышленный стандарт, обеспечивающий индивидуальные учетные записи пользователей без рута, которые могут быть проверены, отключены, просрочены и т. д., обычно с использованием некоторой централизованной базы данных пользователей.

К сожалению, почти все, что вам как системному администратору нужно делать на удаленной машине, требует повышенных прав, однако раздражает то, что большинство инструментов и утилит, основанных на SSH, не работают, пока вы находитесь в sudo.

Поэтому я могу передать вам несколько фокусов, которые я использую для обхода опасных факторов sudo, о которых вы упомянули. Первая проблема заключается в том, что если вход root заблокирован с помощью PermitRootLogin=no или у вас нет root ключа ssh, то это делает SCP файлы чем-то вроде PITA.

Проблема 1: вы хотите передать файлы по scp с удаленной стороны, но они требуют root-доступа, однако вы не можете войти на удаленную систему как root напрямую.

Простое решение: скопировать файлы в домашний каталог, используя chown или scp.

ssh userXXX@remotesystem, sudo su - etc, cp /etc/somefiles to /home/userXXX/somefiles, chown -R userXXX /home/userXXX/somefiles, используйте scp для получения файлов с удаленного компьютера.

Более грамотное решение: sftp поддерживает флаг -s sftp_server, поэтому вы можете сделать что-то вроде следующего (если вы настроили беспарольный sudo в /etc/sudoers):

sftp  -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \

userXXX@remotehost:/etc/resolv.conf 

 (вы также можете использовать этот обходной путь с sshfs, но я не уверен, что это сработает...)

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

Метод Port Forward Ninja:

Войдите на удаленный хост, но укажите, что удаленный порт 3022 (может быть любым свободным и не зарезервированным для администраторов, т. е. >1024) должен быть перенаправлен обратно на порт 22 на локальной машине.

[localuser@localmachine ~]$ ssh userXXX@remotehost -R 3022:localhost:22

Last login: Mon May 21 05:46:07 2019 from 123.123.123.123

 

Получите root обычным способом:

-bash-3.2$ sudo su -

[root@remotehost ~]# 

 Теперь вы можете передавать файлы по scp в другом направлении, избегая шага создания промежуточной копии файлов:

[root@remotehost ~]#  scp -o NoHostAuthenticationForLocalhost=yes \

 -P3022 /etc/resolv.conf localuser@localhost:~

localuser@localhost's password: 

resolv.conf                                 100%  

[root@remotehost ~]#  

Проблема 2: переадресация агентов SSH. Если вы загружаете корневой профиль, например, указывая оболочку для входа, необходимые переменные окружения для пересылки агента SSH, такие как SSH_AUTH_SOCK, сбрасываются, поэтому пересылка агента SSH «ломается» под sudo su -.

Половинчатый ответ:

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

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

В любом случае вы можете разрешить пользователю сохранять свои переменные ENV, установив следующее в sudoers:

Defaults:userXXX    !env_reset

это позволяет вам создавать гибридные среды входа в систему, например:

[localuser@localmachine ~]$ ssh userXXX@remotehost 

Last login: Mon May 21 12:33:12 2019 from 123.123.123.123

-bash-3.2$ env | grep SSH_AUTH

SSH_AUTH_SOCK=/tmp/ssh-qwO715/agent.1971

 

создать оболочку bash, которая запускает /root/.profile и /root/.bashrc, но сохраняет SSH_AUTH_SOCK.

-bash-3.2$ sudo -E bash -l

 Таким образом, эта оболочка имеет права root и root $PATH.

bash-3.2# id

uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:system_r:unconfined_t

bash-3.2# echo $PATH

/usr/kerberos/sbin:/usr/local/sbin:/usr/sbin:/sbin:/home/xtrabm/xtrabackup-manager:/usr/kerberos/bin:/opt/admin/bin:/usr/local/bin:/bin:/usr/bin:/opt/mx/bin

 Вы можете использовать этот вызов для выполнения действий, требующих удаленного доступа к sudo root, а также доступа к агенту SSH, например, так:

bash-3.2# scp /root/.ssh/authorized_keys ssh-agent-user@some-other-remote-host:~

/root/.ssh/authorized_keys              100%  126     0.1KB/s   00:00    

bash-3.2# 

Ответ 2

Определенно, я бы использовал вариант 2.

  1. Это означает, что вы разрешаете доступ к SSH как root. Если эта машина каким-либо образом связана с внешней сетью это небезопасный вариант. Когда я запускал SSH через порт 22, мой VPS ежечасно получал множество попыток аутентифицироваться как root. У меня была базовая IDS, настроенная на регистрацию и запрет IP-адресов, которые делали несколько неудачных попыток, но они продолжали приходить. К счастью, я отключил доступ к SSH от имени пользователя root, как только у меня появилась собственная учетная запись и настроен sudo. Кроме того, в этом случае у вас практически нет аудиторского следа.

  2. Предоставляет root-доступ по мере необходимости. Да, у вас почти нет привилегий как у обычного пользователя, но это именно то, что вам нужно; если учетная запись будет взломана, вы захотите, чтобы ее возможности были ограничены. Вы также захотите, чтобы любой доступ суперпользователя требовал повторного ввода пароля. Кроме того, доступ к sudo можно контролировать через группы пользователей и ограничивать определенные команды, что дает вам больше контроля над тем, кто к чему имеет доступ. Кроме того, команды, выполняемые от имени sudo, могут записываться в журнал, что позволяет лучше отслеживать ситуацию, если что-то пошло не так. О, и не запускайте команду «sudo su –» сразу после входа в систему. Это очень плохая практика.

  3. Идея вашего сисадмина плоха. Машины *nix, вероятно, не помешают вам это сделать, но и ваша файловая система и практически все приложения ожидают, что каждый пользователь будет иметь уникальный UID. Если вы начнете идти по этому пути, я могу гарантировать, что вы столкнетесь с проблемами. Может быть, не сразу, но рано или поздно. Например, несмотря на красивые дружественные имена, файлы и каталоги используют номера UID для обозначения своих владельцев; если вы столкнетесь с программой, у которой есть проблема с дублированием UID, вы не сможете просто изменить UID в файле passwd, не прибегая к серьезной ручной очистке файловой системы.

Ответ 3

Вариант 3 это то, что первым пришло мне в голову. 

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

Минусы: каждый из админов постоянно будет root, поэтому ошибки могут быть катастрофическими.

Я бы хотел спросить, зачем вам нужно, чтобы все администраторы имели root-доступ. Все три предложенных вами метода имеют один явный недостаток: как только администратор запускает sudo bash -l или sudo su - или что-то подобное, вы теряете возможность отслеживать, кто что делает, и после этого ошибка может быть катастрофической. Более того, в случае возможного неправильного поведения это даже может закончиться гораздо хуже.

Вместо этого лучше пойти другим путем:

  1. Создайте своих администраторов как обычных пользователей.

  2. Решите, кто какую работу должен выполнять (управление apache/управление postfix и т. д.).

  3. Добавьте пользователей в соответствующие группы (например, добавьте «Мартин» в «postfix» и «mail», «amavis», если вы его используете, и т. д.).

  4. Исправьте права доступа (chmod -R g+w postfix:postfix /etc/postfix).

  5. Дайте только относительные права sudo: (visudo -> разрешить «Мартину» использовать /etc/init.d/postfix , /usr/bin/postsuper и т. д.).

Таким образом, Мартин сможет безопасно работать с postfix, и в случае ошибки или неправильного поведения вы потеряете только систему postfix, а не весь сервер.

Та же логика может быть применена к любой другой подсистеме, такой как apache, mysql и т. д.

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

Схожие статьи

Linux

Существующие решения, позволяющие использовать контроль версий для файлов конфигурации сервера

Linux

Как использовать sudo для перенаправления вывода, если у меня нет разрешения на запись

Как установить GRUB Customizer в Manjaro и в Ubuntu, редактирование загрузчика
Linux

Как установить GRUB Customizer в Manjaro и в Ubuntu, редактирование загрузчика

Linux

Допустимая средняя нагрузка на сервер