Un emplacement central pour les clés autorisées est-il une bonne idée?

Je suis en train de configurer un serveur cloud pour exécuter la pile suivante: Ruby, Passenger, Apache; sous Ubuntu 10.04 (Lucid Lynx).

Dans le processus de vouloir rendre le serveur plus facile à gérer, j'installe les clés RSA root, et www-datapour pouvoir sshaccéder au serveur. La chose que je n'ai pas aimé que www-dataest .sshassis répertoire dans /var/wwwlequel est la configuration de répertoire par défaut apache. Mon inquiétude est que si apache n'est pas configuré correctement, le .sshrépertoire peut être exposé.

Je suis tombé sur la solution pour déplacer le ~/.ssh/authorized_keysfichier dans un emplacement central en changeant AuthorizedKeysFiledans /etc/ssh/sshd_config. Cela vient avec 2 avantages: un emplacement unique pour les clés, et ne pas avoir à se soucier d'une mauvaise configuration apache. Le seul inconvénient auquel je peux penser est que maintenant chaque utilisateur est disponible pour se connecter sur le serveur (clairement une épée à double tranchant du fichier de clé centrale.)

Y a-t-il quelque chose que j'ai manqué dans cette configuration? Me suis-je surexposé ou est-ce une meilleure solution que des authorized_keysfichiers individuels ?

Je suis vert en ce qui concerne la gestion des serveurs, mais je suis totalement prêt à être qualifié de mauvais noms pour avoir fait de mauvaises choses. :RÉ

— Gavin Miller
source

Au moins, les clés publiques exposées (en lecture seule) sur Internet ne sont pas le plus grand risque ... (Cela pourrait permettre aux attaquants de voir s'ils peuvent se connecter au serveur avec une clé privée qu'ils ont obtenue ailleurs, mais cela ne ne leur permettez pas de vous connecter simplement en obtenant cela ...) (Les problèmes sérieux sont s'il y a un id_rsafichier ~/.sshet qu'ils parviennent à le lire)

— Gert van den Berg

Réponses:

Tous les fichiers de clés peuvent être centralisés dans le même répertoire et ne pas être mélangés dans le même fichier.

Configurez simplement le sshd_configfichier comme ceci:

AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

Sur votre serveur:

les clés www-data seront en /etc/ssh/authorized_keys/www-data
les clés racine seront en /etc/ssh/authorized_keys/root

Concernant les droits d'accès, ces paramètres sont acceptés par sshd:

/etc/ssh/authorized_keysappartient au root:rootmode 755 et possède le mode 755. Les fichiers de clés appartiennent au root:rootmode 644 et ont ce mode.

D'autres modes peuvent fonctionner mais je ne les ai pas testés.

— mahn
source

+1, mais je ne mettrais pas les autres bits. Attribuez à l'utilisateur la propriété des fichiers% u afin que cela ne soit pas nécessaire.

— Aaron Copley

Bonne solution au problème que les utilisateurs malveillants peuvent ajouter plus de clés publiques à leurs ~ / .ssh / authorized_keys accordant l'accès à d'autres.

— bbaassssiiee

Je viens de confirmer que le mode 600 pour le fichier de clés autorisées d'un utilisateur ne fonctionne pas; il doit être en mode 644

— Luis E.

@bbaassssiiee Cela ne résout absolument pas ce problème. Ils peuvent simplement partager leur clé privée avec qui ils veulent donner accès (cette possibilité peut être atténuée bien sûr, mais cette réponse ne fait absolument

— rien

@DylanYoung J'admets que le partage de clés privées est possible. Mais avec chattr, je peux révoquer l'accès en écriture aux fichiers authorized_keys afin de pouvoir les distribuer exclusivement, en protégeant également une seule ligne dans chaque fichier.

— bbaassssiiee

D'une manière générale, je ne ferais pas ce que vous proposez. Il casse les hypothèses courantes (comme ~/.ssh/authorized_keystravailler pour vos utilisateurs et introduit des problèmes que vous avez déjà mentionnés dans votre question. Si vous voyez des problèmes évidents avant la mise en œuvre, cela signifie que votre solution n'est pas idéale.

En ce qui concerne la sécurité, je pense également que c'est une TERRIBLE idée que tout le monde partage un compte de service: en ce moment, c'est juste vous, et vous savez que c'est vous qui apportez des changements. Dans 5 ans, lorsque vous aurez 5 administrateurs, vous voudrez savoir qui a changé quoi et fouiller dans les journaux d'audit pour voir qui a utilisé quelle clé quand est une douleur royale.
Il vaut mieux que les gens se connectent en tant qu'eux-mêmes et utilisent sudoquelque chose de similaire pour augmenter leurs privilèges et faire tout ce qu'ils doivent faire.

Si vous souhaitez toujours centraliser les clés SSH, je suggère de rechercher un système de déploiement comme Puppet ou radmind pour gérer / distribuer les authorized_keysfichiers dans les ~user/.ssh/répertoires appropriés (ou pirater une solution maison qui les SCP en place).
Lorsque vous développez sur plusieurs serveurs, vous souhaiterez peut-être rechercher le correctif de clé publique LDAP pour les anciennes versions d'OpenSSH (ou la AuthorizedKeysCommanddirective et un script approprié dans la nouvelle version d'OpenSSH) afin de pouvoir centraliser vos utilisateurs et ne pas avoir à distribuer leurs clés sur tout votre réseau, mais cela risque d'être assez loin pour vous.

— voretaq7
source

+1 pour l'argument de partage. Bref car il m'a fallu un moment pour comprendre son implication: il ne devrait pas y avoir de répertoire ~ www-data / .ssh du tout, donc pas de risque de sécurité pour le navigateur web.

— 2011

Merci pour les commentaires! Si je vous comprends bien. Je ne devrais ni avoir rootni www-dataaccessible via une clé ssh est-ce correct?

— Gavin Miller,

Avoir un ~www-data/.sshrépertoire n'est pas une chose terrible (avec les autorisations appropriées, ce n'est pas un risque substantiel), mais si vous allez l'utiliser, ~www-data/.sshil est probablement préférable de ne pas avoir votre racine Web ~www-data(déplacez le Webroot ou déplacez le répertoire personnel de Déplacer www-data). La différenciation des utilisateurs est le plus grand argument à mon humble avis - je sais que si je vois la jsmithconnexion, je sais que c'est John Smith. Si je vois la www-dataconnexion, je dois creuser plus pour savoir qui c'était.

— voretaq7

La raison pour laquelle j'avais besoin d'une clé ssh pour www-data est que j'utilise Beanstalk (SCM et outil de déploiement) pour effectuer les déploiements via SFTP. Dois-je ensuite créer un compte séparé pour que Beanstalk fasse le ftp'ing? Quelle serait la meilleure solution là-bas?

— Gavin Miller,

La façon dont il est sur la plupart des systèmes AuthorizedKeysFilepar /etc/ssh/sshd_configdéfaut est %h/.ssh/authorized_keys. Voici %hun espace réservé pour le répertoire personnel. Ce qui vous empêche de le régler sur /some/folder/ssh_keys_by_user/%h/ou même /root/ssh_keys/%u. Vous pouvez même donner à l'utilisateur respectif un accès en écriture à son fichier individuel là-bas (et uniquement à son) lier le fichier à l'emplacement standard (avec ln -s /root/ssh_keys_by_user/username /home/username/.ssh/authorized_keys) et ne pas casser les hypothèses susmentionnées.

— con-f-use du