Несколько системных администраторов Linux, работающих как root

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

Публичный ключ каждого SSH помещается в ~ root / .ssh / authorized_keys2

• Преимущество: простота в использовании, переадресация агента SSH работает легко, небольшие затраты
• Недостаток: отсутствие аудита (вы никогда не знаете, какой «корень» внес изменения), несчастные случаи более вероятны

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

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

• Преимущество: хороший одитинг, sudo мешает нам делать идиотские вещи слишком легко
• Недостаток: переадресация агента SSH, это хлопотно, потому что едва ли можно сделать что-либо без полномочий root

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

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

• Преимущество: переадресация агента SSH, аудит может работать (не проверено), нет проблем с sudo
• Недостаток: чувствует себя довольно грязно - нигде не могу найти документально подтвержденный способ

Что ты предлагаешь?

Второй вариант ИМХО самый лучший. Личные счета, доступ sudo. Полностью отключите root-доступ через SSH. У нас есть несколько сотен серверов и полдюжины системных администраторов, вот как мы это делаем.

Как происходит переадресация агента?

Кроме того, если sudoперед каждым заданием стоит такая сложность, вы можете вызвать оболочку sudo с помощью sudo -sили переключиться на корневую оболочку с помощьюsudo su -

Что касается 3-й предложенной стратегии, кроме прочтения useradd -o -u userXXXопций, рекомендованных @jlliagre, я не знаком с несколькими пользователями, использующими один и тот же uid. (следовательно, если вы продолжите в том же духе, мне было бы интересно, если бы вы могли обновить пост с любыми проблемами (или успехами), которые возникают ...)

Полагаю, мое первое замечание, касающееся первого варианта «Открытый ключ каждого SSH помещен в ~ root / .ssh / авторизованный_кейс2», заключается в том, что если вы абсолютно никогда не собираетесь работать на каких-либо других системах;

1. тогда, по крайней мере, иногда вам придется работать с учетными записями пользователей иsudo

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

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

Так; Использование персонализированных аккаунтов и sudo

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

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

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

Скучное решение : скопируйте файлы в домашнюю директорию, chown и scp down.

ssh userXXX@remotesystem, sudo su -etc, cp /etc/somefilesto /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 без пароля или по какой-то настроенной причине, что вышеуказанный метод не работает, я могу предложить еще один менее скучный способ передачи файлов для доступа к удаленным корневым файлам.

Метод форварда ниндзя :

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

 [localuser@localmachine ~]$ ssh userXXX@remotehost -R 3022:localhost:22
Last login: Mon May 21 05:46:07 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------

Получить рут обычным способом ...

-bash-3.2$ sudo su -
[root@remotehost ~]# 

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

[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 -.

Полупеченый ответ :

Все, что должным образом загружает корневую оболочку, будет по праву сбрасывать среду, однако есть небольшой обходной путь, который вы можете использовать, когда вам нужны ОБА корневое разрешение И возможность использовать SSH-агент, ОДНОВРЕМЕННО

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

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

 Defaults:userXXX    !env_reset

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

войдите как обычно;

[localuser@localmachine ~]$ ssh userXXX@remotehost 
Last login: Mon May 21 12:33:12 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------
-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(но домашний каталог borked ...)

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

Но вы можете использовать этот вызов для выполнения задач, требующих удаленного root-доступа sudo, но также доступа к агенту 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# 

Третий вариант выглядит идеально - но вы действительно пробовали его, чтобы увидеть, что происходит? Хотя вы можете увидеть дополнительные имена пользователей на этапе аутентификации, любой обратный поиск будет возвращать то же значение.

Разрешение прямого прямого доступа по SSH - плохая идея, даже если ваши машины не подключены к Интернету / используют надежные пароли.

Обычно я использую 'su', а не sudo для корневого доступа.

Я использую (1), но я случайно набрал

rm -rf / tmp *

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

(2) Вероятно, более сложный - и вы можете стать полноценным пользователем root с помощью sudo su -. Несчастные случаи все еще возможны все же.

(3) Я бы не трогал палкой баржи. Я использовал его на Suns, чтобы иметь учетную запись root не-barebone-sh (если я правильно помню), но она никогда не была надежной - плюс я сомневаюсь, что это будет очень одитивно.

Определенно ответ 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 позже, не выполнив серьезную ручную очистку файловой системы.

sudoэто путь вперед. Это может привести к дополнительным хлопотам при запуске команд от имени пользователя root, но предоставляет вам более безопасный ящик как с точки зрения доступа, так и с точки зрения аудита.

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

В старые времена Судо не существовало. Как следствие, наличие нескольких пользователей UID 0 было единственной доступной альтернативой. Но это все еще не так хорошо, особенно с регистрацией на основе UID для получения имени пользователя.

В настоящее время sudo является единственным подходящим решением. Забудь что-нибудь еще.

Это задокументировано допустимым фактом. У подразделений BSD долгое время была учетная запись toor, и пользователи bashroot обычно практикуются в системах, где стандарт csh является стандартным (допустимая халатность;)

Возможно, я странный, но метод (3) - это то, что сначала пришло мне в голову. Плюсы: у вас будет имя каждого пользователя в логах и вы будете знать, кто что сделал от имени root. Минусы: каждый из них всегда был бы root, поэтому ошибки могут быть катастрофическими.

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

Вместо этого вы можете рассмотреть возможность пойти другим путем:

• Создайте своих администраторов как обычных пользователей
• Решите, кто должен выполнять какую работу (управление apache / управление postfix и т. Д.)
• Добавьте пользователей в связанные группы (например, добавьте «martin» в «postfix» и «mail», «amavis», если вы используете его и т. Д.)
• Исправить права доступа (chmod -R g + w postfix: postfix / etc / postfix)
• дать только относительные полномочия sudo: (visudo -> позвольте martin использовать /etc/init.d/postfix, / usr / bin / postsuper и т. д.)

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

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

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