Frage

Wie man eine AWS-Instanz über ssh verbinden?

ich habe:

  1. bei AWS Angemeldete;
  2. einen öffentlichen Schlüssel und ein Zertifikat auf AWS-Website erstellt und gespeichert sie auf der Festplatte;
  3. Wir gingen zu meiner Konsole und erstellt Umgebungsvariablen:

    $ 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 AWS API dieses Schlüsselpaar zu verwenden, und rettete die Schlüsselpaar-Datei:

    $ ec2-add-keypair ec2-keypair > ec2-keypair.pem
    
  5. eine AWS Ubuntu 9-Instanz mit dieser Keypair gestartet:

    $ ec2-run-instances ami-ed46a784 -k ec2-keypair
    
  6. Versuchte eine SSH-Verbindung zu der Instanz herzustellen:

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

    Was das Problem sein könnte und wie es funktioniert?

War es hilfreich?

Lösung

Für Ubuntu-Instanzen:

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

Für andere Instanzen, die Sie haben könnten ec2-user verwenden, anstatt ubuntu.

Die meisten EC2 Linux Bilder, die ich verwendet habe, nur die Root-Benutzer standardmäßig erstellt haben.

Siehe auch: http://www.youtube.com/watch?v=WBro0TEAd7g

Andere Tipps

Jetzt ist es:

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

Canonical Releases verwenden, um den Benutzer-ubuntu "standardmäßig für alle, hier mit einem ubuntu Bild Landung, die mit dem gleichen Problem aufkommt.

Wenn Sie ein Bitnami Bild verwenden, melden Sie sich als 'bitnami'.

Es scheint offensichtlich, aber etwas, das ich übersehen.

Für meine ubuntu Bilder, es ist eigentlich ubuntu Benutzer und NICHT der EC2-Benutzer;)

Ubuntu 10.04 mit openSSH

Dies ist die genaue Nutzung:

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

Beispiel:

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

obiges Beispiel wurde für den Anschluss an einen Linux / UNIX-Maschine direkt von dem AWS Tutorial genommen: http://docs.amazonwebservices.com/AWSEC2/latest/GettingStartedGuide/

Es wird auch beschweren, wenn die pem Dateiberechtigungen zu offen sind. chmod die Datei auf 600 bis das in Ordnung bringen.

Ich war auch in diesem Lauf - stellt sich heraus, ich war ein Community erstellte AMI mit - und der Standard-Benutzername war niehter Wurzel, noch war es ect-Benutzer oder ubuntu. In der Tat hatte ich keine Ahnung, was es war - bis ich versuchte, ' root ' und der Kellner fragte mich freundlich wie xxx Loogt xxx ist, was es sagt.

-cheers!

Sie müssen Ihre privaten Schlüssel in Ihrem lokalen Rechner haben

Sie müssen die IP-Adresse oder den DNS-Namen des Remote-Computer oder Server kennen, können Sie diese von AWS-Konsole erhalten

Wenn Sie ein Linux-Benutzer

  • Stellen Sie sicher, dass die Berechtigungen für den privaten Schlüssel sind 600 (chmod 600 <path to private key file>)
  • eine Verbindung zu Ihrer Maschine mit ssh (ssh -i <path to private key file> <user>@<IP address or DNS name of remote server>)

Wenn Sie ein Windows-Benutzer

Verwendung ...

# chmod 400 ec2-keypair.pem

verwenden Sie nicht die 600 Erlaubnis sonst könnten Sie Ihren Schlüssel versehentlich überschrieben werden.

Dies ist für mich:

ssh-keygen -R <server_IP>

die alten Tasten auf der Workstation gespeichert löschen funktioniert auch mit anstelle von

dann tut das gleiche ssh wieder es hat funktioniert:

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

auf ubuntu Instanzen der Benutzername ist: ubuntu Bei Amazon Linux AMI ist der Benutzername: EC2-user

Ich hatte nicht die Instanz von einem Bild neu zu erstellen.

Für Debian EC2-Instanzen, der Benutzer admin.

Wenn Sie EBS verwenden, können Sie auch versuchen, die EBS Volume auf einer laufenden Instanz zu montieren. Dann befestigen Sie ihn auf dieser laufenden Instanz und sehen, was in / home vor sich geht. Sie können Dinge sehen, wie die ubuntu Benutzer oder EC2-Benutzer? oder hat es die richtigen öffentlichen Schlüssel unter ~ / .ssh / authorized_keys

Die Erlaubnis für ec2-keypair.pem werden 400 sollte

chmod 400 ec2-keypair.pem

Wenn Sie AWS Bild von Bitnami ausgeführt werden. Der Benutzername wäre bitnami. Cheers!

meine Debug sehen und Blick auf die zuletzt:

*

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

*

Es gibt zwei Schritte verbunden werden:

chmod 400 auf Ihrem privaten Schlüssel, wie dies die anderen können nicht auf Ihren Schlüssel zugreifen:

chmod 400 toto.pem

zu Ihrer Instanz in SSH verbinden, müssen Sie die öffentliche IP-Adresse Ihrer Instanz wissen:

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

Hoffe, es hilft!

In meinem Fall (Mac OS X), war das Problem der Pause Typ der Datei. Versuchen Sie folgendes:

1.- die .pem-Datei mit TextWrangler Öffnen

2, im unteren Bereich der App überprüfen, ob die Pause Typ ist „Windows (CRLF)“.

Die EC2-Nutzer für Amazon Linux AMI und ubuntu für Ubuntu Bilder. Auch RHEL 6.4 und später EC2-User RHEL 6.3 und frühere Wurzel Fedora EC2-user Centos root

Hinzufügen Gerade zu dieser Liste. Ich war heute Morgen Probleme, mit einem neuen Benutzer nur zu einer AWS EC2-Instanz hinzugefügt. Um auf den Punkt, das Problem war, selinux (was in war Erzwingen Modus), zusammen mit der Tatsache, dass mein Benutzer Hauptdir auf einem neuen EBS war Volumen angebracht. Irgendwie denke ich selinux nicht, dass andere Band mag. Dauerte eine Weile, um herauszufinden, wie ich durch all die anderen üblichen ssh Probleme sah (/ etc / ssh / sshd_config war in Ordnung, natürlich kein Passwort erlaubt, Berechtigungen hatten Recht, etc.)

Das Update?

Für jetzt (bis ich verstehe, wie ein Benutzer zu ermöglichen, zu einem anderen Volumen ssh oder irgendwie, dass Volumen einen bona fide dir Punkt nach Hause machen):

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

Das ist es. Jetzt kann mein neuer Benutzer anmelden, seine eigene id_rsa-Taste.

das gleiche Problem hat. Zugriff verweigert (publickey) bei dem Versuch, mit ‚EC2-Benutzer‘ oder mit ‚root‘ angemeldet sein.

die AMI-Nummer der Maschine Bild gegoogelt und es hatte die SSH-Login-Informationen Recht, ihr auf der Debian-Wiki-Seite.

Hope, das hilft.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top