Autorizzazione negata (chiave pubblica) quando Accesso SSH all'istanza Amazon EC2 [chiuso]

Voglio usare la mia istanza di Amazon ec2 ma ho riscontrato il seguente errore:

Permission denied (publickey).

Ho creato la mia coppia di chiavi e scaricato il file .pem .

Dato:

chmod  600 pem file.

Quindi, questo comando

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

Ma hai questo errore:

Permission denied (publickey)

Inoltre, come posso collegarmi con filezilla per caricare / scaricare file?

Questo messaggio di errore indica che non è stato possibile eseguire l'autenticazione.

Questi sono motivi comuni che possono causare che:

1. Prova di connettersi con la chiave sbagliata. Sei sicuro che questa istanza stia usando questa coppia di chiavi?
2. Prova di connettersi con un nome utente errato. ubuntuè il nome utente per la distribuzione AWS base Ubuntu, ma su alcuni altri è di ec2-user(o adminsu alcune Debians, secondo la risposta di Bogdan Kulbida) (può anche essere root, fedora, vedi sotto)
3. Prova di connettere l'host sbagliato. È l'host giusto a cui stai tentando di accedere?

Nota che 1.accadrà anche se hai incasinato il /home/<username>/.ssh/authorized_keysfile sulla tua istanza EC2.

A proposito 2., le informazioni su quale nome utente si dovrebbe usare spesso mancano dalla descrizione dell'immagine AMI. Ma puoi trovarne alcuni nella documentazione di AWS EC2, punto elenco4. : http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

Utilizzare il comando ssh per connettersi all'istanza. Specifichi il file della chiave privata (.pem) e il nome utente @ nome_dns pubblico. Per Amazon Linux, il nome utente è ec2-user. Per RHEL5, il nome utente è root o ec2-user . Per Ubuntu, il nome utente è ubuntu . Per Fedora, il nome utente è fedora o ec2-user . Per SUSE Linux, il nome utente è root . Altrimenti, se l'utente ec2 e root non funzionano, consultare il proprio provider AMI.

Infine , tieni presente che ci sono molte altre ragioni per cui l'autenticazione fallirebbe. SSH di solito è piuttosto esplicito su cosa è andato storto se ti interessa aggiungere l' -vopzione al tuo comando SSH e leggere l'output, come spiegato in molte altre risposte a questa domanda.

In questo caso il problema sorge dalla perdita della coppia di chiavi. A questo proposito:

• Non è possibile modificare la coppia di chiavi in ​​un'istanza . Devi creare una nuova istanza che utilizza una nuova coppia di chiavi.
• Puoi aggirare il problema se l'istanza viene utilizzata da un'applicazione su Elastic Beanstalk .

Puoi seguire questi passaggi:

1. Accesso a console di gestione AWS
2. Apri fagiolo magico elastico scheda
3. Seleziona la tua applicazione da Tutte le applicazioni scheda
4. Dal menu di sinistra selezionare Configurazione
5. Clicca sul istanze Gear
6. In Server Form controlla l' ingresso EC2 Key Pair e seleziona la tua nuova Key Key. Potrebbe essere necessario aggiornare l'elenco per vedere una nuova coppia di chiavi appena creata.
7. Salva
8. Elastic Beanstalk creerà per te nuove istanze associate alla nuova coppia di chiavi.

In generale, ricorda che devi consentire alla tua istanza EC2 di accettare il traffico SSH in entrata.

Per fare ciò, è necessario creare una regola specifica per il gruppo di sicurezza dell'istanza EC2. Puoi seguire questi passaggi.

1. Accesso alla console di gestione AWS
2. Apri la scheda EC2
3. Dall'elenco Istanze seleziona l'istanza che ti interessa
4. Nella scheda Descrizione controllare il nome del gruppo di sicurezza utilizzato dall'istanza.
5. Sempre nella scheda Descrizione fai clic su Visualizza regole e controlla se il tuo gruppo di sicurezza ha una regola per il traffico ssh in entrata sulla porta 22
6. In caso contrario, nel menu Rete e sicurezza selezionare Gruppo sicurezza
7. Selezionare il gruppo di sicurezza utilizzato dall'istanza e fare clic scheda Inbound
8. A sinistra della scheda Inbound è possibile comporre una regola per il traffico in ingresso SSH:
   • Crea una nuova regola : SSH
   • Origine : indirizzo IP o sottorete da cui si desidera accedere all'istanza
   • Nota : se desideri concedere un accesso illimitato alla tua istanza, puoi specificare 0.0.0.0/0 , anche se Amazon non consiglia questa pratica
9. Fai clic su Aggiungi regola e quindi Applica le tue modifiche
10. Controlla se sei ora in grado di connetterti alla tua istanza tramite SSH.

Spero che questo possa aiutare qualcuno come mi ha aiutato.

Ecco come ho risolto il problema

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

Ho risolto il problema appena sudoprima

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

Ma la soluzione corretta è cambiare prima la proprietà, quindi connettersi come un normale utente come ha detto Janus Troelsen di seguito. Nel mio caso sarebbe:

chown wellington:wellington key.pem

Prova a usare

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

O

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

Un'altra possibile causa di questo errore:

Quando la home directory dell'utente è scrivibile in gruppo , l'utente non può accedere.

(Riprodotto su istanza Ubuntu.)

per la microistanza ubuntu 12.04 lts ho dovuto impostare il nome utente come opzione

ssh -i pemfile.pem -l ubuntu dns

Devi fare i seguenti passi:

1. Apri il tuo client o terminale ssh se stai usando Linux.
2. Individua il file della chiave privata e modifica la directory.
   cd <path to your .pem file>
3. Eseguire i comandi seguenti:
   chmod 400 <filename>.pem
ssh -i <filename>.pem ubuntu@<ipaddress.com>

Se l' ubuntuutente non funziona, provare con ec2-user.

Ho lottato con la stessa autorizzazione a cui è stato negato l'errore apparentemente dovuto

key_parse_private2: missing begin marker 

Nella mia situazione la causa era il file di configurazione ssh dell'utente corrente (~ / .ssh / config).

Utilizzando quanto segue:

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

L'output iniziale ha mostrato:

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

... molte linee di debug tagliate qui ...

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.

La terza riga sopra è dove è stato identificato il problema effettivo; tuttavia, ho cercato il messaggio di debug a quattro righe dal basso (sopra) e sono stato fuorviato. Non c'è un problema con la chiave, ma l'ho testato e confrontato altre configurazioni.

Il mio file di configurazione utente ssh ha ripristinato l'host tramite un'impostazione globale non intenzionale, come mostrato di seguito. La prima riga host non avrebbe dovuto essere un commento.

$ 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

Spero che qualcun altro lo trovi utile.

Ho dimenticato di aggiungere il nome utente (ubuntu) durante la connessione della mia istanza di Ubuntu. Quindi ho provato questo:

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

e il modo corretto era

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

Questo mi è successo più volte. Ho usato Amazon Linux AMI 2013.09.2 e Ubuntu Server 12.04.3 LTS che sono entrambi di livello gratuito.

Ogni volta che ho lanciato un'istanza mi viene negata l'autorizzazione. Non l'ho verificato, ma la mia teoria è che il server non è completamente impostato prima di provare a utilizzarlo. Dopo alcuni tentativi con l'autorizzazione negata, aspetto alcuni minuti e quindi riesco a connettermi. Se riscontri questo problema, ti suggerisco di attendere cinque minuti e riprovare.

Ecco alcuni possibili scenari frustranti che producono questo errore:

Se stai pranzando una nuova istanza da un AMI che hai creato di un'altra istanza (ad esempio istanza xyz), la nuova istanza accetterà solo la stessa chiave utilizzata dall'istanza A. Questo è totalmente comprensibile ma diventa confuso perché durante il processo passo passo della creazione della nuova istanza, ti viene chiesto di selezionare o creare una chiave (all'ultimo passaggio) che non funzionerà.

Indipendentemente dalla chiave creata o selezionata, solo la chiave utilizzata per esempio XYZ verrà accettata dalla nuova istanza.

Ho lottato con questo per un po 'fino a quando ho trovato quanto segue:

eb ssh

Quando lo usi dalla directory del progetto, bingo-bango no muss no fuss, sei dentro

Nel mio caso, ho fatto quanto segue:

chmod 400 <key.pem>

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

Inizialmente stavo usando la root@parte e ho ricevuto questo messaggio:

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

Sono in Windows con WinSCP . Funziona perfettamente su File Explorer e PuTTY SSH Shell per accedere al mio Amazon EC2-VPC Linux. Non c'è nulla a che fare con chmod pem fileil fatto che utilizza myfile.ppk convertito da PuTTYgen dal file pem .

mi è successa la stessa cosa, ma tutto ciò che stava accadendo è che la chiave privata si è persa dal portachiavi sulla mia macchina locale.

ssh-add -K

ha aggiunto nuovamente la chiave, quindi il comando ssh per la connessione è tornato a funzionare.

Questo problema può essere risolto accedendo alla casella Ubuntu usando il comando seguente:

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

Ho avuto due volte le chiavi e la riga di comando ssh corrette (lo so perché sto duplicando un'istanza di Ubuntu 14.04 funzionante), ma non sono stata in grado di ssh in una nuova istanza, anche dopo aver atteso 5 minuti come suggerito da Wade Anderson sopra.

Ho dovuto distruggere e ricreare la macchina. Questo è successo in due diverse occasioni. Dato che inizialmente non riesco a entrare, non riesco a vedere cosa c'è che non va.

Quindi, se hai questo problema, provalo.

devi controllare queste poche cose:

1. Assicurati che il tuo indirizzo IP sia corretto
2. Assicurati di utilizzare la chiave corretta
3. Assicurati di utilizzare il nome utente corretto, puoi provare: 3.1. admin 3.2. utente ec2 3.3. ubuntu

Ho avuto lo stesso problema, e risolto dopo aver cambiato il nome utente in Ubuntu. Nella documentazione AWS è stata menzionata l'utente ec2-user, ma in qualche modo non funziona per me.

La mia chiave privata è stata impostata su autorizzazione 400e mi ha permesso di negare l'autorizzazione impostandola su "644".

key_load_private_type: l'autorizzazione negata è l'errore specifico che stavo ottenendo

Soluzione: Sudo chmod 644 <key.pem>

Nota: impostato su 644 è obbligatorio, non funzionava con 400

Quando provi a farlo

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

Viene visualizzato un messaggio che consiglia di utilizzare il ec2-user.

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

Quindi usa

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

Ho avuto lo stesso problema ed è molto strano. Se ritieni di fare tutto bene, segui questo: alcune volte c'è confusione sull'utente per l'istanza EC2 !! Alcune volte ottieni ec2-user, ubuntu, centos ecc. Quindi controlla il tuo nome utente per il machie !!

Accedi con l'utente root ssh -i yourkey.pem (400 permission) root@<ip> genererà un errore e ti fornirà il nome utente disponibile . quindi accedi con quell'utente.

È una cosa di base, ma conferma sempre quale utente stai tentando di eseguire l'accesso. Im il mio caso è stata solo una distrazione . Stavo provando a utilizzare un utente root :

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

Ma era un altro utente :

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

ho avuto lo stesso errore ma situazione diversa. a me è successo all'improvviso dopo un sacco di tempo che sono riuscito a ssh con successo sul mio computer remoto là fuori. dopo molte ricerche nella soluzione al mio problema c'erano le autorizzazioni per i file. è strano ovviamente perché non ho cambiato nessuna autorizzazione nel mio computer o in quella remota appartenente ai file / directory di ssh. quindi dalla buona wiki di archlinux eccolo qui:

Per il computer locale, procedere come segue:

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

Per la macchina remota, procedere come segue:

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

dopo che il mio ssh ha ricominciato a funzionare senza il permesso negato (publickey).

Un altro possibile problema: ID di accesso errato

Controlla le "Istruzioni d'uso"

Tutti i buoni suggerimenti di cui sopra, ma quello che ho incontrato è che ho selezionato un'istanza pre-fatta. Dopo l'avvio dell'istanza, consultare le istruzioni per l'uso. Ho usato erroneamente l'id di accesso della chiave privata quando nelle istruzioni avrei dovuto usare 'bitnami' (es. Bitnami @ domain -i key.pem)

Ho avuto un errore simile

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

Il mio problema era che l'istanza non si avviava correttamente a causa di un errore sullo script di avvio all'avvio da Step 3: Configure instance detailsottoAdvanced details:

Quello che pensavo di aver inserito:

#include
 https://xxxx/bootstrap.sh


Ciò che è effettivamente inserito interrompe la configurazione dell'istanza

#include

https://xxxx/bootstrap.sh

Quindi la chiave pubblica sul lato dell'istanza non è stata creata

Fa distinzione tra maiuscole e minuscole.

Errato: utente SSH EC2 @ XXX.XX.XX.XX -i MyEC2KeyPair.pem

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

Sono stato in grado di SSH da una macchina, ma non da un'altra. Risulta che stavo usando la chiave privata sbagliata.

Il modo in cui l'ho capito è stato ottenere la chiave pubblica dalla mia chiave privata, in questo modo:

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

Ciò che è uscito non corrisponde a quello che era ~/.ssh/authorized_keyspresente nell'istanza EC2.

Tutte le risposte in alto classificate sopra sono accurate e dovrebbero funzionare nella maggior parte dei casi. Nel caso in cui non fossero come nel mio caso, mi sono semplicemente sbarazzato del mio ~/.ssh/known_hostsfile sulla macchina da cui stavo cercando di risolvere e il problema è stato risolto. Sono stato in grado di connettermi in seguito.