Problème D'accès AWS SSH 'Autorisation refusée (publickey)' [fermé]

Maintenant, c'est:

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

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

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

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

Pour mes images ubuntu, c'est en fait l'utilisateur ubuntu et non l'ec2-user;)

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 ec2-user@ec2-184-72-204-112.compute-1.amazonaws.com

L'exemple ci-dessus a été pris directement à partir du tutoriel AWS pour la connexion à une machine Linux/UNIX à: http://docs.amazonwebservices.com/AWSEC2/latest/GettingStartedGuide/

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

Je courais aussi dans ce-il s'avère que j'utilisais un AMI créé par la communauté - et le nom d'utilisateur par défaut était niehter root, ni ect-user ou ubuntu. En fait, je n'avais aucune idée de ce que c'était - jusqu'j'ai essayé 'racine " et le serveur a gentiment demandé de me connecter en tant que xxx où xxx est ce qu'il vous raconte.

-bravo!

Utilisation...

# chmod 400 ec2-keypair.pem

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

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

• Utilisez PuTTy pour créer la session ssh ( http://the.earth.li/~sgtatham/putty/latest/x86/putty-0.66-installer.exe )
• Si votre fichier de clé privée est dans .format PEM convertir en .ppk en utilisant puttygen
• Lancez PuTTy, définissez le fichier ppk, l'adresse IP ou le nom DNS du serveur distant et démarrez la session ssh

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

Ensuite, en faisant le même ssh à nouveau, 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.

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

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

Voir mon Débogage et regarder 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".

*

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

1.- Ouvrez le .fichier pem avec TextWrangler

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

Son ec2-utilisateur pour Amazon Linux AMI et ubuntu pour les images Ubuntu. En outre, RHEL 6.4 et plus tard ec2-utilisateur RHEL 6.3 et racine antérieure Fedora ec2-utilisateur Racine Centos

Juste ajouter à cette liste. J'avais des problèmes ce matin avec un nouvel utilisateur vient d'être ajouté à une instance AWS EC2. Pour aller droit au but, le problème était selinux (qui était en modeenforcing ), ainsi que le fait que mon répertoire d'utilisateur é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 du temps pour comprendre, car j'ai regardé à travers tous les autres problèmes habituels de ssh (/etc/ssh/sshd_config était bien, bien sûr aucun mot de passe autorisé, les autorisations étaient correctes, etc.)

Le correctif?

Pour l'instant (jusqu'à ce que je comprenne comment permettre à un utilisateur de ssh à un volume différent, ou en quelque sorte faire de ce volume un point de dir maison 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.

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 droit leur sur la page Wiki Debian.

J'espère que cela aide.

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 / authorized_keys

Autorisation pour ec2-keypair.pem devrait être 400

chmod 400 ec2-keypair.pem

Il y a 2 étapes à connecter:

Chmod 400 sur votre clé privée, comme ceci les autres ne peuvent 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 ec2-user@XX.XX.XX.XXX

J'espère que ça aide !