Czy logowanie się jako użytkownik wspólny to zły nawyk?

35

Pracowałem w organizacjach, w których zamiast tworzyć nowego użytkownika Ubuntu na osobę, która chce się zalogować na maszynie, sysadmins po prostu dodaje klucz ssh każdego użytkownika .ssh/authorized_keysi każdemu sshna maszynie jako ( np. ) ubuntu@hostLub ec2-user@host. (Nawiasem mówiąc, widziałem to również praktykowane na współdzielonych komputerach Mac mini w warunkach laboratoryjnych.) Czy jest to akceptowana praktyka, czy też anty-wzór?

Hosty, o których mowa, są głównie używane do testowania, ale są też podejmowane działania, które zazwyczaj wymagają konfiguracji dla poszczególnych użytkowników i są śledzone jako wykonywane przez określonego użytkownika, takie jak tworzenie i wypychanie zatwierdzeń git, które są obecnie wykonywane przy użyciu ogólnego git użytkownik.

user22a6db72d7249
źródło
23
Podczas gdy wiele osób ma problemy z wielopłaszczyznowymi związkami, inni radzą sobie z nimi dobrze, więc nie sądzę, że dzielenie się ... och, nieważne, miałeś na myśli konto użytkownika .
HopelessN00b
Awww, ktoś zredagował tytuł clickbait .. :(
Burgi

Odpowiedzi:

42

Tak, to zły nawyk. Opiera się na podstawowym założeniu, że nikt nie jest (i nie będzie) złośliwy w pobliżu i nikt nie popełnia błędów. Posiadanie wspólnego konta sprawia, że ​​trywialne rzeczy dzieją się bez odpowiedzialności i bez żadnych ograniczeń - użytkownik, który coś łamie, psuje to wszystkim.

Jeśli powodem tego schematu udostępniania UID jest po prostu obniżenie kosztów administracyjnych związanych z tworzeniem nowych kont i konfiguracją udostępniania, być może administratorzy powinni zainwestować trochę czasu w system automatyzacji, taki jak Ansible , Chef , Puppet lub Salt, który sprawia, że ​​tworzenie konta użytkownika konta na wielu komputerach niezwykle proste.

thkala
źródło
4
To nawet nie jest złośliwość, a nawet nieudolność. Kiedy coś, co robię, nie działa, nie mogę założyć, że pamiętam wszystko, co zostało zrobione na tym koncie.
djechlin
Zasady bezpiecznych danych: Uczciwość Poufność Dostępność Odpowiedzialność. +1 za użycie słowa „odpowiedzialność”
DeveloperWeeks
7

Na początek nie szokuje mnie i pracuję w bardzo bezpiecznym środowisku. Każdy ma swojego użytkownika i maszynę oraz klucz ssh, a do pracy na serwerze ssh, jako root lub jako inny użytkownik, w razie potrzeby za pośrednictwem przekaźnika rejestrującego. Wszystko, co robimy, jest rejestrowane jako wykonane przez właściciela klucza ssh, więc odpowiedzialność jest OK.

Jaka byłaby alternatywa? Wiele rzeczy musi być zrobionych jako określony użytkownik, nie mówiąc już o rootowaniu. Sudo? Nie przeszkadza to w przypadku niektórych bardzo ograniczonych zadań, ale nie dotyczy administrowania maszyną.

Jednak nie jestem pewien co do twojego ostatniego akapitu, czy masz na myśli, że ktoś może zmusić gita do zatwierdzenia zwykłego użytkownika? To złamałoby odpowiedzialność, a zerwanie odpowiedzialności jest złe. Git wykonujemy z komputera, na którym jesteśmy zalogowani i uwierzytelniamy się za pomocą naszego klucza ssh ...

Uwierzytelnianie, autoryzacja i rozliczanie (AAA) to klasyczne wyrażenie: jesteś uwierzytelniany za pomocą klucza ssh, masz uprawnienia do robienia wszystkiego, co może zrobić użytkownik ogólny, ponieważ Twój klucz znajduje się w uprawnionych kluczach i potrzebujesz rozliczania, aby to zrobić może zostać poddany przeglądowi po fakcie.

Law29
źródło
3
Więc ogólny użytkownik ma jakiś rodzaj uwierzytelnienia (klucz ssh?), Który jest upoważniony do modyfikowania repozytorium git? To naprawdę nie jest dobre. Nie tylko dlatego, że łamie to odpowiedzialność za to zatwierdzenie, ale także dlatego, że każda osoba może skopiować ten klucz i użyć go z innego miejsca. Gdy mam tego rodzaju problem, kopiuję kod lub plik różnicowy na komputer lokalny i stamtąd go zatwierdzam.
Law29
2
Dlaczego dokładnie nie można sudozaakceptować ogólnego zarządzania maszyną?
Blacklight Shining
4
logujesz się jako root w „wyjątkowo bezpiecznym środowisku” oO?
xaa
@BlacklightShining Jeśli musisz być w stanie zrobić cokolwiek (chown, chmod dowolne pliki, instalować serwery, montować systemy plików, nic nie zyskasz, sshing jako użytkownik i wykonanie sudo bash. Zamiast tego ssh za pomocą przekaźnika rejestrującego i / lub zaloguj wszystko do zdalnego serwera za pomocą właściciela klucza ssh, który ssh'd.
Law29
1
@xaa Tak, rozumiem i nie widzę z tym problemu. Wszystko, co wpisuję, jest rejestrowane na innych komputerach. „Nie pracuj jako root” jest całkowicie bezużyteczną maksymą, gdy maszyna jest serwerem, na którym wszystko, co możesz chcieć zrobić, wymaga rootowania.
Law29
3

Zależy to oczywiście od przypadku użycia systemu. Jeśli jest to system do testowania od czasu do czasu, jest dla mnie w porządku. Mamy również takie systemy. Jeśli firma nie ma żadnego zarządzania tożsamością (LDAP, IPA), tworzenie nowego użytkownika bez zdalnego sterowania w losowym systemie jest dość obciążające.

Ale dla codziennej pracy, gdy czyjś błąd powoduje, że cała firma nie jest w stanie działać, nie jest dobrym pomysłem.

Jakuje
źródło
Dokładnie, jeśli nie masz lub nie możesz mieć usługi katalogowej, tworzenie tysięcy kont i zarządzanie nimi jest niepraktyczne.
Jim B
Nawet jeśli nie możesz używać LDAP, nadal masz dostęp do SSH (lub PowerShell w systemie Windows). Nadal będziesz potrzebować sposobu zarządzania plikiem autoryzowanych kluczy na swoich hostach dla wszystkich tych kont (chyba że również udostępniasz hasła) i mnóstwem innych ustawień. Zastanawiam się, dlaczego nie używasz jakiegoś rodzaju zarządzania konfiguracją (np. Puppet, Chef, Ansible) Jeśli masz tak wielu użytkowników lub serwerów. Usuwa to obciążenie i daje w zamian kontrolę procesu, rozliczalność i kontrolę.
Martijn Heemels,
3

Wszystkie te odpowiedzi dotyczą obawy o rozliczalność, która sama w sobie jest ważnym i realnym problemem, ale korzystanie ze wspólnego konta pozwala również na niezbyt subtelne ataki na innych użytkowników:

Rozważmy atakującego, który tworzy złośliwy sshskrypt, który rejestruje wpisane hasło i umieszcza je PATHdla tego udostępnionego użytkownika (co jest łatwe do wykonania). Teraz następna osoba, która zaloguje się na tym komputerze ze współużytkowanym użytkownikiem i zdecyduje się sshna inne miejsce (tym razem ze swoim osobistym, nieudostępnionym kontem), może mieć paskudną niespodziankę.

Zasadniczo korzystanie ze wspólnego konta na komputerze jest jak picie z kąpieli stóp na publicznym basenie.

ereOn
źródło
1

Ogólnie rzecz biorąc, udostępnianie jednego konta jest złym pomysłem z następujących powodów:

  1. Każde ustawienie wprowadzone dla tego użytkownika ma wpływ na każdego logującego się. (Promt, aliasy, ...)
    1. Tracisz możliwość dowiedzenia się, kto co zrobił (odpowiedzialność)
    2. Jeden błąd w konfiguracji konta (na przykład przypadkowe usunięcie ssh kay) dotyczy wszystkich osób korzystających z tego konta użytkownika (w tym przykładzie blokowane).

I na pewno jest jeszcze więcej wad ... Ale nie chcę się w to zagłębiać.

Chodzi o to, że może to być konieczność współdzielenia konta w celu zarządzania usługą wykonywaną na określonym koncie użytkownika, do którego wszyscy administratorzy powinni mieć dostęp.

W takiej konfiguracji masz możliwość współdzielenia tego konta w celu zalogowania się (w powyższych przypadkach wolałbym tego nie robić) lub logujesz się indywidualnie i przełączasz użytkownika na wspólne konto (sugerowałbym to).

Narzędzia do inspekcji nadal pozwoliłyby na śledzenie, kto co wykonał, ale nadal udostępnia to samo konto.

Gerhard
źródło