Question

Comment se connecter à une instance AWS via ssh?

Je:

  1. Inscrit à AWS;
  2. Création d'une clé publique et un certificat sur le site Web AWS et les sauvegardé sur le disque;
  3. Je suis allé à ma console et a 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. Told API AWS pour utiliser cette paire de clés et enregistré le fichier keypair à:

    $ ec2-add-keypair ec2-keypair > ec2-keypair.pem
    
  5. Démarrage d'une instance AWS Ubuntu 9 en utilisant cette paire de clés:

    $ ec2-run-instances ami-ed46a784 -k ec2-keypair
    
  6. a 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?

Était-ce utile?

La solution

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 les autres cas, vous pourriez avoir à utiliser ec2-user au lieu de ubuntu.

La plupart EC2 images Linux J'ai utilisé seulement que l'utilisateur root créé par défaut.

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

Autres conseils

Maintenant, il est:

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

Les communiqués de Canonical utilisent l'utilisateur « ubuntu » par défaut pour tous ceux qui atterrissant ici avec une image ubuntu qui vient avec le même problème.

Si vous utilisez une image Bitnami, connectez-vous comme 'bitnami'.

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

Pour mes images ubuntu, il est en fait l'utilisateur ubuntu et NON l'EC2 utilisateur;)

Ubuntu 10.04 avec OpenSSH

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

exemple ci-dessus a été prise directement à partir du tutoriel AWS pour se connecter à une machine Linux / UNIX à: http://docs.amazonwebservices.com/AWSEC2/latest/GettingStartedGuide/

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

Je suis également en cours d'exécution dans ce - s'avère que j'utilisais une communauté créée AMI - et le nom d'utilisateur par défaut était la racine niehter, ni n'a été ect-utilisateur ou ubuntu. En fait, je ne savais pas ce qu'il était - jusqu'à ce que j'ai essayé root et le serveur m'a gentiment demandé de vous connecter xxx xxx est tout ce qu'il vous dit.

-cheers!

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 distante ou d'un serveur, vous pouvez obtenir ce à 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 clé privée est au format .pem convertir en .PPK en utilisant puttygen
  • Lancez PuTTY, vous définissez PPK fichier, l'adresse IP ou le nom DNS du serveur distant et démarrez la session ssh

utiliser ...

# chmod 400 ec2-keypair.pem

ne pas utiliser la 600 permission sinon vous risquez de remplacer votre clé par mégarde.

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

faire alors la 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 utilisateur

Je ne devais pas recréer l'instance d'une image.

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

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

L'autorisation de ec2-keypair.pem doit être 400

chmod 400 ec2-keypair.pem

Si vous utilisez l'image de AWS Bitnami. Le nom d'utilisateur serait bitnami. Vive!

voir mon débogage et de 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".

*

Il y a 2 étapes à raccorder:

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 en SSH, vous devez connaître l'adresse IP publique de votre instance:

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

it helps!

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

Ouvrez le fichier 1.- .pem avec TextWrangler

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

Son EC2 utilisateur pour AMI Amazon Linux et de ubuntu pour les images Ubuntu. En outre, RHEL 6.4 et plus tard EC2 utilisateur RHEL 6.3 et versions antérieures racine Fedora EC2 utilisateur racine CentOS

Il suffit d'ajouter à cette liste. J'avais du mal ce matin avec un nouvel utilisateur vient d'ajouter à une instance AWS EC2. Pour couper à la chasse, le problème était SELinux (qui était faire observer le mode ), ainsi que le fait que mon répertoire personnel de l'utilisateur était sur un nouveau EBS le volume attaché. D'une certaine façon, je pense que SELinux n'aime pas cet autre volume. Il m'a fallu un certain temps pour comprendre, comme je l'ai regardé à travers toutes les autres questions ssh habituelles (/ etc / ssh / sshd_config était bien, bien sûr aucun mot de passe permis, les autorisations ont droit, etc.)

Le correctif?

Pour l'instant (jusqu'à ce que je comprends comment permettre à un utilisateur de ssh à un autre volume, ou en quelque sorte faire ce volume une maison de bonne foi point dir):

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

Voilà. Maintenant, mon nouvel utilisateur peut se connecter, en utilisant sa propre clé id_rsa.

eu le même problème. Permission refusée (publickey) lorsque vous essayez de vous connecter avec « EC2 utilisateur » ou « root ».

googlé le nombre AMI de l'image de la machine et il avait droit les informations de connexion SSH leur sur la page wiki Debian.

Hope this helps.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top