Как предоставить доступ нескольким системным администраторам 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 и т. д.

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