Permission denied (publickey) when SSH Access to Amazon EC2 instance [closed]

W tym przypadku problem wynika z utraty pary kluczy. O tym:

• nie ma możliwości zmiany pary kluczy na instancji . Musisz utworzyć nową instancję, która używa nowej pary kluczy.
• możesz obejść problem , jeśli twoja instancja jest używana przez aplikację na Elastic Beanstalk .

Możesz wykonać następujące kroki:

1. Dostęp do AWS Management Console
2. Open Elastic Beanstalk Tab
3. Wybierz aplikację z zakładki Wszystkie aplikacje
4. z lewej strony menu wybierz Konfiguracja
5. Kliknij na instancje Gear
6. w formularzu Serwer Sprawdź parę kluczy EC2 i wybierz nową parę kluczy. Być może będziesz musiał odświeżyć listę, aby zobaczyć nową parę kluczy, którą właśnie utworzyłeś.
7. Zapisz
8. Elastic Beanstalk utworzy dla Ciebie nowe instancje powiązane z nowym kluczem para.

Ogólnie rzecz biorąc, pamiętaj, że musisz zezwolić swojej instancji EC2 na akceptację przychodzącego ruchu SSH.

Aby to zrobić, musisz utworzyć specjalną regułę dla grupy zabezpieczeń Twojej instancji EC2. Możesz wykonać następujące kroki.

1. Dostęp do AWS Management Console
2. Otwórz zakładkę EC2
3. z listy instancje wybierz interesującą Cię instancję
4. w zakładce Opis zaznacz nazwę grupa bezpieczeństwa twoja instancja używa.
5. ponownie w zakładce Description Kliknij View rules i sprawdź, czy Twoja grupa zabezpieczeń ma regułę dla przychodzącego ruchu ssh na porcie 22
6. Jeśli nie, w Network & Security menu wybierz Security Group
7. Wybierz grupę zabezpieczeń używaną przez instancję i kliknij zakładkę Inbound
8. po lewej stronie karty Inbound możesz skomponować regułę dla SSH inbound ruch drogowy:
   • Utwórz nową regułę : SSH
   • Źródło: adres IP lub podsieć, z której chcesz uzyskać dostęp do instancji
   • Uwaga: jeśli chcesz przyznać nieograniczony dostęp do swojej instancji możesz określić 0.0.0.0/0, chociaż Amazon nie zaleca tej praktyki
9. Kliknij Dodaj regułę a następnie Zastosuj zmiany
10. Sprawdź, czy jesteś w stanie połączyć się z Twoim instancja przez SSH.

Mam nadzieję, że to pomoże komuś tak, jak pomogło mi.

Tak rozwiązałem problem

ssh -i <key> ec2-user@<ec2 ip>

Rozwiązałem problem po prostu wstawiając sudo Przed

sudo ssh -i mykey.pem myec2.amazonaws.com

Ale właściwym rozwiązaniem jest najpierw zmiana właściciela, a następnie połączenie jako zwykły użytkownik, jak powiedział Janus Troelsen poniżej. W moim przypadku byłoby to:

chown wellington:wellington key.pem

Spróbuj użyć

sudo ssh -i mykey.pem ubuntu@<ec2_ip_public_dns>

Lub

sudo ssh -i mykey.pem ec2-user@<ec2_ip_public_dns>

Inna możliwa przyczyna tego błędu:

Gdy katalog domowy użytkownika jest zapisywalny dla grupy , użytkownik nie może się zalogować.

(Reproduced on Ubuntu instance.)

Dla mikro instancji ubuntu 12.04 lts musiałem ustawić nazwę użytkownika jako opcję

ssh -i pemfile.pem -l ubuntu dns

Musisz wykonać następujące kroki:

1. otwórz klienta ssh lub terminal, jeśli używasz Linuksa.
2. zlokalizuj plik klucza prywatnego i zmień katalog.
   cd <path to your .pem file>
3. wykonaj poniższe polecenia:
   chmod 400 <filename>.pem
ssh -i <filename>.pem ubuntu@<ipaddress.com>

Jeśli ubuntu Użytkownik nie działa, spróbuj użyć ec2-user.

Zmagałem się z tym samym błędem odmowa zgody najwyraźniej z powodu

key_parse_private2: missing begin marker 

W mojej sytuacji przyczyną był Plik konfiguracyjny SSH bieżącego użytkownika (~ / .ssh/config).

Używając następującego:

ssh -i ~/myKey.pem ec2-user@<IP address> -v 'exit'

Wyjściowe wyniki pokazały:

debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config

... wiele linii debugowania wyciętych tutaj ...

debug1: Next authentication method: publickey
debug1: Trying private key: /home/ec2-user/somekey.pem
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

Trzecia linia powyżej jest tam, gdzie problem faktycznie został zidentyfikowany; jednak szukałem w wiadomości debugowania cztery linie od dołu (powyżej) i został wprowadzony w błąd. Tam nie jest problemem z kluczem, ale Przetestowałem go i porównałem inne konfiguracje.

Mój plik konfiguracyjny użytkownika SSH resetuje host za pomocą niezamierzonego ustawienia globalnego, jak pokazano poniżej. Pierwsza linia hosta nie powinna być komentarzem.

$ cat config
StrictHostKeyChecking=no
#Host myAlias
        user ec2-user
        Hostname bitbucket.org
#        IdentityFile ~/.ssh/somekey
#        IdentitiesOnly yes

Host my2ndAlias
        user myOtherUser
        Hostname bitbucket.org
        IdentityFile ~/.ssh/my2ndKey
        IdentitiesOnly yes

Zapomniałem dodać nazwę użytkownika (ubuntu) podczas łączenia mojej instancji Ubuntu. Więc próbowałem tego:

ssh -i /path/my-key-pair.pem my-ec2-instance.amazonaws.com

A prawidłową drogą było

ssh -i /path/my-key-pair.pem [email protected]

Zdarzyło mi się to wiele razy. Używałem Amazon Linux AMI 2013.09.2 i Ubuntu Server 12.04.3 LTS, które są zarówno na wolnym poziomie.

Za każdym razem, gdy uruchamiam instancję, mam odmowę dostępu. Nie zweryfikowałem tego, ale moja teoria jest taka, że serwer nie jest całkowicie skonfigurowany przed próbą ssh do niego. Po kilku próbach z odmową uprawnień czekam kilka minut, a następnie jestem w stanie połączyć się. Jeśli masz ten problem proponuję poczekać 5 minuty i jeszcze raz.

Oto możliwe, frustrujące scenariusze, które powodują ten błąd:

Jeśli tworzysz nową instancję z AMI, którą utworzyłeś z innej instancji (np. instancja xyz), to nowa instancja będzie akceptować tylko ten sam klucz, którego użyto. Jest to całkowicie zrozumiałe, ale robi się mylące, ponieważ podczas procesu tworzenia nowej instancji krok po kroku, zostaniesz poproszony o wybranie lub utworzenie klucza (na ostatnim kroku), który nie będzie działać.

Niezależnie od klucz, który tworzysz lub wybierasz, tylko klucz, którego używałeś na przykład XYZ, będzie akceptowany przez nową instancję.

Ja też przez jakiś czas się z tym zmagałem, dopóki nie znalazłem:

eb ssh

Kiedy używasz tego z katalogu projektu, bingo-bango no muss no fuss, jesteś w

W moim własnym przypadku, zrobiłem co następuje:

chmod 400 <key.pem>

ssh -i <key.pem> ec2-user@ec2_public_dns (for debian)

Początkowo używałem root@ części i dostałem taki monit:

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

Jestem w Windows z WinSCP. Działa świetnie zarówno na Eksploratorze plików, jak i powłoce SSH PuTTY, aby uzyskać dostęp do mojego Linuksa Amazon EC2-VPC. Nie ma nic wspólnego z chmod pem file ponieważ używa myfile.ppk konwertowane przez PuTTYgen z pliku pem.

To samo stało się ze mną, ale wszystko, co się działo, to to, że klucz prywatny zgubił się z pęku kluczy na mojej lokalnej maszynie.

Ssh-add-K

Ponownie dodano klucz, a następnie polecenie SSH do połączenia powróciło do pracy.

Ten problem można rozwiązać logując się do Ubuntu box używając poniższego polecenia:

ssh -i ec2key.pem ubuntu@ec2-public-IP

Dwa razy miałem klucze i wiersz poleceń SSH poprawny (wiem, bo jestem powielanie działającej instancji Ubuntu 14.04), ale po prostu nie był w stanie ssh do nowej instancji, nawet po odczekaniu 5 minut, jak zasugerował Wade Anderson powyżej.

Musiałem zniszczyć i odtworzyć maszynę. Stało się to przy dwóch różnych okazjach. Skoro nie mogę wejść, nie widzę, co jest nie tak.

Więc, jeśli masz ten problem, spróbuj tego.

Musisz sprawdzić te kilka rzeczy:

1. Upewnij się, że twój adres IP jest poprawny
2. Upewnij się, że używasz właściwego klucza
3. Upewnij się, że używasz prawidłowej nazwy użytkownika, Możesz spróbować: 3.1. admin 3.2. ec2-user 3.3. ubuntu

Miałem ten sam problem i rozwiązałem go po zmianie nazwy użytkownika na ubuntu. W dokumentacji AWS został wymieniony do użytkownika ec2-user ale jakoś nie działa dla mnie.

Mój klucz prywatny został ustawiony na permission 400 i spowodowało to odmowę permission ustawienie go na '644' pomogło mi .

Key_load_private_type: Permission denied jest specyficznym błędem, który otrzymywałem

Rozwiązanie: Sudo chmod 644 <key.pem>

Uwaga: ustawione na 644 jest konieczne, nie działało z 400

Kiedy próbujesz robić

ssh -i <.pem path> root@ec2-public-dns

Otrzymasz wiadomość z informacją o używaniu ec2-user.

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

Więc użyj

ssh -i <.pem path> ec2-user@ec2-public-dns

Miałem ten sam problem i to bardzo dziwne. Jeśli uważasz, że robisz wszystko, co dobre, postępuj zgodnie z tym: Czasami pojawia się zamieszanie dotyczące Użytkownika dla instancji EC2!! Czasami dostajesz ec2-user, ubuntu, centos itp. Więc sprawdź swoją nazwę Użytkownika dla machie!!

Login with root user ssh -i yourkey.pem (400 permission) root@<ip> wyświetli błąd i wyświetli dostępną nazwę Użytkownika . następnie zaloguj się z tym użytkownikiem.

To podstawowa rzecz, ale zawsze potwierdź, którego użytkownika próbujesz zalogować. Moja sprawa była tylko odwróceniem Uwagi . Próbowałem użyć root user:

ssh -i ~/keys/<key_name> [email protected]

Ale był inny użytkownik :

ssh -i ~/keys/<key_name> [email protected]

Miałem ten sam błąd, ale inna sytuacja. dla mnie stało się to ni stąd ni zowąd po długim czasie mogłem SSH z powodzeniem do mojego zdalnego komputera. po wielu poszukiwaniach rozwiązaniem mojego problemu były uprawnienia do plików. jest to oczywiście dziwne, ponieważ nie zmieniłem żadnych uprawnień w moim komputerze lub zdalnym należącym do plików/katalogów ssh. więc z dobrego archlinux wiki Oto jest:

Dla lokalnej maszyny zrób to:

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_ecdsa

Dla zdalna maszyna do tego:

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

Potem mój ssh zaczął działać ponownie bez zgody odmownej (publickey).

Kolejny możliwy problem: Błędny identyfikator logowania

Sprawdź "Instrukcje Użytkowania"

Wszystkie dobre sugestie powyżej, ale to, na co wpadłem, to to, że wybrałem wstępnie wykonaną instancję. Po uruchomieniu wystąpienia zapoznaj się z instrukcjami użycia. Niepoprawnie użyłem loginu klucza prywatnego, gdy w instrukcji miałem użyć' bitnami ' (np. Bitnami@domain-i key.pem)

Miałem podobny błąd

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: xxxx.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Mój problem polegał na tym, że instancja nie uruchomiła się poprawnie z powodu błędu w skrypcie run-on-start-up z Step 3: Configure instance detail pod Advanced details:

Co myślałem, że wpisałem:

#include
 https://xxxx/bootstrap.sh


To, co faktycznie zostało wprowadzone, powoduje przerwanie konfiguracji instancji

#include

https://xxxx/bootstrap.sh

Więc klucz publiczny po stronie instancji nie został utworzony

Rozróżnia wielkość liter.

Źle: SSH EC2-user @XXX. XX. XX. XX-i MyEC2KeyPair.pem

Correct: SSH ec2-user @XXX. XX. XX. XX-i MyEC2KeyPair.pem

Byłem w stanie SSH z jednej maszyny, ale nie z drugiej. Okazało się, że używałem niewłaściwego klucza prywatnego.

Sposób, w jaki to rozgryzłem, polegał na pobraniu klucza publicznego z mojego klucza prywatnego, tak:

ssh-keygen -y -f ./myprivatekey.pem

To, co wyszło, nie pasowało do tego, co było w instancji EC2.

Wszystkie wyżej wymienione odpowiedzi są dokładne i powinny działać w większości przypadków. W przypadku, gdy nie tak jak w moim przypadku, po prostu pozbyłem się mojego pliku ~/.ssh/known_hosts Na maszynie, z której próbowałem ssh, i to rozwiązało problem dla mnie. Udało mi się później połączyć.