EC2: plusieurs clés ssh pour une instance?

Est-il possible de créer plusieurs clés privées pour SSH dans une instance EC2? Quelle est la meilleure pratique générale pour cela? Nous avons plusieurs utilisateurs qui ont besoin de SSH dans les serveurs et la distribution d'une clé ne fonctionne tout simplement pas bien. Cela ne nous permet pas d'empêcher les utilisateurs de pouvoir se connecter à SSH sur le serveur, sauf si nous modifions la clé et la redistribuons.

Absolument; vous placez simplement toutes les clés publiques pertinentes dans l'image et vous devriez avoir raison. Je préfère utiliser un système de gestion de configuration pour gérer les clés SSH; de cette façon, il est assez trivial de révoquer l'accès d'un utilisateur même sur des systèmes en cours d'exécution. Il y a aussi beaucoup plus ... disons "imaginatifs" ... des façons de gérer cela, comme le stockage de toutes vos clés SSH dans LDAP, qui centralisent les clés SSH comme toute autre information d'identification.

Vous pouvez également utiliser des mécanismes ssh standard. La meilleure approche serait que l'utilisateur s'exécute sur sa machine ssh-keygenpour générer sa paire de clés. Ensuite, ils vous envoient ~/.ssh/id_rsa.pub(ou id_dsa.pub, selon l'algorithme choisi) et vous ajoutez son contenu à l' .ssh/authorized_keyshôte de destination dans le répertoire personnel du compte utilisateur auquel ils devraient pouvoir accéder. Il peut y avoir plusieurs clés dans le fichier. Un par ligne. Et c'est tout! La même clé publique (id_rsa.pub) peut être utilisée sur n'importe quel nombre d'hôtes - elle identifiera toujours l'utilisateur.

Vous pouvez également procéder autrement - vous exécutez ssh-keygen et postez ~ / .ssh / id_rsa (ou id_dsa) à l'utilisateur. Et l'utilisateur enregistre le fichier dans ~ / .ssh / id_rsa. Il suffit de se rappeler de changer les autorisations en 600 (-rw -------) de ce fichier, sinon ssh ne l'acceptera pas. C'est évidemment moins sûr, car la clé privée est probablement distribuée par e-mail.

Cela peut également être fait dans PuTTY avec PuTTYgen.

Un moyen plus simple est indiqué ci-dessous.

Pour les utilisateurs Linux / Mac:

1. Pour créer des clés publiques et privées, utilisez la commande suivante: $ ssh-keygen -t rsa -b 4096

2. Téléchargez la clé publique dans un dossier de votre compartiment S3. Par exemple: S3> MyBucket> Keypair

3. Enregistrez et sécurisez votre clé privée.

Pour les utilisateurs de Windows:

1. Utilisez puttygen pour générer les clés.
2. Suivez DigitalOcean pour créer des clés SSH.
3. Téléchargez la clé publique sur S3> MyBucket> Keypair
4. Enregistrez et sécurisez votre clé privée.

Les étapes suivantes sont importantes lors du lancement de toute AMI Linux.

1. Assurez-vous que le rôle IAM a un rôle créé avec la stratégie AmazonS3FullAccess. Cela permet à l'instance d'assumer un rôle pour accéder aux compartiments S3. Cela est nécessaire pour lire les clés publiques de S3 et les copier dans le profil utilisateur

2. Ajoutez le code suivant sous la section user-data dans Configurer les détails de l'instance> Détails avancés (sous forme de texte):

   #!/bin/bash
   usermod user 1
   usermod -aG wheel user1
   mkdir /home/user1/.ssh/
   aws s3 cp s3://MyBucket    /Keypair/user1-pub.pub /home/user1/.ssh/authorized_keys
   
   useradd user2
   usermod -aG wheel user2
   mkdir /home/user2/.ssh/
   aws s3 cp s3://MyBucket   /Keypair/user2-pub.pub /home/user2/.ssh/authorized_keys
   
   sudo -i 
   echo “user1 ALL=(ALL) NOPASSWD:ALL” >> /etc/sudoers
   echo “user2 ALL=(ALL) NOPASSWD:ALL” >> /etc/sudoers
   
   yum update -y
   

Cette configuration crée User1 et User2 et les ajoute aux utilisateurs sudo . La commande aws s3 cp copie les clés publiques des utilisateurs du dossier S3 vers leur .ssh/authorized_keys path. La dernière section consiste à exécuter des commandes en tant qu'administrateur sans avoir besoin de mots de passe.

De nombreuses améliorations de sécurité peuvent être recommandées ici. Bien que cela ne soit pas explicitement utilisé dans cet exemple, limiter l'accès au compartiment S3 à un compartiment spécifique et connaître les implications de sécurité de la désactivation de l'utilisation des mots de passe dans sudo, sont quelques éléments qui peuvent être mis en évidence. Utilisez-les judicieusement en fonction de vos besoins particuliers.