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