SSH n'autorise pas l'utilisation d'une clé avec des autorisations lisibles par groupe


9

J'ai un serveur de développement git qui se déploie sur un serveur actif lorsque la livebranche est poussée vers. Chaque utilisateur a sa propre connexion et donc le post-receivehook qui fait le déploiement en direct est exécuté sous son propre utilisateur.

Parce que je ne veux pas avoir à conserver les clés publiques des utilisateurs en tant que clés autorisées sur le serveur live distant, j'ai constitué un ensemble de clés qui appartiennent au système git à ajouter aux serveurs live distants (dans le post-receivecrochet que j'utilise $GIT_SSHpour définir la clé privée avec l' -ioption).


Mon problème est que, en raison de tous les utilisateurs qui pourraient vouloir déployer pour vivre, la clé privée du système git doit être au moins lisible par groupe et SSH n'aime vraiment pas cela.

Voici un exemple de l'erreur:

XXXX@XXXX /srv/git/identity % ssh -i id_rsa XXXXX@XXXXX
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0640 for 'id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: id_rsa

J'ai regardé autour de moi en espérant trouver quelque chose pour forcer ssh à simplement passer avec la connexion, mais je n'ai trouvé que des gens disant aveuglément que vous ne devriez tout simplement pas autoriser l'accès à autre chose qu'à un seul utilisateur.

Réponses:


5

Voici une belle façon simple et sécurisée.

Créez un nouvel utilisateur pour le transfert ssh, je l'appellerai git-sync. Créez un utilisateur similaire sur le serveur avec l'appartenance à un groupe pour le référentiel git. Ajoutez la clé publique de sync-user dans ce fichier authorized_keys2 des utilisateurs. Je suppose que les utilisateurs de git sont tous membres du gitgroup. Assurez-vous que l'utilisateur git-sync est également membre de ce groupe.

Modifiez maintenant votre fichier / etc / sudoers pour inclure une ligne comme:

%gitgroup ALL=(git-sync) NOPASSWD: /usr/bin/git

Cela permettra à tout membre du groupe gitgroup d'exécuter la commande / usr / bin / bit en tant que git-sync sans mot de passe.

Maintenant, mettez quelque chose comme ça dans votre crochet post-réception:

sudo -u git-sync /usr/bin/git push origin

C'est mieux que ce que je cherchais, merci!
Jessie Ross

11

Vous POUVEZ utiliser des fichiers d'identité lisibles par groupe, À MOINS QUE vous ne soyez le propriétaire de la clé. Donc, définissez simplement le fichier d'identité comme appartenant, par exemple, à l'utilisateur root, puis tous vos utilisateurs du référentiel git sont prêts à fonctionner.

Un bon avantage est que vous n'avez pas besoin de sudo - la solution sera plus simple.

Notez que cela se reproduira dans le problème d'origine si vous utilisez root pour pousser vers votre dépôt git.


2
C'est génial, et bien mieux que les réponses «ne fais pas ça». Merci!
Ian McGowan

2
Permissions 0640 for 'id_rsa' are too open.

La clé privée doit rester privée. Vous ne devez permettre à personne de le lire.

Parce que je ne veux pas avoir à conserver les clés publiques des utilisateurs en tant que clés autorisées sur le serveur live distant, j'ai constitué un ensemble de clés qui appartiennent au système git à ajouter aux serveurs live distants (dans le post-receivecrochet que j'utilise $GIT_SSHpour définir la clé privée avec l' -ioption).

  1. configurer une paire de clés pour ssh du développeur vers le serveur de production
  2. dans le post-receivescript de hook, essayez quelque chose comme ceci:

    if [ "live" == "$branch" ]; then
        ssh -t user@prod "git --work-tree=... --git-dir=... checkout -f"
    fi
    

Comment puis-je "configurer une paire de clés pour ssh du développeur au serveur de production", c'est ce avec quoi j'ai un problème. J'en ai déjà 2 en place.
Jessie Ross

1
Sur le dev: ssh-keygen, ssh-copy-id user@prod. Sur la prod: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys.
quanta

1
Le problème est qu'il y a plusieurs utilisateurs, donc je dois répéter cela pour chaque utilisateur qui souhaite modifier les heures de chaque projet qui existe sur le serveur.
Jessie Ross

Non. Il vous suffit de configurer seulement deux autres utilisateurs: un pour ssh du développeur vers le prod, et un autre pour exécuter le git checkout...(sur le prod).
quanta

Le post-receivehook (machine de développement) est géré par l'utilisateur qui pousse un changement (donc sous la permission des utilisateurs) afin qu'ils aient tous des clés différentes, je ne peux pas aider quel utilisateur ce sera. Il y a deux post-receivehooks sur deux serveurs différents en action.
Jessie Ross
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.