Błąd ssh „uprawnienia są zbyt otwarte”

Miałem problem z komputerem Mac, w którym nie mogłem już zapisać żadnego rodzaju pliku na dysku. Musiałem zrestartować lwa OSX i zresetować uprawnienia do plików i acls.

Ale teraz, gdy chcę zatwierdzić repozytorium, otrzymuję następujący błąd od ssh:

Permissions 0777 for '/Users/username/.ssh/id_rsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.

Jakie poziomy uprawnień powinienem przyznać plikowi id_rsa?

Klucze muszą być czytelne tylko dla Ciebie:

chmod 400 ~/.ssh/id_rsa

Jeśli klucze muszą być przez Ciebie zapisywalne:

chmod 600 ~/.ssh/id_rsa

Wydaje się również, że 600 jest w porządku (w rzeczywistości lepsza w większości przypadków, ponieważ nie trzeba później zmieniać uprawnień do plików, aby go edytować).

Odpowiednia część z manpage ( man ssh)

 ~/.ssh/id_rsa
         Contains the private key for authentication.  These files contain sensitive 
         data and should be readable by the user but not
         accessible by others (read/write/execute).  ssh will simply ignore a private 
         key file if it is              
         accessible by others.  It is possible to specify a
         passphrase when generating the key which will be used to encrypt the sensitive 
         part of this file using 3DES.

 ~/.ssh/identity.pub
 ~/.ssh/id_dsa.pub
 ~/.ssh/id_ecdsa.pub
 ~/.ssh/id_rsa.pub
         Contains the public key for authentication.  These files are not sensitive and 
         can (but need not) be readable by anyone.

Korzystając z Cygwin w Windows 8.1, należy uruchomić polecenie:

Użytkownicy chgrp ~ / .ssh / id_rsa

Następnie można zastosować zamieszczone tutaj rozwiązanie, 400 lub 600 jest OK.

chmod 600 ~ / .ssh / id_rsa

Ref: http://vineetgupta.com/blog/cygwin-permissions-bug-on-windows-8

Rozwiązanie niezależne od ustawień regionalnych, które działa w systemie Windows 8.1 to:

chgrp 545 ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa

GID 545 to specjalny identyfikator, który zawsze odnosi się do grupy „Użytkownicy”, nawet jeśli ustawienia narodowe używają innego słowa dla użytkowników.

0600 jest tym, na czym ustawiony jest mój (i działa)

AFAIK wartościami są:

700 dla ukrytego katalogu „.ssh”, w którym znajduje się plik klucza

600 dla pliku klucza „id_rsa”

Mam błąd w moim systemie Windows 10, więc ustawiłem uprawnienia w następujący sposób i działa.

Szczegółowo usuwaj innych użytkowników / grupy, dopóki nie będą mieć tylko „SYSTEM” i „Administratorzy”. Następnie dodaj do niego logowanie do systemu Windows tylko z uprawnieniami do odczytu.

Uwaga: id_rsaplik znajduje się w c:\users\<username>folderze.

Istnieje jeden wyjątek od wymogu uprawnień „0x00” dla klucza. Jeśli klucz jest własnością użytkownika root, a grupa należy do grupy, w której znajdują się użytkownicy, może to być „0440”, a każdy użytkownik w tej grupie może używać klucza.

Wierzę, że to zadziała z dowolnymi uprawnieniami w zestawie „0xx0”, ale nie przetestowałem każdej kombinacji z każdą wersją. Próbowałem 0660 z 5.3p1-84 na CentOS 6, a grupa nie jest podstawową grupą użytkownika, ale grupą dodatkową i działa dobrze.

Zwykle nie robi się tego w przypadku czyjegoś klucza osobistego, ale w przypadku klucza używanego do automatyzacji, w sytuacji, gdy nie chcesz, aby aplikacja mogła zepsuć się z kluczem.

Podobne zasady dotyczą ograniczeń katalogu .ssh.

podaj 400 uprawnień, wykonaj poniższe polecenie

chmod 400 /Users/username/.ssh/id_rsa

W systemie Windows 10 chmod i chgrp cygwina nie były dla mnie wystarczające. Musiałem kliknąć prawym przyciskiem myszy plik -> Właściwości -> Bezpieczeństwo (karta) i usunąć wszystkich użytkowników i grupy oprócz mojego aktywnego użytkownika.

To działało dla mnie (na Macu)

sudo chmod 600 path_to_your_key.pem 

następnie :

ssh -i path_to_your_key user@server_ip

Mam nadzieję, że to pomoże

co dla mnie zadziałało

chgrp Użytkownicy FOLDER

chmod 600 FOLDER

Mam ten sam problem po migracji z innego komputera Mac. I to zablokowało połączenie github przez mój klucz.

Resetuję uprawnienia jak poniżej i teraz działa dobrze.

chmod 700 ~/.ssh     # (drwx------)
cd ~/.ssh            
chmod 644 *.pub      # (-rw-r--r--)
chmod 600 id_rsa     # (-rw-------)

Windows 10 ssh do Ubuntu EC2 błąd „uprawnienia są zbyt otwarte” na AWS

Miałem ten problem przy próbie ssh do instancji Ubuntu EC2 przy użyciu pliku .pem z AWS.

W systemie Windows działało to, gdy umieściłem ten klucz w utworzonym w folderze .ssh

C:\Users\USERNAME\.ssh\private_key

Aby zmienić ustawienia uprawnień w systemie Windows 10:

Ustawienia pliku> Bezpieczeństwo> Zaawansowane

Wyłącz dziedziczenie

Konwertuj odziedziczone uprawnienia na jawne uprawnienia

Usuń wszystkie wpisy uprawnień oprócz Administratorów

Można wtedy bezpiecznie połączyć.

Dla mnie (za pomocą podsystemu Ubuntu dla systemu Windows) komunikat o błędzie zmienił się na:

 Permissions 0555 for 'key.pem' are too open

po użyciu chmod 400. Okazuje się, że powodem było użycie roota jako domyślnego użytkownika.

Zmień to za pomocą cmd:

 ubuntu config --default-user your_username

Ciekawa wiadomość tutaj. Systemy operacyjne są wystarczająco inteligentne, aby odmawiać połączeń zdalnych, jeśli klucz prywatny jest zbyt otwarty. Rozumie ryzyko, że uprawnienia dla id_rsa są szeroko otwarte (odczyt, każdy może edytować).

{Można najpierw zmienić zamek, a następnie otworzyć go za pomocą kluczy, które już posiada}

cd ~/.ssh
chmod 400 id_rsa

Pracując na wielu serwerach (nieprodukcyjnych), większość z nas czuje potrzebę połączenia zdalnego serwera z ssh. Dobrym pomysłem jest posiadanie kodu poziomu aplikacji (może to być Java za pomocą jsch) w celu utworzenia zaufania ssh między serwerami. W ten sposób połączenie będzie bez hasła. Incase, perl jest zainstalowany - można również użyć modułu net ssh.

Ten błąd napotkałem podczas zabawy z Ansible. Zmieniłem uprawnienia klucza prywatnego na 600 , aby rozwiązać ten problem. I zadziałało!

chmod 600 .vagrant/machines/default/virtualbox/private_key

Próbowałem na poziomie 600 uprawnień dla mojego klucza prywatnego i zadziałało to dla mnie. chmod 600 privateKey [dev] $ ssh -i privateKey użytkownik @ ip działał

chmod 755 privateKey [dev] $ ssh -i privateKey użytkownik @ ip dawał następujący problem: Uprawnienia 0755 dla 'privateKey' są zbyt otwarte. Wymagane jest, aby pliki kluczy prywatnych NIE były dostępne dla innych. Ten klucz prywatny zostanie zignorowany. Załaduj klucz „privateKey”: złe uprawnienia

I have got the similar issue when i was trying to login to remote ftp server using public keys..        
To solve this issue initially i have done the following process

    Najpierw znajdź lokalizację kluczy publicznych, ponieważ podczas próby zalogowania się do ftp przy użyciu tego klucza publicznego. najpierw musimy utworzyć klucz i ustawić, aby ustawić te klucze na 600.
            Upewnij się, że jesteś we właściwej lokalizacji.
            krok 1:
            idź do właściwej lokalizacji
            krok 2:
            Po znalezieniu się we właściwej lokalizacji
 Komenda: 
     chmod 600 id_rsa

        This has solved my issue.

Używam VPC na EC2 i otrzymywałem te same komunikaty o błędach. Zauważyłem, że korzystam z publicznego DNS. Zmieniłem to na prywatny DNS i vola !! zadziałało...

dla Win10 musisz przenieść klucz do katalogu domowego użytkownika dla Linux-a, musisz przeskoczyć do 700 jak lub 600 itd.