OSTRZEŻENIE: NIEBEZPIECZNY PRYWATNY KLUCZOWY PLIK! podczas próby SSH do wystąpienia Amazon EC2


190

Pracuję nad skonfigurowaniem Pandy w instancji Amazon EC2. Skonfigurowałem swoje konto i narzędzia ostatniej nocy i nie miałem problemu z użyciem SSH do interakcji z moją osobistą instancją, ale teraz nie mam pozwolenia na instancję Pandy EC2. Pierwsze kroki z Pandą

Otrzymuję następujący błąd:

@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @

Permissions 0644 for '~/.ec2/id_rsa-gsg-keypair' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.

Przeskoczyłem moją parę kluczy do 600, aby dostać się do mojej osobistej instancji zeszłej nocy, i eksperymentowałem długo ustawiając uprawnienia na 0, a nawet generując nowe ciągi kluczy, ale wydaje się, że nic nie działa.

Każda pomoc byłaby świetną pomocą!


Hm, wygląda na to, że jeśli uprawnienia do katalogu nie są ustawione na 777, skrypt ec2-run-instances nie może znaleźć moich plików kluczy. Jestem nowy w SSH, więc mogę coś przeoczyć.


Wystąpienia ec2-run powinny wymagać jedynie podania nazwy klucza, która jest czymś, co żyje po stronie Amazon. Powinieneś używać rzeczywistego klucza prywatnego (tego na dysku), kiedy SSH jest włączony. Jaki błąd pojawia się w wystąpieniach ec2-run?
user27619,

3
okropny tytuł tego pytania.
MikeNereson

2
@MikeNereson: nie krępuj się edytować, dzięki temu poprawiamy tutaj
Stu Thompson

Czy na pewno ustawiłeś go na 0600 (ósemkowy), a nie na 600 (dziesiętny)?
hyde

5
chmod 400 ~/.ssh/id_rsa Odniesienie: stackoverflow.com/a/9270753/2082569
atulkhatri

Odpowiedzi:


210

Przeskoczyłem moją parę kluczy do 600, aby wczoraj dostać się do mojej osobistej instancji,

I tak właśnie powinno być.

Z dokumentacji EC2 mamy: „Jeśli korzystasz z OpenSSH (lub innego w miarę paranoicznego klienta SSH), prawdopodobnie będziesz musiał ustawić uprawnienia do tego pliku, aby był on tylko do odczytu”. Dokumentacja Panda, którą łączysz z linkami do dokumentacji Amazon, ale tak naprawdę nie pokazuje, jak ważne jest to wszystko.

Chodzi o to, że pliki pary kluczy są jak hasła i muszą być chronione. Tak więc klient ssh, którego używasz, wymaga zabezpieczenia tych plików i tylko ich konto może je odczytać.

Ustawienie katalogu na 700 naprawdę powinno wystarczyć, ale 777 nie będzie bolało, dopóki pliki będą mieć 600.

Wszelkie problemy, które masz, są po stronie klienta, więc pamiętaj o dołączeniu informacji o lokalnym systemie operacyjnym do wszelkich dalszych pytań!


3
Właśnie wpadłem dzisiaj w sytuację, w której CHCĘ, aby plik klucza był czytelny dla grupy (używanie ssh nie do osobistego logowania, ale do wykonania skryptu na zdalnym serwerze, dedykowanego użytkownika na tym serwerze w tym celu, klucze autoryzowane są zablokowane, więc tylko wspomniany skrypt zostanie uruchomiony, a wiele osób na serwerze źródłowym powinno mieć dostęp do uruchomienia skryptu). No cóż, wydaje mi się, że prostym obejściem jest umieszczenie kopii w ~ / .ssh / dla wszystkich użytkowników, którzy powinni mieć dostęp - lub wypełnienie kluczy autoryzowanych wszystkimi kluczami osobistymi.
tobixen

@tobixen: Nadchodzą dwa lata, ale ... „poprawnym” obejściem byłoby umieszczenie klucza w dedykowanym użytkowniku i umożliwienie użytkownikom grupy sudo dostępu do uruchamiania tego polecenia jako dedykowanego użytkownika.
Stu Thompson,

@StuThompson link do dokumentacji EC2 wydaje się być martwy. Czy możesz zaktualizować?
Aniket Thakur,

Nie widzę, co powinienem zrobić, aby zadziałało w twojej odpowiedzi, proszę podać odpowiedź :)
Pratik,

@Pratik ustawienie 600 dla obu plików kluczy i 777 dla katalogu powinno działać.
Jamo

55

Upewnij się, że katalog zawierający pliki kluczy prywatnych jest ustawiony na 700

chmod 700 ~/.ec2

Czy jest jakiś szczególny powód, dla którego chcesz mieć uprawnienia do wykonywania pliku?
Zoltán

1
@ Zoltán to katalog, a nie plik.
avmohan

Właśnie użyłem tego w pliku .pem i zadziałało to dla mnie.
CGTheLegend

30

Aby to naprawić: 1) musisz przywrócić uprawnienia do wartości domyślnych:

sudo chmod 600 ~/.ssh/id_rsa sudo chmod 600 ~/.ssh/id_rsa.pub

Jeśli pojawia się kolejny błąd: Czy na pewno chcesz kontynuować połączenie (tak / nie)? tak Nie udało się dodać hosta do listy znanych hostów (/home/geek/.ssh/known_hosts).

2) Oznacza to, że uprawnienia do tego pliku są również ustawione niepoprawnie i można to zmienić za pomocą:

sudo chmod 644 ~/.ssh/known_hosts

3) Na koniec może być konieczne dostosowanie uprawnień do katalogu:

sudo chmod 755 ~/.ssh

To powinno przywrócić Ci działanie.


17

Plik klucza prywatnego powinien być chroniony. W moim przypadku od dłuższego czasu korzystam z uwierzytelniania klucza publicznego i ustawiłem uprawnienia jako 600 (rw- --- ---) dla klucza prywatnego i 644 (rw- r-- r--) oraz dla do folderu .ssh w folderze domowym będziesz mieć 700 uprawnień (rwx --- ---). Aby to ustawić, przejdź do folderu domowego użytkownika i uruchom następujące polecenie


Ustaw uprawnienia 700 dla folderu .ssh

chmod 700 .ssh


Ustaw uprawnienie 600 dla pliku klucza prywatnego

chmod 600 .ssh/id_rsa


Ustaw 644 uprawnienia do pliku klucza publicznego

chmod 644 .ssh/id_rsa.pub


2

Trzymaj swój klucz prywatny, klucz publiczny, znane_hosty w tym samym katalogu i spróbuj zalogować się jak poniżej:

ssh -I(small i) "hi.pem" ec2-user@ec2-**-***-**-***.us-west-2.compute.amazonaws.com
  • Sam katalog w sensie cd /Users/prince/Desktop. Teraz wpisz lspolecenie i powinieneś zobaczyć **.pem **.ppk known_hosts

Uwaga: musisz spróbować zalogować się z tego samego katalogu, inaczej dostaniesz błąd odmowy uprawnień, ponieważ nie może on znaleźć pliku .pem z bieżącego katalogu.


Jeśli chcesz mieć możliwość SSH z dowolnego katalogu, możesz dodać do ~/.ssh/configpliku następujące informacje ...

Host your.server
HostName ec2-user@ec2-**-***-**-***.us-west-2.compute.amazonaws.com
User ec2-user
IdentityFile ~/.ec2/id_rsa-gsg-keypair
IdentitiesOnly yes

Teraz możesz połączyć się z serwerem SSH niezależnie od tego, gdzie znajduje się katalog, po prostu wpisując ssh your.server(lub dowolną nazwę umieszczoną po „Host”).


1

W systemie Windows spróbuj użyć git bash i tam użyj poleceń systemu Linux. Łatwe podejście

chmod 400 *****.pem

ssh -i "******.pem" ubuntu@ec2-11-111-111-111.us-east-2.compute.amazonaws.com

Jeśli używasz WSL, upewnij się, że skopiowałeś plik pem do folderu Linux, ponieważ chmod nie zadziała w katalogu / mnt dirs.
Paulo Merson


0

Zastanawiam się nad czymś innym. Jeśli próbujesz zalogować się przy użyciu innej nazwy użytkownika, która nie istnieje, to otrzymujesz wiadomość.

Zakładam więc, że próbujesz ssh z użytkownikiem ec2, ale ostatnio pamiętam, że większość AMI centos używa na przykład użytkownika centos zamiast użytkownika ec2

więc jeśli tak, ssh -i file.pem centos@public_IPproszę powiedz mi, że próbujesz ssh z właściwą nazwą użytkownika, w przeciwnym razie może to być silny powód, dla którego widzisz taki komunikat o błędzie, nawet z odpowiednimi uprawnieniami na ~ / .ssh / id_rsa lub file.pem


0

Uwaga dla każdego, kto się na to natknie:

Jeśli próbujesz SSH za pomocą klucza, który został Ci udostępniony, na przykład:

ssh -i /path/to/keyfile.pem user@some-host

Gdzie keyfile.pemklucz prywatny / publiczny jest Ci udostępniany i używasz go do łączenia się, upewnij się, że zapisałeś go w ~/.ssh/i chmod 777.

Próba użycia pliku, gdy został zapisany w innym miejscu na moim komputerze, dawała błąd OP. Nie jestem pewien, czy jest to bezpośrednio powiązane.


0

Rozwiązaniem jest, aby był czytelny tylko dla właściciela pliku, tzn. Ostatnie dwie cyfry reprezentacji trybu ósemkowego powinny wynosić zero (np. Tryb 0400).

OpenSSH sprawdza to w authfile.cfunkcji o nazwie sshkey_perm_ok:

/*
 * if a key owned by the user is accessed, then we check the
 * permissions of the file. if the key owned by a different user,
 * then we don't care.
 */
if ((st.st_uid == getuid()) && (st.st_mode & 077) != 0) {
    error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
    error("@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @");
    error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
    error("Permissions 0%3.3o for '%s' are too open.",
        (u_int)st.st_mode & 0777, filename);
    error("It is required that your private key files are NOT accessible by others.");
    error("This private key will be ignored.");
    return SSH_ERR_KEY_BAD_PERMISSIONS;
}

Zobacz pierwszy wiersz po komentarzu: robi „bitowe i” w stosunku do trybu pliku, zaznaczając wszystkie bity w ostatnich dwóch cyfrach ósemkowych (ponieważ 07jest ósemkowe 0b111, gdzie każdy bit oznacza odpowiednio r / w / x) .

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.