AVERTISSEMENT: FICHIER DE CLÉ PRIVÉE NON PROTÉGÉ! lors de la tentative de SSH dans l'instance Amazon EC2

Question

Je travaille sur la configuration de Panda sur une instance Amazon EC2. J'ai créé mon compte et mes outils la nuit dernière et je n'ai eu aucun problème à utiliser SSH pour interagir avec ma propre instance personnelle, mais pour l'instant, je ne suis pas autorisé à accéder à l'instance EC2 de Panda. Premiers pas avec Panda

Je reçois l'erreur suivante:

@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @

Permissions 0644 for '~/.ec2/id_rsa-gsg-keypair' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.

J'ai modifié ma paire de clés à 600 pour accéder à mon instance personnelle la nuit dernière et j'ai longuement essayé de définir les autorisations à 0 et même de générer de nouvelles chaînes de clé, mais rien ne semble fonctionner.

Toute aide serait une aide précieuse!

Hm, il semble qu'à moins que les autorisations ne soient définies sur le répertoire 777, le script ec2-run-instances ne parvient pas à trouver mes fichiers de clés. Je suis nouveau sur SSH, donc je risque d’ignorer quelque chose.

Answer 1

  

J'ai modifié ma paire de clés à 600 pour entrer dans mon cas personnel la nuit dernière,

Et c'est comme cela que cela est supposé être.

Extrait de la documentation EC2 , nous avons " Si vous utilisez OpenSSH (ou un client SSH raisonnablement paranoïaque), vous devrez probablement définir les autorisations de ce fichier de sorte qu'il ne soit lisible que par vous. " La documentation Panda à laquelle vous associez des liens La documentation d’Amazon ne dit vraiment pas à quel point tout cela est important.

L'idée est que les fichiers de paire de clés sont comme des mots de passe et doivent être protégés. Ainsi, le client ssh que vous utilisez nécessite que ces fichiers soient sécurisés et que seul votre compte puisse les lire.

Définir le répertoire sur 700 devrait suffire, mais 777 ne fera pas de mal tant que les fichiers sont au nombre de 600.

Tous les problèmes que vous rencontrez sont liés au client. Veillez donc à inclure les informations du système d’exploitation local dans les questions suivantes!

Answer 2

Assurez-vous que le répertoire contenant les fichiers de clé privée est défini sur 700

.

chmod 700 ~/.ec2

Answer 3

Pour résoudre ce problème, 1) vous devez réinitialiser les autorisations par défaut:

sudo chmod 600 ~ / .ssh / id_rsa  sudo chmod 600 ~ / .ssh / id_rsa.pub

Si vous obtenez une autre erreur: Êtes-vous sûr de vouloir continuer à vous connecter (oui / non)? Oui Échec de l'ajout de l'hôte à la liste des hôtes connus (/home/geek/.ssh/known_hosts).

2) Cela signifie que les autorisations sur ce fichier sont également définies de manière incorrecte et peuvent être ajustées avec ceci:

sudo chmod 644 ~ / .ssh / connus_hôtes

3) Enfin, vous devrez peut-être également ajuster les autorisations du répertoire:

sudo chmod 755 ~ / .ssh

Cela devrait vous remettre sur pied.

Answer 4

Le fichier de clé privée doit être protégé. Dans mon cas, j’utilise l’authentification public_key depuis longtemps et j’ai l'habitude de définir l'autorisation 600 (rw- --- ---) pour la clé privée et 644 (rw- r-- r--) et pour le dossier .ssh dans le dossier de base, vous aurez l'autorisation 700 (rwx --- ---). Pour le définir, accédez au dossier de base de l'utilisateur et exécutez la commande suivante

Définition de l'autorisation 700 pour le dossier .ssh

chmod 700 .ssh

Définissez l'autorisation 600 sur le fichier de clé privée

.

chmod 600 .ssh/id_rsa

Définition de l'autorisation 644 pour le fichier de clé publique

chmod 644 .ssh/id_rsa.pub

Answer 5

J'ai également le même problème, mais je résous le problème en modifiant l'autorisation d'accès au fichier de clé à 600.

sudo chmod 600 /path/to/my/key.pem

Lien: http://stackabuse.com/how-to-fix-warning-unprotected-private-key-file-on-mac-and-linux/

Answer 6

Sous Windows, essayez d’utiliser git bash et d’utiliser vos commandes Linux. Approche facile

chmod 400 *****.pem

ssh -i "******.pem" ubuntu@ec2-11-111-111-111.us-east-2.compute.amazonaws.com

Answer 7

Conservez votre clé privée, votre clé publique et vos éléments connus dans le même répertoire et essayez de vous connecter comme ci-dessous:

ssh -I(small i) "hi.pem" ec2-user@ec2-**-***-**-***.us-west-2.compute.amazonaws.com

• Même répertoire dans le sens, cd / Users / prince / Desktop . Maintenant, tapez la commande ls et vous devriez voir **. pem **. ppk known_hosts

Remarque: vous devez essayer de vous connecter à partir du même répertoire ou vous obtiendrez une erreur d'autorisation refusée car il ne trouvera pas le fichier .pem dans votre répertoire actuel.

Si vous voulez pouvoir utiliser SSH depuis n’importe quel répertoire, vous pouvez ajouter ce qui suit: ~ / .ssh / config fichier ...

Host your.server
HostName ec2-user@ec2-**-***-**-***.us-west-2.compute.amazonaws.com
User ec2-user
IdentityFile ~/.ec2/id_rsa-gsg-keypair
IdentitiesOnly yes

Vous pouvez maintenant utiliser SSH sur votre serveur, quel que soit l'emplacement du répertoire, en tapant simplement ssh votre.serveur (ou le nom que vous donnez après "Host").

Answer 8

Je pense à autre chose. Si vous essayez de vous connecter avec un nom d'utilisateur différent qui n'existe pas, c'est le message que vous recevrez.

Donc, je suppose que vous essayez peut-être de ssh avec ec2-user mais je me souviens récemment que la plupart des AMI centos utilisent par exemple centos user au lieu de ec2-user

donc si vous êtes ssh -i fichier.pem centos @ public_IP , dites-moi que vous êtes en train de récupérer ssh avec le bon nom d'utilisateur, sinon cela peut être une bonne raison de voir un tel message d'erreur même avec les bonnes autorisations sur votre ~ / .ssh / id_rsa ou file.pem

Answer 9

Juste un mot pour quiconque trébuche sur ceci:

Si vous essayez de SSH avec une clé partagée avec vous, par exemple:

ssh -i /path/to/keyfile.pem utilisateur @ un-hôte

Où keyfile.pem est la clé privée / publique partagée avec vous et que vous utilisez pour vous connecter, assurez-vous de l'enregistrer dans ~ / .ssh / et chmod 777 .

Essayer d’utiliser le fichier alors qu’il était sauvegardé ailleurs sur ma machine donnait l’erreur du PO. Pas sûr que ce soit directement lié.