Problema "Autorizzazione negata (chiave pubblica)" per l'accesso ssh AWS [chiuso]


284

Come connettersi a un'istanza AWS tramite ssh?

Io ho:

  1. Iscrizione ad AWS;
  2. Creato una chiave pubblica e un certificato sul sito Web AWS e li ha salvati su disco;
  3. Sono andato alla mia console e ho creato variabili d'ambiente:

    $ export JAVA_HOME=/usr/lib/jvm/java-6-openjdk/
    $ export EC2_CERT=/home/default/aws/cert-EBAINCRNWHDSCWWIHSOKON2YWGJZ5LSQ.pem
    $ export EC2_PRIVATE_KEY=/home/default/aws/pk-EBAINCRNWHDSCWWIHSOKON2YWGJZ5LSQ.pem
    
  4. Detto API AWS per utilizzare questa coppia di chiavi e salvato la coppia di chiavi su file:

    $ ec2-add-keypair ec2-keypair > ec2-keypair.pem
    
  5. Ha avviato un'istanza di AWS Ubuntu 9 utilizzando questa coppia di chiavi:

    $ ec2-run-instances ami-ed46a784 -k ec2-keypair
    
  6. Tentativo di stabilire una connessione ssh all'istanza:

    $ ssh -v -i ec2-keypair.pem ubuntu@ec2-174-129-185-190.compute-1.amazonaws.com
    OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug1: Connecting to ec2-174-129-185-190.compute-1.amazonaws.com [174.129.185.190] port 22.
    debug1: Connection established.
    debug1: identity file ec2-keypair.pem type -1
    debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5ubuntu1
    debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug1: kex: server->client aes128-cbc hmac-md5 none
    debug1: kex: client->server aes128-cbc hmac-md5 none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug1: Host 'ec2-174-129-185-190.compute-1.amazonaws.com' is known and matches the RSA host key.
    debug1: Found key in /home/default/.ssh/known_hosts:11
    debug1: ssh_rsa_verify: signature correct
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: SSH2_MSG_NEWKEYS received
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug1: Authentications that can continue: publickey
    debug1: Next authentication method: publickey
    debug1: Trying private key: ec2-keypair.pem
    debug1: read PEM private key done: type RSA
    debug1: Authentications that can continue: publickey
    debug1: No more authentication methods to try.
    Permission denied (publickey).
    

    Quale potrebbe essere il problema e come farlo funzionare?


2
Ironia della sorte è che uso "root" come nome utente ma "ubuntu" (quello che hai menzionato) è il nome giusto per il mio AMI, e grazie per il tuo post!
Realjin,

Risposte:


512

Per le istanze di Ubuntu:

chmod 600 ec2-keypair.pem
ssh -v -i ec2-keypair.pem ubuntu@ec2-174-129-185-190.compute-1.amazonaws.com

Per altri casi, potrebbe essere necessario utilizzare ec2-userinvece di ubuntu.

La maggior parte delle immagini Linux EC2 che ho usato hanno solo l'utente root creato di default.

Vedi anche: http://www.youtube.com/watch?v=WBro0TEAd7g


6
Sei forte! Così dannatamente semplice!
Alex,

50
Puoi anche usare ssh-add ec2-keypair.pem in modo da poter eliminare l'opzione -i
AdamK,

12
se provi root e ottieni "Effettua il login come utente ec2 anziché utente root." "usa ec2-user al posto di root.
Tony,

8
E alcune immagini di Ubuntu sembrano avere solo l'utente "ubuntu". (Che può essere sudo per root.)
Prof. Falken,

1
Super, super utile.
NSCoder

93

Adesso è:

ssh -v -i ec2-keypair.pem ec2-user@[yourdnsaddress]

Grazie. Mi ci sono voluti anni per scoprirlo - non è menzionato nelle informazioni di connessione dalla console! Ti dice quando tenti di usare root, ma pensavo che ec2-user fosse un riferimento al mio nome utente. Doh!
Adrian Mouat,

1
Oddio. Non è un bocconcino facile da trovare. Grazie!
vroomfondel,

grazie, non è facile trovarlo

Molto bene! Grazie!
Viana,

46

Le versioni di Canonical utilizzano l'utente 'Ubuntu' per impostazione predefinita per chiunque atterra qui con un'immagine Ubuntu che presenta lo stesso problema.


2
Non è facile scoprirlo.
Gustav,


8

Per le mie immagini Ubuntu, in realtà è l'utente Ubuntu e NON l'utente ec2;)



5

Si lamenterà anche se le autorizzazioni del file pem sono troppo aperte. chmod il file a 600 per risolvere il problema.


Grazie per questo suggerimento - mi ha aiutato molto
Billy Moon,

4
Per i principianti .. il comando per fare questo sarebbe:chmod 600 your_file.pem
dano,

5

Stavo anche incontrando questo - risulta che stavo usando un AMI creato dalla comunità - e il nome utente predefinito era niehter root, né era ect-user o ubuntu. In realtà, non avevo idea di cosa fosse - finché non ho provato " root " e il server mi ha gentilmente chiesto di accedere come xxx dove xxx è quello che ti dice.

-Saluti!


4

È necessario disporre della chiave privata nel computer locale

Devi conoscere l'indirizzo IP o il nome DNS del tuo computer o server remoto, puoi ottenerlo dalla console AWS

Se sei un utente Linux

  • Assicurarsi che le autorizzazioni sulla chiave privata siano 600 ( chmod 600 <path to private key file>)
  • Connettiti al tuo computer usando ssh ( ssh -i <path to private key file> <user>@<IP address or DNS name of remote server>)

Se sei un utente di Windows


Modifica l'autorizzazione del file utilizzando chmod 400 <chiave pem>
Vaibhav Jain

3

uso...

# chmod 400 ec2-keypair.pem

non utilizzare l'autorizzazione 600, altrimenti potresti sovrascrivere accidentalmente la chiave.


2

questo ha funzionato per me:

ssh-keygen -R <server_IP>

per eliminare le vecchie chiavi memorizzate sulla workstation funziona anche con

poi facendo di nuovo lo stesso ssh ha funzionato:

ssh -v -i <your_pem_file> ubuntu@<server_IP>

su istanze ubuntu il nome utente è: ubuntu su Amazon Linux AMI il nome utente è: ec2-user

Non ho dovuto ricreare l'istanza da un'immagine.



2

Ci sono 2 passaggi da collegare:

Chmod 400 sulla tua chiave privata, in questo modo gli altri non possono accedere alla tua chiave:

chmod 400 toto.pem

Per connettersi all'istanza in SSH, è necessario conoscere l'indirizzo IP pubblico dell'istanza:

ssh -i toto.pem ec2-user@XX.XX.XX.XXX

Spero che sia d'aiuto !


1

Se si utilizza EBS, è anche possibile provare a montare il volume EBS su un'istanza in esecuzione. Quindi montalo su quell'istanza in esecuzione e vedi cosa succede in / home. Puoi vedere cose come l'utente ubuntu o l'utente ec2? o ha le chiavi pubbliche giuste sotto ~ / .ssh / authorized_keys


1

L'autorizzazione per ec2-keypair.pemdovrebbe essere400

chmod 400 ec2-keypair.pem


1

Se stai eseguendo un'immagine AWS da Bitnami. Il nome utente sarebbe bitnami. Saluti!

guarda il mio debug e guarda l'ultimo:

*

ssh -v -i awsliferaysrta.pem.txt root@54.254.250.***
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to 54.254.250.*** [54.254.250.***] port 22.
debug1: Connection established.
debug1: identity file awsliferaysrta.pem.txt type -1
debug1: identity file awsliferaysrta.pem.txt-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH_5*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 05:5c:78:45:c9:39:3a:84:fe:f8:19:5d:31:48:aa:5f
debug1: Host '54.254.250.***' is known and matches the RSA host key.
debug1: Found key in /Users/macbookpro/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: awsliferaysrta.pem.txt
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to 54.254.250.*** ([54.254.250.***]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Remote: Port forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Forced command.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Please login as the user "bitnami" rather than the user "root".

*


1

Nel mio caso (Mac OS X), il problema era il tipo di interruzione del file. Prova questo:

1.- Apri il file .pem con TextWrangler

2.- Nella parte inferiore dell'app, verificare se il tipo di interruzione è "Windows (CRLF)".


1

Il suo utente ec2 per Amazon Linux AMI e Ubuntu per immagini Ubuntu. Inoltre, RHEL 6.4 e successivi ec2-user RHEL 6.3 e precedenti root Fedora ec2-user Centos root


0

Sto solo aggiungendo a questo elenco. Stamattina ho avuto problemi con un nuovo utente appena aggiunto a un'istanza di AWS EC2. Per andare al sodo, il problema era selinux (che era in modalità di applicazione ), insieme al fatto che la mia home directory utente era su un nuovo volume collegato a EBS. In qualche modo immagino che a selinux non piaccia quell'altro volume. Mi ci è voluto un po 'per capire, mentre guardavo tutti gli altri soliti problemi di ssh (/ etc / ssh / sshd_config andava bene, ovviamente nessuna password consentita, le autorizzazioni erano giuste, ecc.)

La correzione?

Per ora (fino a quando non avrò capito come consentire a un utente di ssh su un altro volume, o in qualche modo rendere quel volume un vero punto di riferimento home):

sudo perl -pi -e 's/^SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config
sudo setenforce 0

Questo è tutto. Ora il mio nuovo utente può accedere, usando la sua chiave id_rsa.


0

Aveva lo stesso problema. Autorizzazione negata (chiave pubblica) quando si tenta di accedere con 'ec2-user' o con 'root'.

Ho cercato su Google il numero AMI dell'immagine della macchina e aveva le informazioni di accesso SSH proprio sulla loro pagina wiki Debian.

Spero che questo ti aiuti.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.