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

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.

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.

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.

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.

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.

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, ...)
   2. Tracisz możliwość dowiedzenia się, kto co zrobił (odpowiedzialność)
   3. 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.