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

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ć.

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ń!

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

chmod 700 ~/.ec2

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.

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

Mam również ten sam problem, ale rozwiązuję go, zmieniając uprawnienia do pliku kluczy na 600.

sudo chmod 600 /path/to/my/key.pem

Link: http://stackabuse.com/how-to-fix-warning-unprotected-private-key-file-on-mac-and-linux/

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”).

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

Zmień uprawnienia do pliku za pomocą komendy chmod

sudo chmod 700 keyfile.pem

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

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.

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) .