Odmowa zezwolenia (publickey), gdy dostęp SSH do instancji Amazon EC2 [zamknięty]


355

Chcę użyć mojej instancji Amazon ec2, ale napotkałem następujący błąd:

Permission denied (publickey).

Utworzyłem moją parę kluczy i pobrałem plik .pem .

Dany:

chmod  600 pem file.

Następnie to polecenie

ssh -i /home/kashif/serverkey.pem  ubuntu@ec2-54-227-242-179.compute-1.amazonaws.com

Ale ten błąd:

Permission denied (publickey)

Również, w jaki sposób można połączyć z FileZilla, aby przesłać pliki / download?


1
dotyczące drugiego pytania, połącz się z filezilla, aby przesyłać / pobierać pliki, zapoznaj się z instrukcjami krok po kroku - y2u.be/e9BDvg42-JI
Yasitha Chinthaka

2
czy na pewno nie użyłeś „sudo chmod 600 pem file”, spowodowałoby to ten błąd i oznaczałoby, że musisz użyć sudo przed ssh
felbus

W przypadku niektórych systemów operacyjnych Debian nazwa użytkownika to admin. Przynajmniej dla wersji 6.5 i 7.0.
Deweloper

2
Jeśli Twoja nazwa użytkownika to ec2-user, upewnij się, że nie używasz ec2_user:)
grisaitis

2
Upewnij się, że użytkownik, z którym próbujesz się połączyć, ma klucz wymieniony w swoim $HOME/.ssh/authorized_keys pliku.
ILMostro_7,

Odpowiedzi:


589

Ten komunikat o błędzie oznacza, że ​​nie udało się uwierzytelnić.

Są to typowe przyczyny, które mogą powodować:

  1. Próba połączenia z niewłaściwym kluczem. Czy na pewno to wystąpienie używa tej pary kluczy?
  2. Próba połączenia z niewłaściwą nazwą użytkownika. ubuntuto nazwa użytkownika dla dystrybucji Ubuntu opartej AWS, ale na niektórych innych jest to ec2-user(lub adminw niektórych Debians, zgodnie z odpowiedzią Bogdan Kulbida za) (może być również root, fedorapatrz poniżej)
  3. Próba podłączenia niewłaściwego hosta. Czy to właściwy host, na który próbujesz się zalogować?

Zauważ, że 1.stanie się to również, jeśli popsułeś /home/<username>/.ssh/authorized_keysplik w instancji EC2.

Informacje o 2.nazwie użytkownika, której należy użyć, często brakuje w opisie obrazu AMI. Ale niektóre można znaleźć w dokumentacji AWS EC2, punktor 4.: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

Użyj polecenia ssh, aby połączyć się z instancją. Podasz plik klucza prywatnego (.pem) i nazwę użytkownika @ nazwa_domeny publicznej. W systemie Amazon Linux nazwa użytkownika to ec2-user. W przypadku RHEL5 nazwa użytkownika to root lub ec2-user . W systemie Ubuntu nazwa użytkownika to ubuntu . W przypadku Fedory nazwa użytkownika to fedora lub użytkownik ec2 . W przypadku SUSE Linux nazwą użytkownika jest root . W przeciwnym razie, jeśli użytkownik ec2 i użytkownik root nie działają, skontaktuj się z dostawcą AMI.

Na koniec pamiętaj, że istnieje wiele innych powodów niepowodzenia uwierzytelnienia. SSH jest zwykle bardzo wyraźne, co poszło nie tak, jeśli chcesz dodać -vopcję do polecenia SSH i przeczytać wynik, jak wyjaśniono w wielu innych odpowiedziach na to pytanie.


2
Nie sądzę, że interfejs oferuje dodanie klucza do działającej instancji, więc będziesz musiał uruchomić nowy, jeśli zgubiłeś klucz do działającej instancji.
Thibault D.

81
# 2 naprawiłem mój problem, dzięki!
rckehoe

4
Ta odpowiedź rozwiązała dla mnie. Domyślna nazwa użytkownika dla tego wystąpienia to „ubuntu”, a nie użytkownik ec2, jak napisano w instrukcji AWS. Spróbuj użyć „ec2-user@_your_EC2_IP.amazonaws.com
emf

7
Jeśli chodzi o nr 1, zły klucz, dodanie -v (verbose) do wiersza poleceń ssh pokazało mi, które klucze próbował, i to uświadomiło mi, że nie próbowałem wygenerować klucza, ponieważ nazwałem go innym niż id_rsa lub id_dsa.
KC Baltz

3
„ubuntu to nazwa użytkownika dla dystrybucji AWS opartej na ubuntu”. To mnie dostało. Był używany do ec2-user, po prostu zakładałem, że zawsze była to nazwa użytkownika.
Nate Reed

48

W takim przypadku problem wynika z utraconej pary kluczy. O tym:

  • Nie można zmienić pary kluczy w instancji . Musisz utworzyć nową instancję, która używa nowej pary kluczy.
  • Możesz obejść ten problem, jeśli Twoja instancja jest używana przez aplikację na Elastic Beanstalk .

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

  1. Dostęp do konsoli zarządzania AWS
  2. Otwórz zakładkę elastycznej fasoli
  3. Wybierz aplikację na karcie Wszystkie aplikacje
  4. Z menu po lewej stronie ù wybierz Konfiguracja
  5. Kliknij opcję Instances Gear
  6. W formularzu serwera sprawdź dane wejściowe pary kluczy EC2 i wybierz nową parę kluczy. Może być konieczne odświeżenie listy, aby zobaczyć nową parę kluczy, którą właśnie utworzyłeś.
  7. Zapisać
  8. Elastic Beanstalk stworzy dla Ciebie nowe instancje związane z nową parą kluczy.

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

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

  1. Dostęp do konsoli zarządzania AWS
  2. Otwórz kartę EC2
  3. Z listy Instancje wybierz instancję, która Cię interesuje
  4. Na karcie Opis sprawdź nazwę grupy zabezpieczeń, z której korzysta Twoja instancja.
  5. Ponownie w karcie Opis kliknij Wyświetl reguły i sprawdź, czy Twoja grupa zabezpieczeń ma regułę dla przychodzącego ruchu ssh na porcie 22
  6. Jeśli nie, w menu Network & Security menù wybierz Security Group
  7. Wybierz grupę zabezpieczeń używaną przez instancję i kliknij kartę Przychodzące
  8. Po lewej stronie karty Przychodzące możesz utworzyć regułę dla ruchu przychodzącego SSH:
    • 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 instancji, możesz podać wartość 0.0.0.0/0 , chociaż Amazon nie zaleca tej praktyki
  9. Kliknij Dodaj regułę, a następnie Zastosuj zmiany
  10. Sprawdź, czy możesz teraz połączyć się z instancją przez SSH.

Mam nadzieję, że to może komuś pomóc, ponieważ pomogło mi.


1
Druga część twojej odpowiedzi jest błędna. Nie można uzyskać „Odmowa dostępu (publickey)”. jeśli nie skonfigurowałeś poprawnie ustawień zapory (Grupy bezpieczeństwa). „Odmowa zezwolenia (publickey).” jest komunikatem o błędzie z SSH i dowodzi, że konfiguracja grup bezpieczeństwa jest prawidłowa. Zamiast tego pojawi się komunikat „ssh: connect to host xxxx port 22: odmowa połączenia”
Thibault D.

Krótka historia: Komunikat o błędzie informuje, że ten problem nie ma nic wspólnego z konfiguracją grup zabezpieczeń.
Thibault D.

Masz rację. Druga część dotyczy innego rodzaju problemu. Naprawiłem post.
Matteo Ceserani

Jeśli zgubiłeś klucz, myślę, że jednym ze sposobów rozwiązania tego problemu byłoby zrobienie migawki instancji, a następnie uruchomienie nowego z nowym kluczem. W takim przypadku Amazon dołącza nowy klucz publiczny w .ssh / Author_keys, więc pamiętaj, aby usunąć stary. (i uważaj, aby nie usunąć nowego, bo wrócisz do pierwszego wydania)
Thibault D.

43

W ten sposób rozwiązałem problem

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

1
Wydawało mi się, że kluczem jest tutaj adres DNS hosta vs. IP. ec2-user @ <ip> pracował dla mnie.
Zack

1
Rozwiązanie również.
Tpojka,

26

Rozwiązałem problem sudoprzed chwilą

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 jak zwykły użytkownik, jak powiedział Janus Troelsen. W moim przypadku byłoby to:

chown wellington:wellington key.pem

Pracowałem dla mnie (musiałem jednak zaktualizować niektóre pakiety)!
user1429980

4
właściwym rozwiązaniem jest najpierw zmiana właściciela, a następnie połączenie jako zwykły użytkownik. użyć sudo chown wellington:wellington key.pem.
Janus Troelsen

działa, w twoim przypadku, ponieważ próbujesz zalogować się do tej maszyny wirtualnej w Amazon, która obsługuje użytkownika root
Taimoor Changaiz

Zrobiłem whoami, a następnie sudo chown nazwa_użytkownika_given_by_whoami xxxx.pem
Chirag Purohit

23

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>

1
To mi pomogło. Dzięki za wskazówkę! : D
jehzlau

22

Inna możliwa przyczyna tego błędu:

Gdy katalog domowy użytkownika można zapisać w grupie , użytkownik nie może się zalogować.

(Reprodukcja na instancji Ubuntu.)


1
+1 Chciałbym to przeczytać 4 godziny temu !!! Rozwiązałem problem polegający na tym, że rsync -a nadpisywał uprawnienia do mojego folderu użytkownika ec2.
Michael Hobbs,

Po przejściu do katalogu domowego nie mogłem się zalogować.
Robert Moon

Jak więc zalogować się na maszynie, której to dotyczy, i nie możesz się w ogóle zalogować?
PKHunter

Napraw uprawnienia do katalogu / home też działa dla mnie, dzięki! @AlexPetralia, twój link jest zepsuty = / ale ma post na forum aws mówi o tym: forums.aws.amazon.com/message.jspa?messageID=334402
Liko

Czy ktoś taki jak Alex Petralia lub @Michael Hobbs może opublikować (lub przekształcić) rozwiązanie tego problemu?
Jakub Langr,

7

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

ssh -i pemfile.pem -l ubuntu dns

zadziałało to dla mnie, jestem zaskoczony, że nie jest częścią dokumentacji aws, aby dyskutować o użytkownikach, które mogą być wymagane.
Ben

7

Musisz wykonać następujące kroki:

  1. Otwórz klienta ssh lub terminal, jeśli używasz Linuksa.
  2. Znajdź 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 ubuntuużytkownik nie działa, spróbuj z ec2-user.


5

Walczyłem z tym samym pozwoleniem, któremu odmówiono błędu, prawdopodobnie z powodu

key_parse_private2: missing begin marker 

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

Wykorzystując następujące:

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

Wyjściowe wyjście pokazało:

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

... wycięto tutaj wiele linii debugowania ...

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 to miejsce, w którym zidentyfikowano problem; Jednak szukałem komunikatu debugowania cztery linie od dołu (powyżej) i zostałem wprowadzony w błąd. Z kluczem nie ma problemu, ale przetestowałem go i porównałem inne konfiguracje.

Mój plik konfiguracyjny ssh użytkownika zresetował 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

Mam nadzieję, że ktoś inny uzna to za pomocne.


4

Zapomniałem dodać nazwy 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

i był to właściwy sposób

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

Błąd dla początkujących. Jeśli zapomnisz dodać nazwę użytkownika, użyje ona nazwy użytkownika, z którego jesteś zalogowany na komputerze lokalnym.
Thibault D.

3

Zdarzyło mi się to wiele razy. Korzystałem z Amazon Linux AMI 2013.09.2 i Ubuntu Server 12.04.3 LTS, które są na wolnej warstwie.

Za każdym razem, gdy uruchamiam instancję, nie mam uprawnień, aby się pojawiać. Nie zweryfikowałem tego, ale moja teoria jest taka, że ​​serwer nie jest całkowicie skonfigurowany, zanim spróbuję na nim ssh. Po kilku próbach z odmową dostępu czekam kilka minut, a potem mogę się połączyć. Jeśli masz ten problem, sugeruję odczekać pięć minut i spróbować ponownie.


Czekałem 5 minut. i zadziałało. też jestem na darmowym poziomie. dzięki
Emeka Mbah

2

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

Jeśli spożywasz nową instancję z utworzonego przez siebie AMI innej instancji (np. Instancja xyz), nowa instancja zaakceptuje tylko ten sam klucz, którego użyła instancja A. Jest to całkowicie zrozumiałe, ale staje się mylące, ponieważ podczas procesu tworzenia nowej instancji krok po kroku użytkownik jest proszony o wybranie lub utworzenie klucza (na ostatnim etapie), który nie będzie działał.

Niezależnie od klucza, który utworzysz lub wybierzesz, tylko nowy klucz użyty na przykład XYZ zostanie zaakceptowany przez nową instancję.


Wow, nigdy o tym nie myślałem. Użycie starego klucza rozwiązało problem. Dzięki.
tolgamorf

Zazwyczaj dołącza nowy klucz publiczny do pliku autoryzowanego_klucza, dzięki czemu oba są użyteczne. Minęło trochę czasu, odkąd testowałem, ale tego się spodziewałbym.
Thibault D.

2

Zmagałem się z tym również przez chwilę, aż znalazłem:

eb ssh

Gdy użyjesz tego z katalogu projektu, bingo-bango nie będzie musiało być bezproblemowe


2

W moim przypadku wykonałem następujące czynności:

chmod 400 <key.pem>

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

Początkowo używałem root@części i otrzymałem następujący monit:

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

2

Jestem w systemie Windows z WinSCP . Działa świetnie zarówno w Eksploratorze plików, jak i PuTTY SSH Shell, aby uzyskać dostęp do mojego Amazon EC2-VPC Linux. Nie ma nic wspólnego z chmod pem filejak używa go myfile.ppk przekształcone przez PuTTYgen z pliku pem .


2

to samo mi się przydarzyło, ale wszystko, co się działo, to zgubienie klucza prywatnego z pęku kluczy na mojej lokalnej maszynie.

ssh-add -K

ponownie dodał klucz, a następnie polecenie ssh, aby się połączyć, powróciło do pracy.


Zdarza się to za każdym razem po ponownym uruchomieniu i muszę ponownie uruchomić powyższe polecenie w celu obejścia tego problemu.
silentsudo

1
sam tego nie zweryfikowałem, ale zweryfikowana odpowiedź tutaj może pomóc: apple.stackexchange.com/questions/254468/...
eiTan LaVi

1

Ten problem można rozwiązać, logując się w polu Ubuntu za pomocą poniższego polecenia:

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

1
Proszę podać szczegóły.
Syeda Zunaira,

1

Dwukrotnie miałem poprawne klucze i wiersz poleceń ssh (wiem, ponieważ duplikuję działającą instancję Ubuntu 14.04), ale po prostu nie byłem w stanie ssh w nowej instancji, nawet po odczekaniu 5 minut, jak sugerował Wade Anderson powyżej.

Musiałem zniszczyć i odtworzyć maszynę. Stało się to dwa razy. Ponieważ początkowo nie mogę się dostać, nie widzę, co jest nie tak.

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


1

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 poprawnej nazwy użytkownika, możesz spróbować: 3.1. admin 3.2. użytkownik ec2 3.3. ubuntu

Miałem ten sam problem i rozwiązałem go po zmianie nazwy użytkownika na ubuntu. W dokumentacji AWS wspomniano o użytkowniku ec2-user, ale jakoś mi nie działa.


1

Mój klucz prywatny został ustawiony na pozwolenie 400i spowodowało, że odmowa zezwolenia na ustawienie go na „644” pomogła mi.

key_load_private_type: Odmowa dostępu to konkretny błąd, który otrzymywałem

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

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


1

Kiedy spróbujesz to zrobić

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

Otrzymasz komunikat z zaleceniem korzystania z 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


1

Miałem ten sam problem i to bardzo dziwne. Jeśli uważasz, że robisz wszystko dobrze, postępuj zgodnie z tym: Czasem zdarza 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 !!

Zaloguj się z użytkownikiem root ssh -i yourkey.pem (400 permission) root@<ip> Wyrzuci błąd i poda dostępną nazwę użytkownika . następnie zaloguj się z tym użytkownikiem.


1

Jest to podstawowa rzecz, ale zawsze potwierdzaj, którego użytkownika próbujesz zalogować. Im moja sprawa była tylko rozrywką . Próbowałem użyć użytkownika root :

ssh -i ~/keys/<key_name> root@111.111.111.111

Ale był inny użytkownik :

ssh -i ~/keys/<key_name> dedeco@111.111.111.111

1

miałem ten sam błąd, ale inną sytuację. dla mnie stało się to nieoczekiwanie po długim czasie, kiedy mogłem pomyślnie ssh na moim zdalnym komputerze. po wielu poszukiwaniach rozwiązania mojego problemu były uprawnienia do plików. jest to oczywiście dziwne, ponieważ nie zmieniłem żadnych uprawnień na moim komputerze ani na komputerze zdalnym należącym do plików / katalogów ssh. więc z dobrej wiki archlinux tutaj:

W przypadku komputera lokalnego wykonaj następujące czynności:

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

W przypadku zdalnego komputera wykonaj następujące czynności:

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

potem mój ssh zaczął znowu działać bez zezwolenia odmowy (publickey).


0

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

Sprawdź „Instrukcje użytkowania”

Wszystkie dobre sugestie powyżej, ale natknąłem się na to, że wybrałem wstępnie przygotowaną instancję. Po uruchomieniu instancji zapoznaj się z instrukcjami użytkowania. Niepoprawnie użyłem identyfikatora logowania klucza prywatnego, gdy w instrukcji miałem użyć „bitnami” (np. Bitnami @ domain -i key.pem)


0

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ę prawidłowo z powodu błędu w skrypcie uruchamiania przy uruchamianiu od Step 3: Configure instance detaildołuAdvanced details:

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

#include
 https://xxxx/bootstrap.sh


To, co faktycznie wprowadzono, psuje konfigurację instancji

#include

https://xxxx/bootstrap.sh

Tak więc klucz publiczny po stronie instancji nie został utworzony


0

Rozróżnia małe i wielkie litery.

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

Prawidłowo: SSH ec2-user @ XXX.XX.XX.XX -i MyEC2KeyPair.pem


-1

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

Zrozumiałem to, pobierając klucz publiczny z mojego klucza prywatnego, jak poniżej:

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

To, co wyszło, nie pasowało do tego, co było w ~/.ssh/authorized_keysinstancji EC2.


-1

Wszystkie wyżej ocenione odpowiedzi są prawidłowe i powinny działać w większości przypadków. W przypadku, gdy nie jest tak, jak w moim przypadku, po prostu pozbyłem się mojego ~/.ssh/known_hostspliku na maszynie, z której próbowałem ssh i to rozwiązało problem. Później mogłem się połączyć.


Chociaż usunięcie known_hostsmoże rozwiązać problem podczas łączenia się z serwerem, który zmienił swój klucz hosta (chociaż i tak jest to złe podejście), jestem prawie pewien, że nie może rozwiązać błędu „Odmowa zezwolenia (publickey)” .
Martin Prikryl,
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.