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


190

Je travaille à configurer Panda sur une instance Amazon EC2. J'ai configuré 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 le moment, je n'ai pas l'autorisation d'accéder à l'instance EC2 de Panda. Premiers pas avec Panda

J'obtiens 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 chmodé ma paire de clés à 600 afin d'entrer dans mon instance personnelle la nuit dernière, et j'ai longuement expérimenté en définissant les autorisations sur 0 et même en générant de nouvelles chaînes de clés, mais rien ne semble fonctionner.

N'importe quelle aide serait d'une grande aide!


Hm, il semble que si les permissions ne sont pas définies sur 777 sur le répertoire, le script ec2-run-instances est incapable de trouver mes fichiers de clés. Je suis nouveau sur SSH donc je pourrais oublier quelque chose.


Les instances ec2-run-instances ne devraient nécessiter qu'un nom de paire de clés, ce qui vit du côté d'Amazon. Vous ne devriez utiliser votre clé privée réelle (celle sur le disque) que lorsque vous vous connectez en SSH. Quelle erreur obtenez-vous des instances ec2-run-instances?
user27619

3
titre terrible pour cette question.
MikeNereson

2
@MikeNereson: n'hésitez pas à le modifier, c'est ainsi que nous améliorons les choses ici
Stu Thompson

Êtes-vous sûr de l'avoir réglé sur 0600 (octal) et non sur 600 (décimal)?
hyde

5
chmod 400 ~/.ssh/id_rsa Référence: stackoverflow.com/a/9270753/2082569
atulkhatri

Réponses:


210

J'ai chmodé ma paire de clés sur 600 pour accéder à mon instance personnelle la nuit dernière,

Et c'est ainsi que cela est censé être.

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

L'idée est que les fichiers de paires 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 vraiment suffire, mais 777 ne fera pas de mal tant que les fichiers sont 600.

Tous les problèmes que vous rencontrez sont du côté du client, alors assurez-vous d'inclure les informations du système d'exploitation local avec toutes les questions de suivi!


3
Je viens de me retrouver dans une situation aujourd'hui où JE VEUX que le fichier de clés soit lisible par groupe (en utilisant ssh non pas pour la connexion personnelle, mais pour exécuter un script sur un serveur distant, utilisateur dédié sur le serveur distant à cette fin, les clés_autorisées verrouillées donc seulement ledit script s'exécutera et plusieurs personnes sur le serveur d'origine devraient avoir accès pour exécuter le script). Eh bien, je suppose que la solution de contournement simple est de mettre des copies dans ~ / .ssh / pour tous les utilisateurs qui devraient y avoir accès - ou de remplir authorized_keys avec toutes les clés personnelles.
tobixen

@tobixen: Deux ans à venir, mais ... la solution de contournement «correcte» serait de placer la clé dans un utilisateur dédié et d'autoriser les utilisateurs du groupe sudo à exécuter cette commande en tant qu'utilisateur dédié.
Stu Thompson

Le lien @StuThompson vers la documentation EC2 semble être mort. Pouvez-vous s'il vous plaît mettre à jour?
Aniket Thakur

Je ne vois pas ce que je dois faire pour que cela fonctionne dans votre réponse, veuillez fournir une réponse :)
Pratik

@Pratik définissant 600 pour les deux fichiers clés et 777 pour le répertoire devrait fonctionner.
Jamo le

55

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

chmod 700 ~/.ec2

Une raison particulière pour laquelle vous souhaitez avoir des privilèges d'exécution sur le fichier?
Zoltán

1
@ Zoltán c'est un répertoire, pas un fichier.
avmohan

Je viens de l'utiliser sur le fichier .pem et cela a fonctionné pour moi.
CGTheLegend

30

Pour résoudre ce problème, 1) vous devrez 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/known_hosts

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

sudo chmod 755 ~/.ssh

Cela devrait vous remettre en marche.


17

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


Définissez l' autorisation 700 pour le dossier .ssh

chmod 700 .ssh


Définir l' autorisation 600 pour le fichier de clé privée

chmod 600 .ssh/id_rsa


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

chmod 644 .ssh/id_rsa.pub


2

Gardez votre clé privée, clé publique, known_hosts 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 lscommande 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 trouve pas le fichier .pem dans votre répertoire actuel.


Si vous voulez pouvoir SSH à partir de n'importe quel répertoire, vous pouvez ajouter ce qui suit à votre ~/.ssh/configfichier ...

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

Maintenant, vous pouvez SSH sur votre serveur quel que soit l'endroit où se trouve le répertoire en tapant simplement ssh your.server(ou quel que soit le nom que vous placez après "Host").


1

Sous Windows, essayez d'utiliser git bash et utilisez vos commandes Linux là-bas. Approche facile

chmod 400 *****.pem

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

Si vous utilisez WSL, assurez-vous de copier le fichier pem dans un dossier Linux car chmod ne sera pas efficace dans les répertoires / mnt.
Paulo Merson le

1

Modifier l'autorisation de fichier à l'aide de la commande chmod

sudo chmod 700 keyfile.pem

0

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, par exemple, utilisent centos user au lieu d'ec2-user

donc si vous êtes s'il vous ssh -i file.pem centos@public_IPplaît dites-moi que vous essayez de ssh avec le bon nom d'utilisateur, sinon cela peut être une bonne raison pour laquelle vous voyez un tel message d'erreur même avec les bonnes autorisations sur votre ~ / .ssh / id_rsa ou file.pem


0

Juste une note pour tous ceux qui trébuchent sur ceci:

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

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

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

Essayer d'utiliser le fichier lorsqu'il a été enregistré ailleurs sur ma machine donnait l'erreur de l'OP. Je ne sais pas si c'est directement lié.


0

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

OpenSSH le vérifie authfile.cdans 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 "bitwise et" contre le mode du fichier, en sélectionnant tous les bits dans les deux derniers chiffres octaux (puisque 07est octal pour 0b111, où chaque bit représente r / w / x, respectivement) .

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.