2010-04-16 17 views
0

L'authentification auprès de notre instance Ubuntu EC2 a bien fonctionné jusqu'à tout récemment. Tout à coup, la clé est rejetée. Lorsque nous créons une nouvelle instance avec la paire de clés, nous sommes en mesure de nous connecter à l'instance parfaitement, donc cela semble être un problème avec l'instance existante. Le port 22 est ouvert.Clé Amazon EC2 RSA arrêtée d'authentification - Autorisation refusée (clé publique)

Des suggestions sur ce qu'il faut regarder d'un point de vue de la configuration afin que nous puissions résoudre ce problème? Des idées sur comment nous pouvons entrer dans la boîte?

Voici la sortie de débogage SSH. Y a-t-il quelque chose qui ne va pas?

Merci beaucoup!

$ ssh -v -i ~/zzz.pem [email protected]###.###.###.### 
OpenSSH_5.2p1, OpenSSL 0.9.8l 5 Nov 2009 
debug1: Reading configuration data /etc/ssh_config 
debug1: Connecting to ###.###.###.### [###.###.###.###] port 22. 
debug1: Connection established. 
debug1: identity file zzz.pem type -1 
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-6ubuntu2 
debug1: match: OpenSSH_5.1p1 Debian-6ubuntu2 pat OpenSSH* 
debug1: Enabling compatibility mode for protocol 2.0 
debug1: Local version string SSH-2.0-OpenSSH_5.2 
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: Host '###.###.###.###' is known and matches the RSA host key. 
debug1: Found key in /zzz/.ssh/known_hosts:18 
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: Offering public key: /zzz/.ssh/id_rsa 
debug1: Authentications that can continue: publickey 
debug1: Offering public key: zzz.txt 
debug1: Authentications that can continue: publickey 
debug1: Trying private key: zzz.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). 
+0

S'il n'y a pas d'autre utilisateur pour la machine, alors comment nous réparons ce problème? –

+0

J'ai le même problème. Pourriez-vous expliquer plus de détails et spécifier comment résoudre le problème merci beaucoup –

+0

Ceci est une bonne référence sur authorized_keys - http://www.eng.cam.ac.uk/help/jpmg/ssh/authorized_keys_howto .html - nous avons essentiellement trouvé un utilisateur qui avait accès et était capable de réparer le fichier authorized_keys, si je me souviens bien. – shedd

Répondre

1

Nous avons trouvé ce qui n'allait pas ici. Un utilisateur sur la boîte a écrasé la clé principale ~/.ssh/authorized_keys - il a pu se connecter et vérifier ce fichier et y ajouter la clé .pem maître.

+2

L'utilisateur est l'ennemi. Toujours. –