Uprawnienia do klucza prywatnego w folderze .ssh?

380

Zmieniłem swoje uprawnienia w .sshfolderze i teraz, gdy korzystam z oprogramowania używającego mojego klucza prywatnego, muszę za każdym razem wpisywać hasło. Jakie powinny być moje uprawnienia do mojego id_rsapliku, aby nie musieć wpisywać hasła za każdym razem, gdy korzystam z aplikacji, która go używa?

Obecnie moje uprawnienia są ustawione na:

-rw-------@ 1 Jody  staff   114 Nov  4 23:29 config
-rw-------  1 Jody  staff  1743 Oct 21  2009 id_rsa
-rw-------@ 1 Jody  staff   397 Oct 21  2009 id_rsa.pub 
-rw-------@ 1 Jody  staff  3855 Sep 13 22:35 known_hosts

— JakeGould
źródło

638

Zazwyczaj chcesz, aby uprawnienia były:

.ssh informator: 700 (drwx------)
klucz publiczny ( .pubplik):644 (-rw-r--r--)
klucz prywatny ( id_rsa):600 (-rw-------)
wreszcie twój katalog domowy nie może być zapisywany przez grupę lub inne osoby (co najwyżej 755 (drwxr-xr-x)).

Zakładam, że masz na myśli to, że musisz za każdym razem wprowadzać hasło systemowe / hasło użytkownika, a wcześniej nie było to konieczne. Odpowiedź cdhowie zakłada, że ustawiasz hasło / hasło podczas generowania kluczy, a jeśli tak, to jak mówi, będziesz musiał wprowadzić hasło za każdym razem, chyba że użyjesz agenta ssh.

— Fabs
źródło

13

Odkryłem gdzie indziej, że jeśli używasz pliku Author_keys, powinien on być chmod'd do 640, tj. -Rw-r -----.

— AnneTheAgile,

5

Gdzie mogę znaleźć te informacje na stronach podręcznika?

— Sonique

131

Wróciłem do tego postu około 30 razy. Nie mogę uwierzyć, że nie pamiętam tego.

— JREAM

7

Jedyne ważne rzeczy to to, że nic w .ssh nie jest możliwe do zapisu dla nikogo innego i żaden z tajnych kluczy nie jest czytelny dla nikogo innego.

— Markus Kuhn

5

@Cerin uprawnienie do wykonywania katalogu daje możliwość wyświetlania bezpośrednich plików potomnych / katalogów tego katalogu, pliki w folderze nie „dziedziczą” bitu wykonawczego swojego folderu nadrzędnego.

— Thomas

86

Walczyłem z tym na zawsze i w końcu zorientowałem się, co jest potrzebne. Zamień $USERwszędzie na nazwę użytkownika SSH, na którą chcesz się zalogować na serwerze. Jeśli próbujesz zalogować się tak root, jak trzeba użyć /root/.sshitp., Zamiast tego /home/root/.sshjest tak w przypadku użytkowników innych niż root.

Inni użytkownicy nie powinni zapisywać katalogu domowego na serwerze: chmod go-w /home/$USER
Folder SSH na serwerze wymaga 700 uprawnień: chmod 700 /home/$USER/.ssh
Plik Authorized_keys wymaga 644 uprawnień: chmod 644 /home/$USER/.ssh/authorized_keys
Upewnij się, że userjest właścicielem plików / folderów, a nie root: chown user:user authorized_keysichown user:user /home/$USER/.ssh
Umieść wygenerowany klucz publiczny (z ssh-keygen) w authorized_keyspliku użytkownika na serwerze
Upewnij się, że katalog domowy użytkownika jest ustawiony zgodnie z oczekiwaniami i że zawiera poprawny .sshfolder, który modyfikowałeś. Jeśli nie, użyj, usermod -d /home/$USER $USERaby rozwiązać problem
Na koniec uruchom ponownie ssh: service ssh restart
Następnie upewnij się, że klient ma pliki klucza publicznego i prywatnego w .sshfolderze użytkownika lokalnego i zaloguj się:ssh user@host.com

— Alex W.
źródło

Jeśli chodzi o twój pierwszy akapit, jestem w stanie ssh z kluczami publicznymi / prywatnymi z użytkownikiem na moim lokalnym systemie Linux (np. abc), Innym niż użytkownik na zdalnym serwerze (np def@123.456.789.). Musiałem tylko upewnić się, że lokalny użytkownik jest właścicielem lokalnych plików .ssh (np. abc:abcNie root:abc) `

— Michael

1

Dzięki za wprowadzenie wszystkich kroków i poleceń dla początkujących, Alex. Twoja jest jedną z najbardziej pomocnych odpowiedzi tutaj.

— Nav

6

+1. „Plik Authorized_keys wymaga uprawnień 644” <= to było kluczowe!

— Le Quoc Viet

Jeśli podajesz tryb .ssh katalogu 700 , to nie ma sensu nadawać r-- grupie i innym, ponieważ tylko ty możesz "przejść" .ssh wtedy (zakładając, że nie ma twardych linków dla tych plików). To samo dotyczy zaakceptowanej odpowiedzi. Domyślnie 755 wystarczy.

— user3125367,

Z mojego doświadczenia wystarczy 400 plików pem.

— AT

37

Upewnij się również, że Twój katalog domowy nie jest zapisywany przez innych użytkowników.

chmod g-w,o-w ~

— Felipe Alvarez
źródło

8

Do Twojej wiadomości, to polecenie zakłada, że jesteś zalogowany jako użytkownik, a nie root

— Alex W

6

Uprawnienia nie powinny mieć z tym nic wspólnego. Twój klucz prywatny jest zaszyfrowany hasłem, więc musisz go wprowadzić, aby klucz prywatny mógł zostać odszyfrowany i użyteczny.

Możesz rozważyć uruchomienie agenta ssh, który może buforować odszyfrowane klucze i dostarczy je do aplikacji, które ich potrzebują.

— cdhowie
źródło

Dzięki za dodatkowe informacje o agencie ssh. Wygląda na to, że Leopard jest wbudowany, więc myślę, że to zrobię. Mam z tym trochę problemów, ale zadam kolejne pytanie.

5

Nie lekceważ uprawnień. Zdecydowanie nadal wchodzą w grę.

— Alex W

@AlexW Oni wchodzą w grę z innymi aspektami ssh, ale nie tymi, o które pytano w pytaniu.

— cdhowie

Jeśli nie masz hasła do kluczy prywatnych (bzdura zautomatyzowanych zdalnych skryptów), to ci nie pomoże. Uprawnienia są tutaj potrzebne.

— nerdoc

„Muszę wpisywać hasło za każdym razem. Jakie powinny być moje uprawnienia do pliku id_rsa, aby nie musieć wpisywać hasła za każdym razem, gdy używam aplikacji, która go używa?

— Craig Hicks,

4

Felipe ma rację - katalog zawierający katalog .ssh nie może być zapisywany przez grupę lub inną grupę. chmod go-w ~Jest to więc kolejna logiczna rzecz do wypróbowania, jeśli po uruchomieniu ssh'ing nadal pojawia się monit o hasło ssh-keygen -t rsa; cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys, zakładając, że nie przypisujesz hasła w komendzie ssh-keygen, a twój katalog .ssh znajduje się w twoim katalogu domowym.

— mikentalk
źródło