AWS ssh access 'Autorisation refusée (publickey)' [fermé]

284

Comment se connecter à une instance AWS via ssh?

J'ai:

  1. Inscrit à AWS;
  2. Créé une clé publique et un certificat sur le site Web AWS et les a enregistrés sur le disque;

  3. Je suis allé sur ma console et j'ai créé des variables d'environnement: 

    $ 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. A dit à l'API AWS d'utiliser cette paire de clés et a enregistré la paire de clés dans un fichier: 

    $ ec2-add-keypair ec2-keypair > ec2-keypair.pem

  5. A démarré une instance AWS Ubuntu 9 à l'aide de cette paire de clés: 

    $ ec2-run-instances ami-ed46a784 -k ec2-keypair

  6. Vous avez tenté d'établir une connexion ssh à l'instance: 

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

    Quel pourrait être le problème et comment le faire fonctionner?

amazon-web-services  ssh-keys 
— Alex
source
2
Ironic est que j'utilise "root" comme nom d'utilisateur mais "ubuntu" (ce que vous avez mentionné) est le bon nom pour mon AMI, et merci pour votre message!
— realjin
— CtheGood

Réponses:

512

Pour les instances Ubuntu:

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

Pour d'autres instances, vous devrez peut-être utiliser à la ec2-userplace de ubuntu.

La plupart des images EC2 Linux que j'ai utilisées n'ont que l'utilisateur root créé par défaut.

Voir aussi: http://www.youtube.com/watch?v=WBro0TEAd7g

— sipwiz
source
6
Tu gères! Tellement simple!
— Alex
50
Vous pouvez également utiliser ssh-add ec2-keypair.pem pour supprimer l'option -i
— AdamK
12
si vous essayez root et que vous obtenez "Veuillez vous connecter en tant qu'utilisateur ec2 plutôt qu'en tant qu'utilisateur root." "utilisez ec2-user à la place de root.
— Tony
8
Et certaines images d'Ubuntu semblent avoir uniquement l'utilisateur "ubuntu". (Qui peut sudo pour rooter.)
— Prof. Falken
1
Super, super utile.
— NSCoder
93

Maintenant c'est:

ssh -v -i ec2-keypair.pem ec2-user@[yourdnsaddress]
— SSH
source
Merci. Cela m'a pris beaucoup de temps pour le découvrir - ce n'est pas mentionné dans les informations de connexion de la console! Cela vous dit quand vous essayez d'utiliser root, mais je pensais que ec2-user était une référence à mon nom d'utilisateur. Ah!
— Adrian Mouat
1
Oh mec. Pas une friandise facile à trouver. Merci!
— vroomfondel
merci, pas facile de trouver celui-ci
Très bien! Je vous remercie!
— viana
46

Les versions de Canonical utilisent par défaut l'utilisateur 'ubuntu' pour quiconque atterrit ici avec une image ubuntu qui rencontre le même problème.

— bryon
source
2
Pas facile de trouver celui-ci.
— Gustav
17

Si vous utilisez une image Bitnami, connectez-vous en tant que «bitnami».

Cela semble évident, mais quelque chose que j'ai négligé.

— akim
source
Votre réponse m'a sauvé la journée!
— Surya
2
Vouliez-vous dire? Seems <sarcasm>obvious</sarcasm>
— Bob Stein
Instructions Bitnami , y compris comment trouver les mots de passe de la base de données.
— Bob Stein
8

Pour mes images ubuntu, il s'agit en fait de l'utilisateur ubuntu et NON de l'utilisateur ec2;)

— Dean Hiller
source
5

Ubuntu 10.04 avec openSSH

c'est l'usage exact:

ssh -v -i [yourkeypairfile] ec2-user@[yourdnsaddress]

par exemple:

ssh -v -i GSG_Keypair.pem ec2-user@ec2-184-72-204-112.compute-1.amazonaws.com

l'exemple ci-dessus a été tiré directement du didacticiel AWS pour la connexion à une machine Linux / UNIX à l' adresse : http://docs.amazonwebservices.com/AWSEC2/latest/GettingStartedGuide/

— carl crott
source
Avec le commutateur ssh -i, nous ne pouvons utiliser que le fichier .pem.
— ABHAY JOHRI
5

Il se plaindra également si les autorisations du fichier pem sont trop ouvertes. modifiez le fichier à 600 pour résoudre ce problème.

— Allan Bogh
source
Merci pour cette astuce - m'a beaucoup aidé
— Billy Moon
4
Pour les novices .. la commande pour ce faire serait:chmod 600 your_file.pem
— dano
5

J'étais également confronté à cela - il s'avère que j'utilisais une AMI créée par la communauté - et le nom d'utilisateur par défaut était niehter root, ni ect-user ni ubuntu. En fait, je n'avais aucune idée de ce que c'était - jusqu'à ce que j'essaie « root » et que le serveur me demande gentiment de me connecter en tant que xxx où xxx est tout ce qu'il vous dit.

-à votre santé!

— kevinfoundananswwer
source
4

Vous devez avoir votre clé privée sur votre machine locale

Vous devez connaître l'adresse IP ou le nom DNS de votre machine ou serveur distant, vous pouvez l'obtenir à partir de la console AWS

Si vous êtes un utilisateur Linux

  • Assurez-vous que les autorisations sur la clé privée sont 600 ( chmod 600 <path to private key file>)
  • Connectez-vous à votre machine à l'aide de ssh ( ssh -i <path to private key file> <user>@<IP address or DNS name of remote server>)

Si vous êtes un utilisateur Windows

— Vineeth Guna
source
Modifier l'autorisation du fichier à l'aide de chmod 400 <clé pem>
— Vaibhav Jain
3

utilisation... 

# chmod 400 ec2-keypair.pem

n'utilisez pas l'autorisation 600 sinon vous risquez d'écraser accidentellement votre clé.

— x1b2j
source
2

cela a fonctionné pour moi:

ssh-keygen -R <server_IP>

pour supprimer les anciennes clés stockées sur le poste de travail fonctionne également avec au lieu de

puis en faisant à nouveau le même ssh, cela a fonctionné:

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

sur les instances ubuntu, le nom d'utilisateur est: ubuntu sur Amazon Linux AMI, le nom d'utilisateur est: ec2-user

Je n'ai pas eu à recréer l'instance à partir d'une image.

— Cris
source
2

Il y a 2 étapes à connecter:

Chmod 400 sur votre clé privée, comme ça les autres ne peuvent pas accéder à votre clé:

chmod 400 toto.pem

Pour vous connecter à votre instance dans SSH, vous devez connaître l'adresse IP publique de votre instance: 

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

J'espère que ça aide !

— GuillaumeAgis
source
1

Si vous utilisez EBS, vous pouvez également essayer de monter le volume EBS sur une instance en cours d'exécution. Montez-le ensuite sur cette instance en cours d'exécution et voyez ce qui se passe dans / home. Vous pouvez voir des choses comme l'utilisateur ubuntu ou ec2-user? ou a-t-il les bonnes clés publiques sous ~ / .ssh / authorized_keys

— Rico
source
1

L'autorisation pour ec2-keypair.pemdevrait être400

chmod 400 ec2-keypair.pem

— Yogi
source
1

Si vous exécutez une image AWS à partir de Bitnami. Le nom d'utilisateur serait bitnami. À votre santé!

voir mon débogage et regardez le dernier:

*

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

*

— Hung Do
source
1

Dans mon cas (Mac OS X), le problème était le type de rupture du fichier. Essaye ça:

1.- Ouvrez le fichier .pem avec TextWrangler

2.- En bas de l'application, vérifiez si le type de rupture est "Windows (CRLF)".

— pmartinezd
source
1

Son utilisateur ec2 pour Amazon Linux AMI et ubuntu pour les images Ubuntu. Aussi, RHEL 6.4 et versions ultérieures ec2-user RHEL 6.3 et versions antérieures Root Fedora ec2-user Centos root

— Amith Ajith
source
0

Ajout juste à cette liste. J'avais des problèmes ce matin avec un nouvel utilisateur venant d'être ajouté à une instance AWS EC2. Pour aller droit au but, le problème était le selinux (qui était en mode d' application ), ainsi que le fait que mon répertoire personnel était sur un nouveau volume attaché EBS. D'une certaine manière, je suppose que selinux n'aime pas cet autre volume. Il m'a fallu un certain temps pour comprendre, alors que je regardais tous les autres problèmes ssh habituels (/ etc / ssh / sshd_config était bien, bien sûr aucun mot de passe n'était autorisé, les autorisations étaient bonnes, etc.)

La solution?

Pour l'instant (jusqu'à ce que je comprenne comment autoriser un utilisateur à ssh vers un volume différent, ou en quelque sorte faire de ce volume un point de répertoire personnel de bonne foi):

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

C'est tout. Mon nouvel utilisateur peut désormais se connecter en utilisant sa propre clé id_rsa.

— Pierre D
source
0

Eu le même problème. Autorisation refusée (publickey) lorsque vous essayez de vous connecter avec 'ec2-user' ou avec 'root'.

Googlé le numéro AMI de l'image de la machine et il avait les informations de connexion SSH directement sur la page wiki Debian.

J'espère que cela t'aides.

— Lionel Morrison
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.