Czy możliwości rejestrowania SSH są równoważne rejestrowaniu su w celu uwierzytelnienia klucza prywatnego / publicznego?

W pracy mamy wspólne konto logowania użytkownika innego niż root w systemie UNIX, które służy do administrowania określoną aplikacją. Zasada nie zezwala na bezpośrednie logowanie do wspólnego konta; musisz zalogować się jako użytkownik i użyć polecenia „su”, aby przełączyć się na wspólne konto. Służy to do rejestrowania / bezpieczeństwa.

Zacząłem używać uwierzytelniania klucza publicznego / prywatnego SSH z agentem, aby umożliwić mi wprowadzanie hasła raz dziennie, a przekazywanie przez agenta eliminuje monitowanie o hasło na resztę dnia. To jest naprawdę ładne.

Jednak niektóre systemy są zablokowane, więc naprawdę muszę użyć polecenia „su”, aby uzyskać dostęp do wspólnego konta. Arg! Wróć do ciągłego wprowadzania haseł!

Czy istnieje wystarczająca ilość informacji zarejestrowanych za pomocą uwierzytelniania SSH za pomocą klucza publicznego / prywatnego, tak że mógłbym mieć uzasadnioną szansę zażądania zmiany zasad, aby umożliwić zdalne logowanie do wspólnego konta, jeśli używane są klucze publiczne / prywatne?

Miałem administratora, który szukał w / var / log / secure i po prostu mówi, że klucz publiczny został zaakceptowany dla konta użytkownika z określonego adresu IP. Nie mówiło, kto to jest klucz publiczny, ani kto klucz prywatny dokonał uwierzytelnienia.

sshd_configPlik ma wiele poziomów rejestrowania . Zobacz stronę podręcznika i poszukaj LogLevel. Domyślnym poziomem jest, INFOale banalnie łatwo go podbić do VERBOSEjednego lub nawet jednego z DEBUG#poziomów.

Ponadto powinieneś zbadać sudojako alternatywę dla su. Pełna dyskusja na temat korzyści sudobyłaby kwestią samą w sobie. Ale mogę powiedzieć, że dzięki sudoniemu możesz dostosować częstotliwość wpisywania hasła, które komendy mogą być uruchamiane itp., Wszystkie kontrolowane przez plik konfiguracyjny sudoers .

Innym sposobem byłoby wyjście authorized_keyspoza zakres użytkownika (na przykład do /etc/ssh/authorized_keys), aby tylko sysadmins kontrolowali, które klucze publiczne mogą być używane do rejestrowania na danych kontach.

Kiedyś zmienialiśmy AuthorizedKeysFiledyrektywę sshd_configna coś takiego.

AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Następnie utwórz i zapełnij /etc/ssh/authorized_keyskatalog plikami dla każdego użytkownika, który powinien być w stanie się zalogować, upewniając się, że rootplik jest czytelny / zapisywalny tylko w katalogu głównym, a inne pliki czytelne dla odpowiedniego użytkownika, na przykład:

-rw-------  1 root root    1,7K 2008-05-14 14:38 root
-rw-r-----  1 root john     224 2008-11-18 13:15 john

Każdy plik zawiera zestaw kluczy publicznych, które będą mogły logować się na dane konto. Jest to dość powszechne dla każdego konta użytkownika, do którego należy również odpowiednia grupa.

Korzystanie z kluczy publicznych / prywatnych jest o wiele lepszą metodą kontrolowania zdalnego dostępu użytkowników. Nie musisz zmieniać hasła co miesiąc (nie musisz go też ustawiać) i nie musisz go zmieniać tylko dlatego, że pracownik opuścił Twoją firmę, po prostu usuwając swój klucz publiczny; i oczywiście dzięki opcjom SSH ( http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8#SSHRC) możesz dokładnie określić, co i skąd dany użytkownik może mieć dostęp.

Uwierzytelnianie klucza publicznego / prywatnego SSH jest niezależne od uwierzytelniania hosta. Nie masz tu szczęścia. Można jednak zażądać, aby członkowie konkretnej grupy mogli uruchamiać określone polecenia administracyjne sudobez hasła - tak jak w przykładzie poniżej użytkownicy w secretariesgrupie mogą zarządzać kontami:

# file: /etc/sudoers
...
%secretaries    ALL= NOPASSWD: /usr/bin/adduser, /usr/bin/rmuser   
...