SSH i uprawnienia do katalogu domowego

53

Wiele godzin zajęło mi rozwiązanie tego problemu SSH z jednym z moich kont klasy na serwerach mojej szkoły.

Nie mogłem ssh na jednym konkretnym koncie klasy bez podania hasła, podczas gdy uwierzytelnianie bez hasła działało z moimi innymi kontami klasy. Katalog .ssh / i cała jego zawartość miały takie same, poprawne uprawnienia jak inne konta klas.

Okazuje się, że problemem były uprawnienia ustawione w moim katalogu domowym. Uwierzytelnianie bez hasła nie działało, gdy uprawnienia do mojego katalogu HOME były ustawione na 770 (niezależnie od uprawnień ustawionych dla .ssh /), ale działało z uprawnieniami ustawionymi na 755 lub 700.

Czy ktoś wie, dlaczego robi to SSH? Czy to dlatego, że uprawnienia do katalogu domowego są zbyt liberalne? Dlaczego SSH odmawia uwierzytelnienia za pomocą kluczy publicznych / prywatnych, gdy katalog domowy jest ustawiony na więcej niż 700?

ssh permissions

— action_potato
źródło

1

Potwierdził poniższe odpowiedzi; problem polegał na tym, że uprawnienia grupy do folderu domowego były niepoprawnie ustawione (komunikat o błędzie z auth.log brzmiał: „Odmowa uwierzytelnienia: złe prawo własności lub tryby dla katalogu / home / <użytkownik>). Widzę, że SSH ma rację, jeśli chodzi o wybory dotyczące domowego katalogu.

— action_potato

5

Czy wiesz o tagach wiki, które mamy tutaj? Jeśli klikniesz ssh, a następnie learn morezobaczysz listę kontrolną, co zrobić, gdy SSH nie działa, i wspomniane są uprawnienia do katalogu domowego.

— Gilles 'SO - przestań być zły'

Ach, przepraszam, nie wiedziałem o tym! Dzięki za heads-upy.

— action_potato

54

Jest to domyślne zachowanie dla SSH. Chroni klucze użytkownika poprzez wymuszenie rwx------na $HOME/.sshi zapewniając tylko właściciel ma uprawnienia do zapisu $HOME. Jeśli użytkownik inny niż odpowiedni właściciel ma uprawnienia do zapisu w $HOMEkatalogu, może złośliwie zmodyfikować uprawnienia $HOME/.ssh, potencjalnie przejmując klucze użytkownika known_hostslub coś podobnego. Podsumowując, poniższe uprawnienia $HOMEbędą wystarczające do działania SSH.

rwx------
rwxr-x---
rwxr-xr-x

SSH nie będzie działać prawidłowo i wysyła ostrzeżenia do obiektów dziennika w przypadku jakiejkolwiek zmiany przedsięwzięcia g+wlub o+wistnieje w $HOMEkatalogu. Administrator może jednak zastąpić to zachowanie, definiując StrictModes now sshd_config(lub podobnym) pliku konfiguracyjnym, chociaż powinno być jasne, że nie jest to zalecane .

— George M.
źródło

1

Dzięki za wzmiankę StrictModes no. W moim ustawieniu lista ACL jest skonfigurowana w katalogu osobistym użytkownika docelowego i wszystkich potomków, aby umożliwić modyfikacje przez użytkownika z ograniczoną odpowiedzialnością ( u:operator:rwx), a SSH tego nie lubił.

— intelfx,

31

77x w twoim katalogu domowym oznacza, że każdy z poprawnym GID może przenieść twój katalog .ssh i zastąpić go innym. Użytkownicy z prawidłowym identyfikatorem GID mają uprawnienia do zapisu / wykonania w katalogu domowym i dlatego mogą zmieniać nazwę / tworzyć pliki / katalogi.

SSH jest bardzo wybredna, jeśli chodzi o uprawnienia i powinna.

— jippie
źródło