Я работал в организациях, где вместо создания нового пользователя Ubuntu на человека, который хочет войти в систему на компьютере, системные администраторы просто добавляют ключ ssh каждого пользователя .ssh/authorized_keys, а каждый sshна машину - как ( например ) ubuntu@hostили ec2-user@host. (Кстати, я также видел, как это практикуется на общих Mac-мини в лабораторных условиях.) Это общепринятая практика или анти-паттерн?
Рассматриваемые хосты в основном используются для тестирования, но существуют также действия, которые обычно требуют настройки для каждого пользователя и отслеживаются как выполняемые определенным пользователем, такие как создание и отправка коммитов git, которые в настоящее время выполняются с использованием универсального git. пользователь.
источник
Ответы:
Да, это плохая привычка. Он основывается на базовом предположении, что вокруг нет (или не будет) никого злого, и что никто не делает ошибок. Наличие общей учетной записи делает тривиально, что вещи происходят без ответственности и без каких-либо ограничений - пользователь, нарушающий что-то, нарушает это для всех.
Если причиной такой схемы совместного использования uid является просто снижение административных затрат на создание новых учетных записей и настройку общего доступа, то, возможно, администраторам следует потратить некоторое время на систему автоматизации, такую как Ansible , Chef , Puppet или Salt, которая делает такие вещи, как создание пользователя. Аккаунты на нескольких машинах предельно просты.
источник
Начать с того, что меня это не шокирует, и я работаю в крайне защищенной среде. У каждого есть свой пользователь, машина и ключ ssh, и для работы на сервере, который мы используем в качестве root или другого пользователя, через реле регистрации, если это необходимо. Все, что мы делаем, регистрируется как выполненное владельцем ключа ssh, поэтому подотчетность в порядке.
Какой будет альтернатива? Многие вещи должны быть сделаны как определенный пользователь, не говоря уже о root. Sudo? Это нормально для некоторых очень ограниченных задач, но не для системного управления машиной.
Однако я не уверен насчет вашего последнего абзаца, вы имеете в виду, что кто-то может нажать git commit для обычного пользователя? Это нарушит ответственность, а нарушение ответственности - это плохо. Мы делаем git с машины, на которой мы вошли, и мы аутентифицируем git с помощью нашего ключа ssh ...
Аутентификация, авторизация и учет (AAA) - это классическое выражение: вы аутентифицируетесь с помощью своего ключа ssh, вы уполномочены делать все, что может сделать общий пользователь, потому что ваш ключ находится в авторизованных ключах, и вам нужен учет, чтобы делать то, что вы делаете можно пересмотреть после факта.
источник
sudoприемлемо для общего администрирования машины?Это явно зависит от варианта использования системы. Если это система для тестирования время от времени, это хорошо для меня. У нас есть и такие системы. Если компания не имеет какого-либо управления идентификацией (LDAP, IPA), то создание нового пользователя без какого-либо удаленного управления в произвольной системе является довольно обременительным.
Но для каждодневной работы, когда чья-то ошибка делает целую компанию неспособной работать, не очень хорошая идея.
источник
Все эти ответы касаются проблемы подотчетности, которая сама по себе является важной и реальной проблемой, но использование общей учетной записи также допускает не столь тонкие атаки на других пользователей:
Представьте себе, что злоумышленник создает вредоносный
sshскрипт, который регистрирует введенный пароль и помещает егоPATHдля этого общего пользователя (что легко сделать). Теперь следующий человек, который входит в систему на этом компьютере с общим пользователем и решает переместиться вsshкакое-то другое место (на этот раз со своей личной, не общей учетной записью), может иметь неприятный сюрприз.По сути, использование общей учетной записи на компьютере - это все равно, что пить из ванны для ног в общественном бассейне.
источник
В общем, совместное использование одной учетной записи является плохой идеей по следующим причинам:
И конечно, есть еще больше минусов ... Но я не хочу вдаваться в подробности.
Дело в том, что, возможно, вы сталкиваетесь с необходимостью совместного использования учетной записи для управления службой, которая выполняется под определенной учетной записью пользователя, к которой должны иметь доступ все администраторы.
В такой настройке у вас есть возможность поделиться этой учетной записью для входа (по указанным выше причинам я бы предпочел не делать этого), или вы входите индивидуально и затем переключаете пользователя на общую учетную запись (я бы предложил).
Инструменты аудита по-прежнему позволят вам отслеживать, кто что выполнил, но все еще использует ту же учетную запись.
источник