Permisiune refuzată (publickey) la accesul SSH la instanța Amazon EC2 [închis] (Programare, Amazon Web Services, Ssh, Amazon Ec2)

Kashiftufail a intrebat.

Vreau să folosesc instanța mea Amazon ec2, dar m-am confruntat cu următoarea eroare:

Permission denied (publickey).

Mi-am creat perechea de chei și am descărcat .pem fișier.

Dat:

chmod  600 pem file.

Apoi, această comandă

ssh -i /home/kashif/serverkey.pem  [email protected]

Dar am această eroare:

Permission denied (publickey)

De asemenea, cum mă pot conecta cu filezilla pentru a încărca/descărca fișiere?

Comentarii

  • în ceea ce privește a doua întrebare, conectați-vă cu filezilla pentru a încărca/descărca fișiere, consultați acest lucru pentru instrucțiuni pas cu pas – y2u.be/e9BDvg42-JI –  > Por Yasitha Waduge.
  • sunteți sigur că nu ați folosit „sudo chmod 600 pem file” acest lucru ar cauza această eroare și ar însemna că ar trebui să folosiți sudo înainte de ssh –  > Por felbus.
  • De asemenea, pentru unele sisteme de operare Debian, numele de utilizator este admin. Cel puțin pentru versiunile 6.5 și 7.0. –  > Por Dezvoltator.
  • Dacă numele de utilizator este ec2-user, , asigurați-vă că nu folosiți ec2_user 🙂 –  > Por grisaitis.
  • Asigurați-vă că utilizator în calitate de care încercați să vă conectați are cheia listată în lui $HOME/.ssh/authorized_keys fișier. –  > Por ILMostro_7.
29 răspunsuri
Thibault D.

Acest mesaj de eroare înseamnă că nu ați reușit să vă autentificați.

Acestea sunt motive comune care pot cauza acest lucru:

  1. Încercarea de a vă conecta cu o cheie greșită. Sunteți sigur că această instanță utilizează această pereche de chei?
  2. Încercarea de a vă conecta cu un nume de utilizator greșit. ubuntu este numele de utilizator pentru distribuția AWS bazată pe Ubuntu, dar pe altele este ec2-user (sau admin pe unele Debians, conform răspunsului lui Bogdan Kulbida)(poate fi și root, , fedora, , vezi mai jos)
  3. Încearcă să se conecteze la o gazdă greșită. Este gazda corectă la care încercați să vă conectați?

Rețineți că 1. se va întâmpla, de asemenea, dacă ați încurcat /home/<username>/.ssh/authorized_keys de pe instanța EC2.

Despre 2., , informațiile despre numele de utilizator pe care trebuie să îl utilizați lipsesc adesea din descrierea imaginii AMI. Dar puteți găsi unele în documentația AWS EC2, punctul de puncte 4. : http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

Utilizați comanda ssh pentru a vă conecta la instanță. Veți specifica fișierul cu cheia privată (.pem) și [email protected]_dns_name. Pentru Amazon Linux, numele de utilizator este ec2-user. Pentru RHEL5, numele de utilizator este fie root, fie ec2-user. Pentru Ubuntu, numele de utilizator este ubuntu. Pentru Fedora, numele de utilizator este fie fedora fie ec2-user. Pentru SUSE Linux, numele de utilizator este root. În caz contrar, dacă ec2-user și root nu funcționează, verificați cu furnizorul AMI.

În cele din urmă, , fiți conștienți de faptul că există multe alte motive pentru care autentificarea ar putea eșua. SSH este, de obicei, destul de explicit cu privire la ceea ce nu a mers bine, dacă aveți grijă să adăugați -v la comanda SSH și citiți rezultatul, așa cum se explică în multe alte răspunsuri la această întrebare.

Comentarii

  • Nu cred că interfața vă oferă posibilitatea de a adăuga o cheie la o instanță în curs de execuție, astfel încât va trebui să începeți una nouă dacă ați pierdut cheia instanței în curs de execuție. –  > Por Thibault D..
  • 81

  • #2 mi-a rezolvat problema, mulțumesc! –  > Por rckehoe.
  • Acest răspuns a rezolvat-o pentru mine. Numele de utilizator implicit pentru această instanță era „ubuntu”, nu ec2-user, așa cum se spune în manualul AWS. Încercați să utilizați „[email protected]_your_EC2_IP.amazonaws.com –  > Por emf.
  • În ceea ce privește #1, cheia greșită, adăugând -v (verbose) la linia de comandă ssh mi-a arătat ce chei încerca și asta m-a făcut să îmi dau seama că nu încerca cheia pe care o generasem pentru că o numisem altfel decât id_rsa sau id_dsa. –  > Por KC Baltz.
  • „ubuntu este numele de utilizator pentru distribuția AWS bazată pe ubuntu,” Acesta este ceea ce m-a prins. Eram obișnuit cu ec2-user, pur și simplu am presupus că acesta era întotdeauna numele de utilizator. –  > Por Nate Reed.
Matteo Ceserani

În acest caz, problema apare din cauza pierderii perechii de chei. În legătură cu aceasta:

  • Nu există nicio modalitate de a schimba perechea de chei pe o instanță.. Trebuie să creați o nouă instanță care să folosească o nouă pereche de chei.
  • Puteți rezolva problema dacă instanța dvs. este utilizată de o aplicație pe Elastic Beanstalk.

Puteți urma acești pași:

  1. Accesați Consola de administrare AWS
  2. Deschideți Elastic Beanstalk Fila
  3. Selectați aplicația dvs. din Toate aplicațiile Fila
  4. Din meniul din partea stângă selectați Configurație
  5. Faceți clic pe Instanțe Angrenaj
  6. În Server Formular bifați caseta EC2 Key Pair (Pereche de chei EC2) și selectați noua pereche de chei. Este posibil să trebuiască să reîmprospătați lista pentru a vedea noua pereche de chei pe care tocmai ați creat-o.
  7. Salvați
  8. Elastic Beanstalk va crea pentru dvs. noi instanțe asociate cu noua pereche de chei.

În general, amintiți-vă că trebuie să permiteți instanței EC2 să accepte traficul SSH de intrare.

Pentru a face acest lucru, trebuie să creați o regulă specifică pentru Grupul de securitate al instanței dvs. EC2. puteți urma acești pași.

  1. Acces la Consola de administrare AWS
  2. Deschideți fila EC2
  3. De la Instanțe selectați instanța care vă interesează
  4. În fereastra Descriere verificați numele instanței Grupul de securitate pe care îl utilizează instanța dvs.
  5. Din nou în Descriere faceți clic pe Vizualizare reguli și verificați dacă Grupul de securitate are o regulă pentru traficul ssh de intrare pe portul 22
  6. Dacă nu, în Network & Security meniu selectați Security Group (Grup de securitate)
  7. Selectați Grupul de securitate utilizat de instanța dvs. și faceți clic pe Tabul Inbound
  8. În partea stângă a tab-ului Inbound Tab (fila Inbound) puteți compune o regulă pentru traficul SSH de intrare:
    • Creați o regulă nouă: SSH
    • Sursa: Adresa IP sau subrețea din care doriți să accesați instanța
    • Notă: Dacă doriți să acordați acces nelimitat la instanța dvs. puteți specifica 0.0.0.0/0, , deși Amazon nu recomandă această practică
  9. Faceți clic pe Add Rule (Adăugare regulă) și apoi Aplicați modificările
  10. Verifică dacă acum poți să te conectezi la instanța ta prin SSH.

Sper că acest lucru poate ajuta pe cineva așa cum m-a ajutat pe mine.

Comentarii

  • A doua parte a răspunsului dvs. este greșită. Nu puteți obține „Permission denied (publickey).” (Permisiune refuzată (publickey).) dacă nu ați setat corect setările de firewall (Security Groups). „Permission denied (publickey).” este un mesaj de eroare de la SSH și este o dovadă că configurația Security Groups este corectă. În schimb, veți primi „ssh: connect to host x.x.x.x.x port 22: Connection refused” –  > Por Thibault D..
  • Pe scurt: Mesajul de eroare arată că această problemă nu are nicio legătură cu configurația Security Groups (Grupuri de securitate). –  > Por Thibault D..
  • Aveți dreptate. A doua parte tratează un alt tip de problemă. Am corectat postul. –  > Por Matteo Ceserani.
  • Dacă ați pierdut cheia, cred că o posibilă modalitate de rezolvare ar fi să faceți un instantaneu al instanței și apoi să porniți una nouă cu o nouă cheie. În acest caz, Amazon adaugă noua cheie publică în .ssh/authorized_keys, așa că asigurați-vă că o eliminați pe cea veche după aceea. (și aveți grijă să nu o eliminați pe cea nouă, altfel vă întoarceți la prima problemă).  > Por Thibault D..
Deepti Kohli

Iată cum am rezolvat problema

ssh -i <key> [email protected]<ec2 ip>

Comentarii

  • Se pare că cheia pentru mine aici a fost adresa DNS a gazdei vs IP. [email protected]<ip> a funcționat pentru mine. –  > Por Zack.
  • Soluție la fel de bine. –  > Por Tpojka.
Wellington Lorindo

Am rezolvat problema doar punând sudo înainte de

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

Dar soluția corectă este să schimbați mai întâi proprietatea și apoi să vă conectați ca utilizator normal, așa cum a spus Janus Troelsen mai jos. În cazul meu ar fi:

chown wellington:wellington key.pem

Comentarii

  • A funcționat pentru mine (a trebuit să actualizez unele pachete după aceea, deși)! –  > Por user1429980.
  • soluția corectă este să schimbi mai întâi proprietatea și apoi să te conectezi ca un utilizator normal. folosește sudo chown wellington:wellington key.pem. –  > Por Janus Troelsen.
  • funcționează, în cazul dvs. pentru că încercați să vă conectați la acel VM de la Amazon, care oferă asistență root utilizator –  > Por Taimoor Changaiz.
  • Făcusem whoami apoi sudo chown user_name_given_by_whoami xxxx.pem –  > Por Chirag Purohit.
Abhishek Gupta

Încercați să utilizați

sudo ssh -i mykey.pem [email protected]<ec2_ip_public_dns>

OR

sudo ssh -i mykey.pem [email protected]<ec2_ip_public_dns>

Stepan

O altă cauză posibilă a acestei erori:

Atunci când utilizatorul home directory este un grup care poate fi scris de către grup, , utilizatorul nu se poate autentifica.

(Reprodus pe o instanță Ubuntu.)

Comentarii

  • +1 Mi-aș fi dorit să fi citit asta acum 4 ore!!!! Mi-a rezolvat problema în care rsync -a suprascria permisiunea dosarului meu ec2-user. –  > Por Michael Hobbs.
  • După ce am făcut mv la directorul meu personal, nu m-am putut conecta. –  > Por Robert Moon.
  • Deci, cum te loghezi pe o mașină care este astfel afectată și nu te poți loga deloc pe ea? –  > Por PKHunter.
  • Fixarea permisiunilor pe directorul /home funcționează și pentru mine, mulțumesc! @AlexPetralia, linkul tău este stricat =/ dar are o postare pe forumul aws care vorbește despre asta: forums.aws.amazon.com/message.jspa?messageID=334402 –  > Por Liko.
  • Poate cineva ca Alex Petralia sau @Michael Hobbs să reposteze (sau să redea) soluția la acest lucru? –  > Por Jakub Langr.
dc10

pentru instanța ubuntu 12.04 lts micro a trebuit să setez numele de utilizator ca opțiune

ssh -i pemfile.pem -l ubuntu dns

Comentarii

  • acest lucru a funcționat pentru mine, sunt surprins că nu face parte din documentația aws pentru a discuta efectiv despre utilizatorii care pot fi necesari. –  > Por Ben.
Rabinarayan Panigrahi

Trebuie să efectuați următorii pași:

  1. Deschideți clientul ssh sau terminalul dacă folosiți Linux.
  2. Localizați fișierul cu cheia privată și schimbați directorul.
    cd <path to your .pem file>
  3. Executați comenzile de mai jos:
    chmod 400 <filename>.pem
    ssh -i <filename>.pem [email protected]<ipaddress.com>

Dacă ubuntu user nu funcționează, atunci încercați cu ec2-user.

Ben Paz

M-am luptat cu aceeași eroare de permisiune refuzată aparent din cauza

key_parse_private2: missing begin marker 

În situația mea, cauza a fost fișierul de configurare ssh al utilizatorului curent (~/.ssh/config).

Folosind următoarele:

ssh -i ~/myKey.pem [email protected]<IP address> -v 'exit'

Ieșirea inițială a arătat:

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

… multe linii de depanare tăiate aici …

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.

A treia linie de mai sus este cea în care a fost identificată problema reală; cu toate acestea, m-am uitat la mesajul de depanare la patru linii de jos (de mai sus) și am fost indus în eroare. Nu există o problemă cu cheia, dar am testat-o și am comparat alte configurații.

Fișierul meu de configurare ssh de utilizator a resetat gazda printr-o setare globală neintenționată, așa cum se arată mai jos. Prima linie Host nu ar fi trebuit să fie un comentariu.

$ 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

Sper ca altcineva să găsească acest lucru util.

JohnP

Am uitat să adaug numele de utilizator (ubuntu) atunci când mi-am conectat instanța Ubuntu. Așa că am încercat acest lucru:

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

iar modul corect a fost

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

Comentarii

  • Eroare legitimă de începător. Dacă uitați să adăugați numele de utilizator, atunci se va folosi numele de utilizator al utilizatorului cu care sunteți conectat în computerul local. –  > Por Thibault D..
Wade Anderson

Acest lucru mi s-a întâmplat de mai multe ori. Am folosit Amazon Linux AMI 2013.09.2 și Ubuntu Server 12.04.3 LTS, ambele la nivel gratuit.

De fiecare dată când am lansat o instanță mi se afișează permission denied. Nu am verificat acest lucru, dar teoria mea este că serverul nu este complet configurat înainte de a încerca să intru prin ssh în el. După câteva încercări cu permission denied, aștept câteva minute și apoi mă pot conecta. Dacă aveți această problemă, vă sugerez să așteptați cinci minute și să încercați din nou.

Seeker

Iată un posibil scenariu frustrant care produce această eroare:

Dacă lansați o nouă instanță dintr-o AMI pe care ați creat-o dintr-o altă instanță (de exemplu, instanța xyz), atunci noua instanță va accepta doar aceeași cheie pe care a folosit-o instanța A. Acest lucru este complet de înțeles, dar devine confuz deoarece, în timpul procesului pas cu pas de creare a noii instanțe, vi se cere să selectați sau să creați o cheie (la ultimul pas), ceea ce nu va funcționa.

Indiferent de cheia pe care o creați sau o selectați, numai cheia pe care o foloseați pentru instanța XYZ va fi acceptată de noua instanță.

Comentarii

  • De obicei, aceasta adaugă noua cheie publică la fișierul authorized_keys, făcând astfel ca ambele chei să fie utilizabile. Totuși, a trecut ceva timp de când am testat, dar la asta mă aștept să se întâmple. –  > Por Thibault D..
JedA

M-am luptat și eu cu acest lucru o vreme până când am găsit următoarele:

eb ssh

Când folosiți asta din directorul de proiect, bingo-bango no muss no fuss, sunteți în

AJNinja

În cazul meu, am făcut următoarele:

chmod 400 <key.pem>

ssh -i <key.pem> [email protected]_public_dns (for debian)

Inițial am folosit [email protected] part și am primit această solicitare:

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

Chetabahana

Sunt în Windows cu WinSCP. Funcționează foarte bine atât pe File Explorer, cât și pe PuTTY SSH Shell pentru a accesa Linux-ul meu Amazon EC2-VPC. Nu este nimic de făcut cu chmod pem file deoarece utilizează myfile.ppk convertit de PuTTYgen din pem.

eiTan LaVi

același lucru mi s-a întâmplat și mie, dar tot ce se întâmpla este că cheia privată s-a pierdut din keychain-ul de pe mașina locală.

ssh-add -K

a adăugat din nou cheia, apoi comanda ssh pentru conectare a revenit să funcționeze.

Comentarii

  • Se întâmplă de fiecare dată după repornire și trebuie să reiau comanda de mai sus orice soluție de lucru pentru acest lucru. –  > Por silentsudo.
  • nu am verificat acest lucru eu însumi, dar răspunsul verificat aici ar putea ajuta: apple.stackexchange.com/questions/254468/… –  > Por eiTan LaVi.
Prajith

Această problemă poate fi rezolvată prin autentificarea în caseta Ubuntu folosind comanda de mai jos:

ssh -i ec2key.pem [email protected]

Comentarii

  • Vă rugăm să dați câteva detalii. –  > Por Syeda Zunaira.
Greg Bell

Am avut de două ori cheile și linia de comandă ssh corecte (știu pentru că am duplicat o instanță Ubuntu 14.04 care funcționează), dar pur și simplu nu am reușit să intru prin ssh într-o nouă instanță, chiar și după ce am așteptat 5 minute, așa cum a sugerat Wade Anderson mai sus.

A trebuit să distrug și să recreez mașina. Acest lucru s-a întâmplat în două ocazii diferite. Din moment ce nu pot intra inițial, nu pot vedea ce este în neregulă.

Așadar, dacă aveți această problemă, încercați asta.

Mehran

trebuie să verifici aceste câteva lucruri:

  1. Asigură-te că adresa IP este corectă
  2. Asigurați-vă că folosiți cheia corectă
  3. Asigurați-vă că folosiți numele de utilizator corect, puteți încerca:3.1. admin3.2. ec2-user3.3. ubuntu

Am avut aceeași problemă, și s-a rezolvat după ce am schimbat numele de utilizator în ubuntu. În documentația AWS a fost menționat pentru utilizator ec2-user, dar cumva nu funcționează pentru mine.

Kuldeep Dangi

Cheia mea privată a fost setată la permisiunea 400 și a avut ca rezultat Permission denied (permisiune refuzată) setarea acesteia la „644” m-a ajutat .

key_load_private_type: Permisiune refuzată este eroarea specifică pe care o primeam

Soluție:Sudo chmod 644 <key.pem>

Notă: setat la 644 este obligatoriu, nu funcționa cu 400

Jerome Anthony

Când încercați să faceți

ssh -i <.pem path> [email protected]

primiți un mesaj care vă sfătuiește să utilizați ec2-user.

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

Deci, utilizați

ssh -i <.pem path> [email protected]

Manoj Sahu

Am avut aceeași problemă și este foarte ciudat. Dacă credeți că faceți totul bine, atunci urmați acest lucru: Uneori există o confuzie cu privire la utilizatorul pentru instanța EC2!!! Uneori primești ec2-user, ubuntu, centos etc. Deci, verificați-vă numele de utilizator pentru machie!!!

Autentificați-vă cu utilizatorul root
ssh -i yourkey.pem (400 permission) [email protected]<ip>
Se va arunca o eroare și vă va oferi numele de utilizator disponibil. apoi conectați-vă cu acel utilizator.

Andre Araujo

Este un lucru de bază, dar confirmați întotdeauna ce utilizator încercați să faceți autentificarea. În cazul meu a fost doar o distragere a atenției. Am încercat să folosesc un root utilizator:

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

Dar a fost un alt utilizator:

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

Azriel

am avut aceeași eroare, dar în altă situație. mie mi s-a întâmplat din senin, după o grămadă de timp în care am reușit să fac ssh cu succes la calculatorul meu de la distanță de acolo. după multe căutări, soluția la problema mea au fost permisiunile fișierelor. este ciudat, desigur, pentru că nu am schimbat nici o permisiune în calculatorul meu sau în cel de la distanță aparținând fișierelor/directoarelor de la ssh. așa că de la bunul archlinux wiki aici este:

Pentru mașina locală faceți așa:

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

Pentru mașina de la distanță faceți asta:

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

după care ssh-ul meu a început să funcționeze din nou fără chestia cu permisiunea refuzată (publickey).

Mike Q

O altă problemă posibilă: ID de conectare greșit

Verificați „Instrucțiuni de utilizare

Toate sugestiile bune de mai sus, dar ceea ce am întâlnit a fost că am selectat o instanță pre-făcută. După ce instanța a pornit , uitați-vă la instrucțiunile de utilizare. Am folosit incorect ID-ul de autentificare al cheii private, când în instrucțiuni trebuia să folosesc „bitnami” (de exemplu, [email protected] -i key.pem)

ARN

Am avut o eroare similară

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

Problema mea a fost că instanța nu a pornit corect din cauza unei erori pe scriptul run-on-start-up de la Step 3: Configure instance detail sub Advanced details:

Ce am crezut că am introdus:

#include

https://xxxx/bootstrap.sh


Ceea ce am introdus de fapt întrerupe configurarea instanței

#include

https://xxxx/bootstrap.sh

Deci, cheia publică din partea instanței nu a fost creată.

Tanmay

Este sensibilă la majuscule și minuscule.

Greșit : SSH EC2-user@XXX.XX.XX.XX.XX -i MyEC2KeyPair.pem

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

Petko M

Am reușit să fac SSH de pe o mașină, dar nu și de pe alta. Se pare că foloseam o cheie privată greșită.

Modul în care mi-am dat seama de acest lucru a fost să obțin cheia publică din cheia mea privată, astfel:

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

Ceea ce a ieșit nu se potrivea cu ceea ce era în ~/.ssh/authorized_keys pe instanța EC2.

pbegle

Toate răspunsurile de mai sus sunt corecte și ar trebui să funcționeze pentru majoritatea cazurilor. În cazul în care nu funcționează, așa cum a fost în cazul meu, am scăpat pur și simplu de cheia mea ~/.ssh/known_hosts de pe mașina de pe care încercam să fac ssh și asta a rezolvat problema pentru mine. Am reușit să mă conectez după aceea.

Comentarii

  • În timp ce ștergeam known_hosts poate rezolva o problemă atunci când se conectează la un server care și-a schimbat cheia de gazdă (deși este oricum o abordare proastă), sunt destul de sigur că nu poate rezolva „Permisiune refuzată (publickey)” error. –  > Por Martin Prikryl.