Gérer les clés SSH

FreeIPA fait la gestion des clés SSH assez bien. Je l'utilise avec succès à la maison mais de nombreuses entreprises l'utilisent en production (la liste de diffusion freeipa-users est hyper-active). C'est le projet de logiciel libre en amont sur lequel est basée la solution de gestion d'identité de Red Hat. Il y a également des développeurs de Red Hat qui modèrent et aident sur la liste de diffusion freeipa-users.

Il s'agit en fait d'un service de type Active Directory pour les environnements Unix/Linux. Il peut également se synchroniser avec AD. Il dispose de fonctionnalités natives *nix comme les montages automatiques NFS, les politiques sudo centralisées, etc.

Chaque utilisateur peut ajouter sa clé SSH à son profil FreeIPA. Ensuite, sshd peut être configuré pour utiliser une commande AuthorizedKeysCommand fournie par le paquetage sssd qui sera configurée pour interroger le serveur FreeIPA. Combiné avec les politiques sudo, vous obtenez une escalade de privilèges. et audit (qui a sudo'ed).

Comme il s'agit d'un projet RedHat, il est facile de l'installer sur Fedora ou CentOS, mais j'ai réussi à installer et configurer des boîtes debian comme clients FreeIPA. J'installe cependant le serveur d'authentification sur un serveur Fedora, qui est sa plateforme native.

http://www.freeipa.org/page/Main_Page

Le problème que je vois en utilisant la même clé SSH partout est le manque de responsabilité.

Je préférerais que chaque utilisateur dispose de sa ou ses propres clés SSH et utilise un système d'authentification et d'autorisation centralisé.

De cette façon, les clés publiques ne doivent même pas être distribuées aux systèmes cibles, et peuvent être stockées dans un service d'annuaire central comme FreeIPA .

Outre la responsabilisation, vous avez également la possibilité de définir des politiques de contrôle d'accès à base de rôles (RBAC) très précises.

Pour 2500 hôtes, vous disposez peut-être déjà d'un système de gestion de la configuration, mais vous pourriez utiliser SaltStack si vous ne le faites pas. Nous avons ceci pour l'authentification de la racine :

user1auth:
  ssh_auth:
    - present
    - user: root
    - source: salt://resources/ssh_keys/user1

user2auth:
  ssh_auth:
    - present
    - user: root
    - source: salt://resources/ssh_keys/user2

Vous n'avez pas besoin d'avoir la clé privée sur l'hôte de saut. Utilisez simplement le transfert d'agent lorsque vous vous connectez : ssh -A root@host .

Il existe également d'autres systèmes (Pupet, cfengine, par exemple).

La plupart des cadres de sécurité (c'est-à-dire HIPAA, PCI, etc.) requièrent une clé par utilisateur humain . Les utilisateurs doivent jamais ne partagent pas plus les clés qu'ils ne partageraient les mots de passe.

Chaque utilisateur humain a besoin de son propre compte, et ces comptes doivent pouvoir être supprimés sur tous les serveurs de l'entreprise lorsque les utilisateurs passent à d'autres projets. C'est une tâche qui mérite d'être automatisée !

Je travaille pour Userify, qui gère les clés pour vous à travers vos équipes et tous vos serveurs et peut même s'interfacer avec Active Directory (Userify Enterprise), mais il existe également d'autres options, comme SSH Universal Key Manager.

Votre choix doit dépendre de vos besoins et de votre budget, ainsi que des caractéristiques que vous jugez importantes.

Par exemple, de nombreux systèmes centralisés sont tellement centralisés que vous pourriez ne pas être en mesure de vous connecter à l'un de vos serveurs, si, par exemple, votre serveur LDAP est en panne. (Userify continuera à fonctionner correctement même si AD ou LDAP est en panne, car les couches de cryptographie à clé publique s'étendent jusqu'au serveur final).

Il est important de pouvoir gérer vos autorisations SSH de manière centralisée, tout en décentralisant l'opération réelle pour une plus grande fiabilité et un meilleur contrôle.

Voir aussi ce sujet de Slant : https://www.slant.co/topics/8010/~gestionnaires-pour-les-clefs-de-sécurité

Copier la clé publique sur tous les serveurs auxquels vous vous connectez est généralement la façon dont les choses se passent avec SSH. Si vous avez créé une clé privée/publique sur le serveur jumpstart et copié la clé publique sur tous les serveurs auxquels vous vous connectez, vous pouvez le faire. public pour ~/.ssh/authorized_keys sur l'hôte auquel vous voulez vous connecter par ssh, c'est (en partie) la manière acceptée de sécuriser une connexion à distance via ssh. D'autres éléments à prendre en compte pour sécuriser davantage ssh sont les suivants :

• changement /etc/ssh/sshd_config et mettre PasswordAuthentication No y PubkeyAuthentication yes
• changement LogLevel en /etc/ssh/sshd_config a VERBOSE et ensuite surveiller /var/log/auth.log pour les anomalies.
• エディット /etc/security/access.conf pour n'autoriser que les connexions d'utilisateurs provenant de certaines IP
• エディット /etc/pam.d/login et mettre account required pam_access.so pour activer les modifications que vous avez apportées à access.conf

Déployer une "clé différente pour chaque serveur" semble signifier que vous voulez une clé différente pour chaque serveur. public dans le ~/.ssh/authorized_keys sur chaque serveur. La raison de ce choix n'est pas claire pour moi mais si vous devez le faire, je créerais un fichier texte sur le serveur Jumpstart avec un hôte sur chaque ligne. Utilisez un for boucle pour analyser le fichier et exécuter ssh-keygen -f $line_from_file pour créer une paire de clés pour chaque hôte. Vous pouvez également utiliser la même for boucle pour ssh dans chaque hôte et ajouter la pubkey à ~/.ssh/authorized_keys en utilisant sed -i ou quelque chose comme ça.