web-dev-qa-db-fra.com

Problème 'Autorisation refusée (publickey)' de l'accès AWS ssh

Comment se connecter à une instance AWS via ssh?

J'ai:

  1. Inscrit à AWS;
  2. A créé une clé publique et un certificat sur le site Web AWS et les a sauvegardées sur un 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. Indiquez à l'API AWS d'utiliser cette paire de clés et enregistrez-la dans un fichier:

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

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

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

  6. Tentative d’établir une connexion SSH à l’instance:

    $ ssh -v -i ec2-keypair.pem [email protected]
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-servicesssh-keys
268
Alex

Pour les instances Ubuntu:

chmod 600 ec2-keypair.pem
ssh -v -i ec2-keypair.pem [email protected]

Dans d'autres cas, vous devrez peut-être utiliser ec2-user au lieu 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

492
sipwiz

Maintenant c'est:

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

Les versions de Canonical utilisent par défaut l'utilisateur 'ubuntu' pour tous ceux qui débarquent ici avec une image ubuntu présentant le même problème.

46
bryon

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

Cela semble évident, mais c'est quelque chose que j'ai oublié.

17
akim

Pour mes images Ubuntu, il s’agit en fait d’un utilisateur Ubuntu et NON de l’utilisateur ec2;)

8
Dean Hiller

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

5
Allan Bogh

Ubuntu 10.04 avec openSSH

c'est l'utilisation exacte:

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

par exemple:

ssh -v -i GSG_Keypair.pem [email protected]

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

5
carl crott

Je me trouvais aussi confronté à ceci - 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'aie essayé 'root' et le serveur m'a gentiment demandé de me connecter en tant que xxx où xxx est ce qu'il vous dit.

-à votre santé!

5
kevinfoundananswwer

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

Vous devez connaître l'adresse IP ou le nom DNS de votre machine ou de votre 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 en utilisant ssh (ssh -i <path to private key file> <user>@<IP address or DNS name of remote server>)

Si vous êtes un utilisateur Windows

4
Vineeth Guna

utilisation...

# chmod 400 ec2-keypair.pem

n'utilisez pas l'autorisation 600 sinon vous pourriez écraser votre clé par inadvertance.

3
x1b2j

cela a fonctionné pour moi:

ssh-keygen -R <server_IP>

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

puis refaire la même chose ssh:

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.

2
Cris

Pour les instances Debian EC2, l'utilisateur est admin.

2
Alastair Irvine

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

voir mon debug et regarder le dernier:

*

ssh -v -i awsliferaysrta.pem.txt [email protected].***
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 [email protected]
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
Hung Do

Il y a 2 étapes pour être connecté:

Cliquez sur Chmod 400 sur votre clé privée, ainsi, les autres ne pourront pas accéder à votre clé:

chmod 400 toto.pem

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

ssh -i toto.pem [email protected]

J'espère que ça aide !

1
GuillaumeAgis

L'autorisation pour ec2-keypair.pem devrait être 400

chmod 400 ec2-keypair.pem

1
Yogesh

Son utilisateur ec2 pour les images Amazon Linux AMI et ubuntu pour les images Ubuntu. De plus, RHEL 6.4 et les versions ultérieures de l'utilisateur ec2, RHEL 6.3 et les versions antérieures de la racine Fedora ec2, utilisateur Centos.

1
Amith Ajith

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

1.- Ouvrez le fichier .pem avec TextWrangler

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

1
pmartinezd

Si vous utilisez EBS, vous pouvez également essayer de monter le volume EBS sur une instance en cours d'exécution. Ensuite, montez-le 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/allowed_keys

1
Rico

Il suffit d'ajouter à cette liste. J'avais des problèmes ce matin avec un nouvel utilisateur ajouté à une instance AWS EC2. Pour aller droit au but, le problème était selinux (qui était en mode respect), ainsi que le fait que mon répertoire d'accueil utilisateur se trouvait sur un nouveau volume attaché EBS. D'une manière ou d'une autre, je suppose que selinux n'aime pas cet autre volume. Il m'a fallu un certain temps pour comprendre, alors que je parcourais tous les autres problèmes ssh habituels (/ etc/ssh/sshd_config allait bien, bien sûr, aucun mot de passe n'est autorisé, les autorisations sont correctes, etc.)

Le correctif?

Pour le moment (jusqu'à ce que je comprenne comment autoriser un utilisateur à utiliser ssh sur un volume différent, ou en quelque sorte, faire de ce volume un point de référence personnel de bonne foi):

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

C'est ça. Maintenant, mon nouvel utilisateur peut se connecter en utilisant sa propre clé id_rsa.

0
Pierre D

Avait 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 à leur droite sur la page du wiki Debian.

J'espère que cela t'aides.

0
Lionel Morrison