Вход в систему с правами общего доступа

35

Я работал в организациях, где вместо создания нового пользователя Ubuntu на человека, который хочет войти в систему на компьютере, системные администраторы просто добавляют ключ ssh каждого пользователя .ssh/authorized_keys, а каждый sshна машину - как ( например ) ubuntu@hostили ec2-user@host. (Кстати, я также видел, как это практикуется на общих Mac-мини в лабораторных условиях.) Это общепринятая практика или анти-паттерн?

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

ssh user-management

— user22a6db72d7249
источник

23

В то время как у многих людей возникают проблемы с полиамурными отношениями, другие справляются с ними просто отлично, поэтому я не думаю, что это обязательно «плохая привычка» делиться ... о, неважно, вы имели в виду учетную запись пользователя .

— HopelessN00b

Аууу, кто-то отредактировал название кликбэйта .. :(

— Burgi

42

Да, это плохая привычка. Он основывается на базовом предположении, что вокруг нет (или не будет) никого злого, и что никто не делает ошибок. Наличие общей учетной записи делает тривиально, что вещи происходят без ответственности и без каких-либо ограничений - пользователь, нарушающий что-то, нарушает это для всех.

Если причиной такой схемы совместного использования uid является просто снижение административных затрат на создание новых учетных записей и настройку общего доступа, то, возможно, администраторам следует потратить некоторое время на систему автоматизации, такую как Ansible , Chef , Puppet или Salt, которая делает такие вещи, как создание пользователя. Аккаунты на нескольких машинах предельно просты.

— thkala
источник

4

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

— Джечлин

Принципы защиты данных: целостность, конфиденциальность, доступность, ответственность. +1 за использование слова подотчетность

— DeveloperWeeks

7

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

Какой будет альтернатива? Многие вещи должны быть сделаны как определенный пользователь, не говоря уже о root. Sudo? Это нормально для некоторых очень ограниченных задач, но не для системного управления машиной.

Однако я не уверен насчет вашего последнего абзаца, вы имеете в виду, что кто-то может нажать git commit для обычного пользователя? Это нарушит ответственность, а нарушение ответственности - это плохо. Мы делаем git с машины, на которой мы вошли, и мы аутентифицируем git с помощью нашего ключа ssh ...

Аутентификация, авторизация и учет (AAA) - это классическое выражение: вы аутентифицируетесь с помощью своего ключа ssh, вы уполномочены делать все, что может сделать общий пользователь, потому что ваш ключ находится в авторизованных ключах, и вам нужен учет, чтобы делать то, что вы делаете можно пересмотреть после факта.

— Law29
источник

3

Таким образом, у обычного пользователя есть какая-то аутентификация (ключ ssh?), Которой разрешено изменять git-репо? Это действительно не хорошо. Не только потому, что это нарушает ответственность за этот коммит, но и потому, что любой человек может скопировать этот ключ и использовать его откуда-то еще. Когда у меня возникает такая проблема, я копирую код или diff на свой локальный компьютер и фиксирую его оттуда.

— Закон 29

2

Почему именно не sudoприемлемо для общего администрирования машины?

— Blacklight Shining

4

ты ssh в качестве root в "чрезвычайно защищенной среде" oO?

— Xaa

@BlightlightShining Если вам нужно что-либо делать (chown, chmod, произвольные файлы, устанавливать серверы, монтировать файловые системы, ничего не получится, если вы зайдете в систему как пользователь и выполните команду sudo bash. Вместо этого используйте ssh при использовании реле регистрации). и / или зарегистрируйте все на удаленном сервере с владельцем ключа ssh, который входил в ssh'd.

— Law29

1

@ xaa Да, и я не вижу проблемы с этим. Все, что я печатаю, регистрируется на других машинах. «Не работайте с правами root» - это абсолютно бесполезный принцип, когда машина является сервером, где все, что вы, возможно, захотите сделать, требует, чтобы вы были пользователем root.

— Law29

3

Это явно зависит от варианта использования системы. Если это система для тестирования время от времени, это хорошо для меня. У нас есть и такие системы. Если компания не имеет какого-либо управления идентификацией (LDAP, IPA), то создание нового пользователя без какого-либо удаленного управления в произвольной системе является довольно обременительным.

Но для каждодневной работы, когда чья-то ошибка делает целую компанию неспособной работать, не очень хорошая идея.

— Jakuje
источник

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

— Джим Б

Даже если вы не можете использовать LDAP, у вас все равно есть SSH-доступ (или Powershell в Windows). Вам по-прежнему понадобится способ управления файлом author_keys на ваших хостах для всех этих учетных записей (если вы не делите пароли) и множество других настроек. Мне интересно, почему вы не используете какое-то управление конфигурацией (например, Puppet, Chef, Ansible), если у вас так много пользователей или серверов. Снимает это бремя и дает вам контроль над процессом, подотчетность и возможность аудита в ответ.

— Мартейн Химельс

3

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

Представьте себе, что злоумышленник создает вредоносный sshскрипт, который регистрирует введенный пароль и помещает его PATHдля этого общего пользователя (что легко сделать). Теперь следующий человек, который входит в систему на этом компьютере с общим пользователем и решает переместиться в sshкакое-то другое место (на этот раз со своей личной, не общей учетной записью), может иметь неприятный сюрприз.

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

— ereOn
источник

1

В общем, совместное использование одной учетной записи является плохой идеей по следующим причинам:

Все настройки, сделанные для этого пользователя, влияют на всех, кто входит в систему. (Promt, aliases, ...)
1. Вы теряете возможность узнать, кто что сделал (ответственность)
2. Одна ошибка в настройке учетной записи (например, случайное удаление ssh kay) затрагивает всех, кто использует эту учетную запись пользователя (в этом примере блокировка).

И конечно, есть еще больше минусов ... Но я не хочу вдаваться в подробности.

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

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

Инструменты аудита по-прежнему позволят вам отслеживать, кто что выполнил, но все еще использует ту же учетную запись.

— Gerhard
источник

Вход в систему с правами общего доступа - плохая привычка?