В нашей команде три опытных системных администратора Linux, которым необходимо администрировать несколько десятков серверов Debian. Раньше мы все работали как root, используя аутентификацию с открытым ключом SSH. Но мы обсудили, что лучше всего подходит для этого сценария, и ни о чем не смогли договориться.
Таким образом, мы будем входить в систему с персонализированными учетными записями с использованием открытых ключей SSH и использовать судо выполнять отдельные задачи с корень разрешения. Вдобавок мы могли бы создать группу «adm», которая позволяет нам просматривать файлы журналов.
Это очень уникальное предложение от одного из системных администраторов. Он предлагает создать трех пользователей в / etc / passwd, у всех которых UID 0, но разные имена для входа. Он утверждает, что это на самом деле не запрещено и позволяет всем иметь UID 0, но при этом иметь возможность проводить аудит.
Что ты предлагаешь?
ИМХО второй вариант самый лучший. Личные аккаунты, доступ sudo. Полностью отключите root-доступ через SSH. У нас есть несколько сотен серверов и полдюжины системных администраторов, вот как мы это делаем.
Как именно переадресация агента прерывается?
Кроме того, если это такая проблема, используйте sudo перед каждой задачей вы можете вызвать оболочку sudo с sudo -s или переключитесь на корневую оболочку с помощью sudo su -
Что касается 3-й предлагаемой стратегии, кроме прочтения useradd -o -u userXXX параметры, рекомендованные @jlliagre, я не знаком с запуском нескольких пользователей с одним и тем же uid. (следовательно, если вы продолжите это делать, мне было бы интересно, можете ли вы обновить сообщение о любых возникающих проблемах (или успехах) ...)
Я предполагаю, что мое первое наблюдение относительно первого варианта «Все открытые ключи SSH помещаются в ~ root / .ssh / authorized_keys2» заключается в том, что если вы абсолютно никогда не собираетесь работать с другими системами;
sudoВторое наблюдение: если вы работаете с системами, которые стремятся к соблюдению HIPAA, PCI-DSS или тому подобному, как CAPP и EAL, вам придется обойти проблемы sudo, потому что:
Так; Использование персонализированных учетных записей и sudo
К сожалению, как системному администратору почти все, что вам нужно сделать на удаленном компьютере, потребует некоторых повышенных разрешений, однако досадно, что большинство инструментов и утилит на основе SSH перестают работать, пока вы находитесь в sudo
Следовательно, я могу передать некоторые уловки, которые использую, чтобы обойти раздражение sudo что вы упомянули. Первая проблема заключается в том, что если вход в систему root заблокирован с помощью PermitRootLogin=no или что у вас нет корня с помощью ключа ssh, тогда файлы SCP становятся чем-то вроде PITA.
Проблема 1: Вы хотите загружать файлы scp с удаленной стороны, но для них требуется root-доступ, однако вы не можете войти в удаленный ящик напрямую как root.
Скучное решение: скопируйте файлы в домашний каталог, chown и scp down.
ssh userXXX@remotesystem, sudo su - и т.д, cp /etc/somefiles к /home/userXXX/somefiles, chown -R userXXX /home/userXXX/somefiles, используйте scp для получения файлов с удаленного компьютера.
Действительно, очень скучно.
Менее скучное решение: sftp поддерживает -s sftp_server flag, поэтому вы можете сделать что-то вроде следующего (если вы настроили 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 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------
Получаем root обычным способом ...
-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 -.
Наполовину запеченный ответ:
Все, что правильно загружает корневую оболочку, будет по праву перезагружать среду, однако есть небольшой обходной путь, который вы можете использовать, когда вам нужны ОБА root-права И возможность использовать SSH-агент, В ТО ЖЕ ВРЕМЯ
Таким образом получается своего рода химерный профиль, который на самом деле не следует использовать, потому что это противный взлом, но это полезно, когда вам нужно передать файлы SCP с удаленного хоста как root на другой удаленный хост.
В любом случае, вы можете разрешить пользователю сохранять свои переменные 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 (но забитый домашний каталог ...)
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#
Третий вариант выглядит идеально, но вы действительно пробовали его, чтобы посмотреть, что происходит? Пока ты мощь см. дополнительные имена пользователей на этапе аутентификации, любой обратный поиск вернет то же значение.
Разрешение прямого доступа root по ssh - плохая идея, даже если ваши машины не подключены к Интернету / не используйте надежные пароли.
Обычно для корневого доступа я использую su, а не sudo.
Я использую (1), но случайно набрал
rm -rf / tmp *
в один злополучный день. Я вижу, будет достаточно плохо, если у вас будет больше, чем несколько администраторов.
(2) Вероятно, более спроектирован - и вы можете стать полноценным пользователем root с помощью sudo su -. Однако несчастные случаи все же возможны.
(3) Я бы не трогал столб баржи. Я использовал его на Suns, чтобы иметь корневую учетную запись не-barebone-sh (если я правильно помню), но она никогда не была надежной - плюс я сомневаюсь, что ее можно было бы хорошо контролировать.
Однозначно ответ 2.
Означает, что вы разрешаете доступ по SSH как root. Если эта машина хоть как-то выставлена на всеобщее обозрение, это просто ужасная идея; Когда я запускал SSH на 22-м порту, мой VPS ежечасно получал несколько попыток аутентификации как root. У меня была базовая IDS, настроенная для регистрации и блокировки IP-адресов, которые делали несколько неудачных попыток, но они продолжали приходить. К счастью, я отключил доступ по SSH как пользователь root, как только у меня была настроена моя учетная запись и sudo. Кроме того, при этом у вас практически нет контрольного журнала.
Предоставляет root-доступ по мере необходимости. Да, у вас едва ли есть какие-либо привилегии в качестве стандартного пользователя, но это в значительной степени именно то, что вам нужно; если учетная запись действительно будет взломана, вы хотите, чтобы ее возможности были ограничены. Вы хотите, чтобы любой доступ суперпользователя требовал повторного ввода пароля. Кроме того, доступом sudo можно управлять через группы пользователей и, если хотите, ограничивать его конкретными командами, что дает вам больше контроля над тем, кто и к чему имеет доступ. Кроме того, команды, выполняемые как sudo, могут регистрироваться, поэтому он обеспечивает гораздо лучший контрольный журнал, если что-то пойдет не так. О, и не запускайте "sudo su -" сразу после входа в систему. Это ужасная, ужасная практика.
Идея вашего системного администратора плохая. И ему должно быть плохо. Нет, машины * nix, вероятно, не остановят вас от этого, но и ваша файловая система, и практически каждое приложение ожидают, что у каждого пользователя будет уникальный UID. Если вы начнете идти по этому пути, я могу гарантировать, что у вас возникнут проблемы. Может не сразу, но рано или поздно. Например, несмотря на отображение приятных понятных имен, файлы и каталоги используют номера UID для обозначения своих владельцев; если вы столкнетесь с программой, у которой есть проблема с повторяющимися UID в дальнейшем, вы не сможете просто изменить UID в вашем файле passwd позже, не выполняя серьезную ручную очистку файловой системы.
sudo это путь вперед. Это может вызвать дополнительные проблемы с запуском команд от имени пользователя root, но дает вам более безопасный ящик как с точки зрения доступа, так и с точки зрения аудита.
Определенно вариант 2, но используйте группы, чтобы дать каждому пользователю как можно больше контроля без необходимости использования sudo. sudo перед каждой командой теряет половину преимущества, потому что вы всегда находитесь в опасной зоне. Если вы сделаете соответствующие каталоги доступными для записи системным администраторам без sudo, вы вернете sudo в исключение, что заставит всех чувствовать себя в большей безопасности.
В старые времена sudo не существовало. Как следствие, единственной доступной альтернативой было наличие нескольких пользователей с UID 0. Но это все еще не так хорошо, особенно с ведением журнала на основе UID для получения имени пользователя.
В настоящее время sudo - единственное подходящее решение. Забудь обо всем остальном.
Это документально подтверждено допустимым фактом. Объединения BSD имеют свою учетную запись toor в течение долгого времени, и пользователи bashroot имеют тенденцию быть принятой практикой в системах, где csh является стандартом (принятая халатность;)
Возможно, я странный, но метод (3) - это тоже то, что пришло мне в голову в первую очередь. Плюсы: у вас будет имя каждого пользователя в журналах, и вы будете знать, кто что делает, как root. Минусы: каждый из них будет постоянно иметь root-права, поэтому ошибки могут быть катастрофическими.
Я хотел бы спросить, зачем вам нужно, чтобы у всех админов был root-доступ. Все 3 метода, которые вы предлагаете, имеют один явный недостаток: как только администратор запускает sudo bash -l или sudo su - или что-то подобное, вы теряете способность отслеживать, кто что делает, и после этого ошибка может иметь катастрофические последствия. Более того, в случае возможного плохого поведения это может даже закончиться намного хуже.
Вместо этого вы можете подумать о другом пути:
Таким образом, martin сможет безопасно обрабатывать postfix, и в случае ошибки или неправильного поведения вы потеряете только свою систему postfix, а не весь сервер.
Та же логика может быть применена к любой другой подсистеме, такой как apache, mysql и т. Д.
Конечно, на данный момент это чисто теоретически, и может быть сложно настроить. Похоже, это лучший способ пойти. По крайней мере, мне. Если кто-нибудь попробует это сделать, дайте мне знать, как это прошло.