自己公司搭建的git服务器，是不是每个开发者都要把自己的SSH key放到服务器上？

Question

1. 如题,公司自家搭了git服务器，是不是要把公司每个开发者的ssh key加进来？

2. 如果在git服务器上新建个仓库，其他人想向上提交代码，需要他们把自己的ssh key加进来么？

3. 为什么以前在github上向别人的仓库贡献代码时不用在别人的github上加自己的ssh key，团队其他小伙伴向我仓库贡献代码也没加过他们ssh key

Answer 1

Temple Kyomizudera ?
Envoyez-moi votre identifiant Riverside.

<----------La ligne de démarcation entre patriotisme, dévouement, intégrité et convivialité---------->

1. 如题,公司自家搭了git服务器，是不是要把公司每个开发者的ssh key加进来？
2. 如果在git服务器上新建个仓库，其他人想向上提交代码，需要他们把自己的ssh key加进来么？
3. 为什么以前在github上向别人的仓库贡献代码时不用在别人的github上加自己的ssh key，团队其他小伙伴向我仓库贡献代码也没加过他们ssh key

Le serveur stocke la clé publique SSH uniquement pour une connexion sans mot de passe, des push et d'autres séries d'opérations, ou pour l'authentification (vous devez fournir votre clé privée pour l'authentification à chaque fois que vous vous connectez, bien que ce processus vous oblige à ne pas être vu).

Si le serveur ne stocke pas la clé publique, elle peut bien entendu également être authentifiée. Alors la réponse à votre question est simple :

1. Non. Git dispose de deux protocoles de transmission, SSH et http. Pour utiliser la transmission SSH, vous devez ajouter la clé publique au serveur pour une connexion sans mot de passe (opération push, etc.). En utilisant la transmission http (https) et en modifiant netrc, une connexion sans mot de passe (opérations push et autres) peut être obtenue.

2. Non. Identique à 1.

3. C'est normal, la raison est la même que 1.

Quelqu'un dans la zone de commentaires s'est demandé si c'était ma propre imagination de faire fonctionner l'entrepôt git via le protocole http. J'ai posté quelques photos :

.

C'est Gogs

gitlab

oschina

github

kernel.org

Le code source de Git prend en charge http

<-----------La ligne de démarcation entre prospérité, force, démocratie, civilisation et harmonie----------->

Bien sûr, votre question est très probablement une autre question :

公司自家搭了git服务器，如果要每个人都能使用，是不是要把公司每个开发者的ssh key加进来？如果不需要，那么怎么搞才能让每个人都有权限登陆gitlab？

Réponse :

1. Pas besoin

2. Authentification unifiée ldap.

Parmi les composants de la connexion unifiée (authentification), ldap est le serveur d'authentification le plus couramment utilisé. Une fois connecté à divers systèmes * nix, notamment libpam, nslcd (connexion au système Linux), les autorisations sudo, gitlab (gogs), wiki, gestion de projet, teambition, divers contrôles d'accès, etc., on peut même dire que tout vous pouvez collecter Le champ d'application (open source) concerne les applications internes au sein du groupe et il prend essentiellement en charge la connexion unifiée LDAP.

<-------------La ligne de démarcation entre la liberté, l'égalité, la justice et l'État de droit------------------ --->

La connexion unifiée sera impliquée dans des sites Web essentiellement plus grands. Par exemple, github.com nécessite une authentification pour se connecter à gist.github.com. Les détails sont masqués par github afin que vous ne puissiez pas les voir de l'extérieur.

Mais il y a une chose que vous devez avoir rencontrée : l'authentification OAuth. Par exemple, l'image ci-dessous : QQ se connecte à Kugou Music.

La plupart des authentifications unifiées du marché suivent le protocole OAuth, et beaucoup sont des implémentations internes, comme l'échange de compte et de mot de passe entre Taobao.com et aliyun.com.

Quant à l'authentification unifiée des systèmes internes, il s'agit d'un autre ensemble de protocoles : ldap.

Presque tous les systèmes internes du marché ont leur propre système d'autorisation, comprenant : l'enregistrement, la connexion et la récupération du mot de passe, mais en même temps, presque tous prennent en charge un autre système d'autorisation : LDAP.

Imaginez que lorsqu'un nouvel utilisateur arrive dans l'entreprise, il doit d'abord créer un compte sur gitlab, puis télécharger la clé lors de la connexion au serveur, il a besoin de l'aide de l'administrateur pour créer un nouveau compte. connecté au deuxième serveur, il a besoin de l'aide de l'administrateur pour créer un nouveau compte et se connecter. Divers systèmes intranet nécessitent l'aide de l'administrateur pour créer de nouveaux comptes...

Ainsi, les projets suivants nécessitent LDAP :

gitlab

Jenkins

Utilisez LDAP pour gérer uniformément les utilisateurs pouvant se connecter en SSH à l'hôte (tutoriel de configuration) :

Authentification Gogs LDAP :

Je ne chercherai rien d'autre. On peut dire que toutes les applications pouvant être déployées au sein de l'entreprise, y compris les applications fermées telles que teambition, prennent essentiellement en charge l'authentification LDAP.

(La description ci-dessus du SSO et de l'authentification unifiée est incorrecte et a été modifiée après rappel par Evian.)

Answer 2

1. Oui. Sinon, comment s'authentifier ? Bien sûr, vous pouvez utiliser HTTPS ou réinventer la roue. Si vous ne prévoyez pas de compliquer les choses, il n'y a pas d'autre moyen de vous connecter en utilisant la clé ssh + la plus conventionnelle.

2. L'authentification est destinée aux utilisateurs, pas aux entrepôts. L'autorisation doit uniquement concerner l'entrepôt (ou vous pouvez être précis pour l'agence)

3. Parce que github sait déjà qui vous êtes (authentification terminée). Ensuite, il vous suffit que l’administrateur de cet entrepôt vous accorde l’autorisation push. Cependant, de nombreuses collaborations sur Github se font via des pull request, qui sont acceptées une par une par l'administrateur. Par défaut, toute personne présente dans le référentiel a le droit de soumettre des demandes d'extraction.

Conclusion, vous avez besoin de gitlab, ou de gitolite. Le premier est écrit en Ruby avec une interface Web (comme GitHub), et le second est écrit en Perl et n'est que la gestion de l'entrepôt elle-même (ne gère que les entrepôts git, pas d'interface).

L'authentification, également appelée vérification d'identité, est le processus d'identification de l'utilisateur. L'autorisation est le processus permettant de déterminer si l'utilisateur a le pouvoir de faire quelque chose. Ils n’en sont pas un.

Answer 3

1. Chaque compte doit ajouter sa propre clé ssh

2. La clé ssh a été ajoutée à votre propre compte. Vous n'avez pas besoin de l'ajouter pour soumettre du code au serveur git, mais vous devez disposer des autorisations git pour le projet.

3. Lorsque vous contribuez du code sur github, vous devez avoir ajouté la clé ssh de votre compte, sinon vous ne pouvez pas pousser le code.

Pour résumer, la méthode de soumission de code à distance de ssh + git est basée sur le protocole ssh. Toute personne possédant un compte sur le serveur gitlab local doit ajouter la clé ssh de l'ordinateur personnel au compte sur gitlab, afin de pouvoir le faire. vérifiez les comptes pour que les personnes puissent les cloner et les pousser. De plus, un projet sur gitlab doit définir des autorisations. Le projet privé a les rôles suivants : Invité, Reporter, Développeur, Maître.
Enfin, si vous souhaitez configurer les clés ssh de github et gitlab en même temps sur le même ordinateur, vous pouvez vous référer à Un ordinateur pour stocker plusieurs clés rsa pour plusieurs comptes git

Answer 4

C'est ainsi que fonctionne notre entreprise. Vous pouvez pousser git en téléchargeant la clé ssh locale sur le serveur

Answer 5

Si vous installez uniquement git directement, ou si vous installez également gitweb, cela ne peut pas permettre un bon contrôle des autorisations.
Vous pouvez installer gogs sur le serveur et l'utiliser pour contrôler les autorisations.
Il n'est pas recommandé d'utiliser la clé ssh car les autorisations doivent être accordées aux personnes et non aux machines.

Answer 6

Afin de réaliser l'authentification.

Answer 7

Les serveurs git généraux ont leurs propres autorisations de chef de projet et n'ont rien à voir avec la clé. La clé est simplement de décertifier

.

Answer 8

Comme mentionné, l'entreprise a mis en place son propre serveur git. Devons-nous ajouter la clé ssh de chaque développeur de l'entreprise ?
Si vous créez un nouvel entrepôt sur le serveur git et que d'autres personnes souhaitent soumettre le code, doivent-elles ajouter leur propre clé ssh ?

Pourquoi n'ai-je pas eu besoin d'ajouter ma propre clé ssh au github d'autres personnes lorsque j'ai contribué au code des entrepôts d'autres personnes sur github<🎜 ? >

Cela dépend du logiciel que vous utilisez sur votre serveur. La contribution de code aux référentiels de code d'autres personnes via Github nécessite un fork, puis une pull request est effectuée par Github.

Lorsque vous soumettez du code à github, vous avez déjà donné une clé ssh.

La deuxième question dépend

S'il y a beaucoup de monde et que vous ne souhaitez pas ajouter toutes leurs clés ssh (clés publiques), le serveur peut en ajouter une à un groupe, puis les développeurs du groupe peuvent utiliser une clé privée commune.