AVERTISSEMENT: NON PROTÉGÉE DU FICHIER DE CLÉ PRIVÉE! lorsque vous essayez de SSH en Instance Amazon EC2

J'ai chmodé ma paire de clés à 600 pour rentrer dans mon exemple la nuit dernière,

Et ce est la façon dont il est censé être.

De la EC2 documentation nous avons "Si vous êtes à l'utilisation d'OpenSSH (ou de tout raisonnablement paranoïaque client SSH), alors vous aurez probablement besoin de définir les permissions de ce fichier afin qu'il ne soit lisible que par vous." Le Panda de la documentation que vous lier des liens vers Amazon de la documentation, mais n'a pas vraiment d'exprimer comment important c'est.

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

Paramètre le répertoire de 700 vraiment devrait être suffisant, mais 777 n'est pas te faire de mal, tant que les dossiers sont de 600.

Tous les problèmes que vous rencontrez sont côté client, donc assurez-vous d'inclure les informations OS avec un suivi des questions!

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

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

Si vous obtenez un autre message d'erreur:
Êtes-vous sûr de vouloir continuer à 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 permissions sur ce fichier sont également définies de manière incorrecte, et peut être ajusté avec ce:

sudo chmod 644 ~/.ssh/known_hosts

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

sudo chmod 755 ~/.ssh

Cela devrait vous remettre en place et en cours d'exécution.

J'ai aussi eu le même problème, mais je résoudre ce problème en modifiant mon fichier de clé d'autorisation de 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/

Sur windows, Essayez d'utiliser git bash et l'utilisation de vos commandes Linux là. Facile d'approche

chmod 400 *****.pem

ssh -i "******.pem" [email protected]

Juste une note pour toute personne qui tombe sur ceci:

Si vous essayez de faire du SSH avec une clé qui a été partagé avec vous, par exemple:

ssh -i /path/to/keyfile.pem user@some-host

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

D'essayer de les utiliser lorsque le fichier a été enregistré ailleurs sur ma machine était de donner l'OP de l'erreur. Vous ne savez pas si elle est directement liée.

La solution est de le rendre lisible uniquement par le propriétaire du fichier, c'est à dire les deux derniers chiffres de l'octal mode de représentation doit être égal à zéro (par exemple le mode 0400).

OpenSSH vérifie ce dans authfile.c, dans une fonction nommée sshkey_perm_ok:

/*
 * if a key owned by the user is accessed, then we check the
 * permissions of the file. if the key owned by a different user,
 * then we don't care.
 */
if ((st.st_uid == getuid()) && (st.st_mode & 077) != 0) {
    error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
    error("@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @");
    error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
    error("Permissions 0%3.3o for '%s' are too open.",
        (u_int)st.st_mode & 0777, filename);
    error("It is required that your private key files are NOT accessible by others.");
    error("This private key will be ignored.");
    return SSH_ERR_KEY_BAD_PERMISSIONS;
}

Voir la première ligne après le commentaire: il fait un "bit à bit et" contre le mode du fichier, en sélectionnant tous les bits dans les deux dernières octale (depuis 07 est octal pour 0b111, où chaque bit représente r/w/x, respectivement).