Dla niektórych jest to prawdopodobnie głupio proste pytanie :)

Utworzyłem nową instancję linuksa na Amazon EC2 i jako część tego pobrałem plik .pem, aby umożliwić mi SSH.

Kiedy próbowałem ssh z:

ssh -i myfile.pem <public dns>

Mam:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'amazonec2.pem' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: amazonec2.pem
Permission denied (publickey).

Po tym wpisie próbowałem chmod +600 plik pem, ale teraz, gdy ssh, po prostu otrzymuję:

Permission denied (publickey).

Jaki błąd popełniam w szkole? Plik .pem znajduje się w moim folderze domowym (w systemie osx). Jego uprawnienia wyglądają następująco:

-rw-------@   1 mattroberts  staff    1696 19 Nov 11:20 amazonec2.pem

Problemem jest zły mod na pliku.

Łatwo rozwiązany przez wykonanie -

chmod 400 mykey.pem

Zaczerpnięte z instrukcji Amazon -

Twój klucz nie może być publicznie widoczny, aby SSH działał. W razie potrzeby użyj tego polecenia: chmod 400 mykey.pem

400 chroni go, czyniąc go tylko do odczytu i tylko dla właściciela.

Prawdopodobnie używasz niewłaściwej nazwy użytkownika do logowania:

• większość obrazów Ubuntu ma użytkownika ubuntu
• AMI Amazon jest ec2-user
• większość obrazów Debiana ma albo rootalboadmin

Aby się zalogować, musisz dostosować polecenie ssh:

ssh -l USERNAME_HERE -i .ssh/yourkey.pem public-ec2-host

HTH

Wiem, że to bardzo późno do gry ... ale to zawsze działa na mnie:

krok 1

ssh-add ~/.ssh/KEY_PAIR_NAME.pem

krok 2, po prostu ssh :)

ssh user_name@<instance public dns/ip>

na przykład

ssh [email protected]

mam nadzieję, że to komuś pomoże.

Ok, jedyne, co działało dla mnie, to:

1. Zmień uprawnienia klucza

   chmod 400 mykey.pem

2. Zaloguj się przy użyciu ec2-user i poprawnego adresu ec2-99 ... Adres ec2-99 znajduje się na dole konsoli aws, gdy jesteś zalogowany i widzisz swoje wystąpienie na liście

   ssh -i mykey.pem [email protected]

Spójrz na ten artykuł . Nie używasz publicznego DNS, ale formularz

ssh -i your.pem [email protected]

gdzie nazwa jest widoczna na twoim panelu AMI

Zmień uprawnienia do pliku klucza za pomocą:

chmod 400 key-file-name.pem

Zobacz dokumentację AWS dotyczącą łączenia się z instancją:

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#EC2_ConnectToInstance_Linux

W systemie Windows możesz przejść do właściwości pliku pem i przejść do zakładki bezpieczeństwa, a następnie do przycisku przewijania.

usuń dziedziczenie i wszystkie uprawnienia. następnie daj sobie pełną kontrolę. w końcu SSL nie spowoduje ponownego wystąpienia tego samego błędu.

Wiem, że na to pytanie już udzielono odpowiedzi, ale dla tych, którzy wypróbowali je wszystkie, wciąż pojawia się irytujący „Odmowa zezwolenia (publickey)”. Spróbuj uruchomić polecenie za pomocą SUDO. Oczywiście jest to rozwiązanie tymczasowe i należy poprawnie ustawić uprawnienia, ale przynajmniej pozwoli to stwierdzić, że bieżący użytkownik nie korzysta z wymaganych uprawnień (zgodnie z założeniami)

sudo ssh -i amazonec2.pem ec2-xxx-xxx-xxx-xxx.us-west-2.compute.amazonaws.com

Gdy to zrobisz, otrzymasz następujący komunikat:

Please login as the user "ec2-user" rather than the user "root"

Co również jest słabo udokumentowane. W takim przypadku po prostu zrób to:

sudo ssh -i amazonec2.pem ec2-xxx-xxx-xxx-xxx.us-west-2.compute.amazonaws.com -l ec2-user

A otrzymasz chwalebne:

   __|  __|_  )
   _|  (     /   Amazon Linux AMI
  ___|\___|___|

W terminalu Mac robienie „chmod 400 xyz.pem” nie pomogło mi, ciągle powtarzano, że odmawia zgody. Dla użytkowników ubuntu sugerowałbym

1. ssh-add xyz.pem
2. ssh -i xyz.pem [email protected] (zauważ, że użytkownik jest ubuntu)

Najważniejsze wskazówki dotyczące kluczy SSH i uprawnień do plików:

• Katalog .ssh - 0700 (tylko przez właściciela)
• plik klucza prywatnego / .pem - 0400 (tylko do odczytu przez właściciela)

• plik klucza publicznego / .pub - 0600 (tylko do odczytu i zapisu przez właściciela)

  chmod XXXX file/directory

ssh -i /.pem użytkownik @ host-maszyna-IP

Myślę, że dzieje się tak dlatego, że albo wprowadziłeś nieprawidłowe dane uwierzytelniające, albo używasz klucza publicznego, a nie prywatnego, albo twoje uprawnienia do portu są otwarte dla WSZYSTKICH do ssh. To źle dla Amazon.

Alternatywne logowanie przy użyciu PuTTY. Jest dobry, ale potrzebuje kilku kroków.

1. Pobierz plik .pem, który został wygenerowany przy pierwszym utworzeniu instancji EC2.
2. Konwertuj plik .pem .ppk za pomocą PuttyGen, ponieważ PuTTY nie odczytuje .pem.
3. Otwórz PuTTY i wprowadź nazwę hosta, która jest nazwą użytkownika instancji + publiczny DNS (np. [email protected]). Nie nazwa użytkownika konta AWS.
4. Następnie przejdź do Połączenia> SSH> Auth . Następnie dodaj plik .ppk . Kliknij Przeglądaj, gdzie jest napisane „Plik klucza prywatnego do uwierzytelnienia” .
5. Kliknij Otwórz i powinieneś być w stanie natychmiast nawiązać połączenie.

Używam PuTTY 0.66 w systemie Windows.

Oprócz innych odpowiedzi, oto co zrobiłem, aby to zadziałało:

• Skopiuj klucz do folderu .ssh, jeśli nadal nie:

cp key.pem ~/.ssh/key.pem

• Nadaj odpowiednie uprawnienia kluczowi

chmod 400 ~/.ssh/key.pem

• Uruchom ssh-agent (dzięki https://stackoverflow.com/a/17848593 )

eval `ssh-agent -s` ssh-add

• Następnie dodaj klucz

ssh-add ~/.ssh/key.pem

Teraz powinieneś być w stanie ssh EC2 (:

Wykonaj chmod 400 yourkeyfile.pem Jeśli twoją instancją jest Amazon Linux, użyj ssh -i yourkeyfile.pem ec2-user @ ip dla ubuntu ssh -i yourkeyfile.pem ubuntu @ ip dla centos ssh -i yourkeyfile.pem centos @ ip

Przyczyną tego błędu mogą być trzy przyczyny.

1. Używasz niewłaściwego klucza.
2. Twój klucz nie ma odpowiednich uprawnień. Musisz przeskoczyć do 400.
3. Używasz niewłaściwego użytkownika. Obrazy Ubuntu mają użytkownika ubuntu , AMI Amazon jest ec2-użytkownik, a obrazy Debiana mają root lub admin

Problemem było to, że mój plik .pem znajdował się na jednej z partycji NTFS. Przeniosłem go na moją partycję linux (ext4).

Udzielono wymaganych uprawnień, uruchamiając:

chmod 400 my_file.pem

I zadziałało.

Patrząc na opis Twojego wpisu, uważam, że popełniłeś 2 błędy: -

1. Ustaw poprawne uprawnienia dla klucza prywatnego . Poniższe polecenie powinno pomóc Ci ustawić poprawne uprawnienia do plików.

   chmod 0600 mykey.pem

2. Nieprawidłowy użytkownik ec2, którego próbujesz się zalogować .

   Patrząc na dziennik debugowania, myślę, że odrodziłeś instancję Amazon linux. Domyślnym użytkownikiem tego typu instancji jest ec2-user. Jeśli instancja byłaby ubuntu, byłby to domyślny użytkownik ubuntu.

   ssh -i privatekey.pem default_ssh_user@server_ip

Note:
   For an Amazon Linux AMI, the default user name is ec2-user.

   For a Centos AMI, the default user name is centos.

   For a Debian AMI, the default user name is admin or root.

   For a Fedora AMI, the default user name is ec2-user or fedora.

   For a RHEL AMI, the default user name is ec2-user or root.

   For a SUSE AMI, the default user name is ec2-user or root.

   For an Ubuntu AMI, the default user name is ubuntu.

   Otherwise, if ec2-user and root don't work, check with the AMI provider.

źródło: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

Lista kontrolna:

1. Czy używasz odpowiedniego pliku .pem klucza prywatnego?

2. Czy jego uprawnienia są ustawione poprawnie? (Moje interfejsy AMI marki Amazon działają z 644, ale Red Hat musi mieć co najmniej 600 lub 400. Nie wiem o Ubuntu.)

3. Czy używasz prawidłowej nazwy użytkownika w linii ssh? Amazon-branded = „ec2-user”, Red Hat = „root”, Ubuntu = „ubuntu”. Użytkownik może być określony jako „ssh -i pem nazwa użytkownika @ nazwa hosta” LUB ”ssh -l nazwa użytkownika -i pem nazwa hosta”

Po prostu zmień uprawnienia pliku pem na 0600, dopuszczając tylko dozwolonego użytkownika i będzie działał jak urok.

sudo chmod 0600 myfile.pem

A potem spróbuj ssh, to zadziała idealnie.

ssh -i myfile.pem <<ssh_user>>@<<server>>

Domyślnie uprawnienia nie zezwalają na klucz pem. Musisz tylko zmienić uprawnienia:

chmod 400 xyz.pem

a jeśli wystąpienie ubuntu, to połącz się używając:

ssh -i xyz.pem [email protected]

Plik klucza nie powinien być publicznie dostępny, więc użyj uprawnienia 400

chmod 400 keyfile.pem

Jeśli powyższe polecenie pokazuje błąd uprawnień, użyj

sudo chmod 400 keyfile.pem

Teraz ssh na maszynie ec2, jeśli nadal napotykasz problem, użyj ec2-user

ssh -i keyfile.pem [email protected]

.400 chroni go, czyniąc go tylko do odczytu i tylko dla właściciela.
Odpowiedź znajdziesz w przewodniku ASW.

chmod 400 yourPrivateKey.pem

Poniżej przedstawiono proste kroki dla użytkownika systemu Linux, aby połączyć się z serwerem za pomocą pliku .pem:

Krok 1: Przejdź do lokalizacji pliku pem i skopiuj go do domowej lokalizacji .ssh.

cp example.pem ~/.ssh/example.pem

Krok 2: Zmień uprawnienia

chmod 400 ~/.ssh/example.pem

Krok 3: Uruchom następujące polecenie

ssh -i ~/.ssh/example.pem [email protected]

Ponieważ to polecenie jest zbyt długie, możesz utworzyć jego alias, używając następujących poleceń:

 vim ~/.bashrc

Najpierw napisz to samo polecenie w następujący sposób.

alias sshConnect='ssh -i ~/.ssh/example.pem [email protected]'

Teraz uruchom ponownie system i użyj, sshConnectaby połączyć się z serwerem.

To tylko problem z uprawnieniami z kluczem aws pem.

Wystarczy zmienić uprawnienia klucza pem na 400 za pomocą poniższego polecenia.

chmod 400 pemkeyname.pem

Jeśli nie masz uprawnień do zmiany uprawnień do pliku, możesz użyć polecenia sudo jak poniżej.

sudo chmod 400 pemkeyname.pem

Mam nadzieję, że to zadziała dobrze.

Widziałem dwa powody tego problemu

1) klucz dostępu nie ma odpowiednich uprawnień. Klucze pem z domyślnym uprawnieniem nie mogą nawiązywać bezpiecznego połączenia. Musisz tylko zmienić uprawnienia:

chmod 400 xyz.pem

2) Sprawdź także, czy zalogowałeś się przy użyciu odpowiednich poświadczeń użytkownika. W przeciwnym razie użyj sudo podczas łączenia

sudo ssh -i {plik klucza} ec2-user @ {adres IP zdalnego hosta}

Twój klucz nie może być publicznie widoczny, aby SSH działał. W razie potrzeby użyj tego polecenia:

chmod 400 Interview-apps.pem

Connect to your instance using its Public DNS:

ec2-**-***-***-***.us-west-2.compute.amazonaws.com

Przykład:

ssh -i "Interview-apps.pem" ec2-user@ec2-**-***-***-***.us-west-2.compute.amazonaws.com

Zignoruj ​​tę odpowiedź, jeśli jest ona dla ciebie nieistotna, ale z mojego doświadczenia widziałem, że ludzie mają problem, Permission denied (publickey)ponieważ po prostu wkleili swój klucz publiczny (na maszynie docelowej) bez pierwszej litery !

Dzieje się tak, gdy używasz vima do edycji (wklejenia) klucza. Ponieważ vim domyślnie otwiera się w trybie poleceń (nie w trybie wstawiania ), wklejenie klawisza bez przełączania do trybu wstawiania (tj. i) Spowoduje pominięcie pierwszej slitery, np. Zamiast

ssh-rsa <key>

w końcu wklejasz

sh-rsa <key>

Zanim wypróbujesz inne rozwiązania, sprawdź, czy poprawnie wkleiłeś klucz ! to znaczy

cat ~/.ssh/id_rsa.pub

Tylko jeśli jesteś pewien, wykonaj kolejne kroki; próba ssh w trybie pełnym (tj. flaga -v) może wskazywać na rzeczywisty problem:

ssh -v -i <private_key> <name>@<ip> -p <port>

Na marginesie, jak już wspomniano tutaj przez innych, w większości przypadków uruchomienie pustego agenta ssh (program, który trzyma klucze w pamięci) i dodanie klucza powinno rozwiązać problem:

ssh-agent bash
ssh-add <private_key>

Tym, co naprawiło to dla mnie, było przeniesienie pliku .pem do katalogu aplikacji. Powiedzmy, że fooapp to nazwa mojej aplikacji. Umieściłem go bezpośrednio tam.

Czasami może wystąpić błąd w folderze. Nie wiem dlaczego...

Możesz zmienić folder i spróbować ponownie. Na przykład możesz eksperymentować w zwykłych folderach (Pulpit, Pobieranie itp.).

Wypróbowałem tę metodę i zadziałałem

Ten błąd wynika tylko z pozwolenia.

Po prostu daj pozwolenie 400

#chmod 400 pemfilepath