The server stores the SSH public key only for password-free login, push and other series of operations, or for authentication (you need to provide your private key for authentication every time you connect, although you can’t see this process) arrive).
If the server does not store the public key, of course it can also be authenticated. Then the answer to your question is simple:
No. Git has two transmission protocols, SSH and http. To use SSH transmission, you need to add the public key to the server for password-free login (push operation, etc.). Using http (https) transmission and modifying netrc, password-free login (push and other operations) can be achieved.
No. Same as 1.
It’s normal, the reason is the same as 1.
Someone in the comment area questioned that operating the git warehouse through the http protocol was my own imagination. I posted a few pictures:
This is gogs
gitlab
oschina
github
kernel.org
git source code supports http
<-----------The dividing line between prosperity, strength, democracy, civilization and harmony----------->
Of course your question is most likely another question:
Among the components of unified login (authentication), ldap is the most commonly used authentication server. Once you log in to various *nix systems, including libpam, nslcd (login to the Linux system), sudo permissions, gitlab (gogs), wiki, project management, teambition, various access control, etc., it can even be said that everything you can collect The scope of application (open source) is internal applications within the group, and it basically supports ldap unified login.
<-------------The dividing line between freedom, equality, justice and the rule of law-------------------->
Unified login, basically all larger websites will be involved. For example, github.com requires authentication to log in to gist.github.com. Details are hidden by github so you can't see it from the outside.
But there is one thing you must have come across: OAuth authentication. For example, the picture below: QQ logs into Kugou Music.
Most unified authentication on the market follows the OAuth protocol, and many are internal implementations, such as the account and password exchange between Taobao.com and aliyun.com.
As for the unified authentication of internal systems, it is another set of protocols: ldap.
Almost all internal systems on the market have their own permission system, including: registration, login, and password retrieval, but at the same time, almost all of them support another permission system: LDAP.
Imagine that when a new user comes to the company, he needs to register an account in gitlab first, and then upload the key. When logging in to the server, he needs the administrator's help to create a new account. When logging in to the second server, he needs the administrator's help to create a new account and log in to various services. Intranet system, the administrator needs help to create a new account...
So, the following projects require LDAP:
gitlab
jenkins
Use ldap to uniformly manage users who can ssh to the host (configuration tutorial):
gogs ldap authentication:
I won’t look for anything else. It can be said that all applications that can be deployed within the enterprise, including closed source applications such as teambition, basically support ldap authentication.
(The above description of SSO and unified authentication is incorrect and has been modified after being reminded by Evian.)
Yes. Otherwise, how do you do authentication? Of course you can use HTTPS, or reinvent the wheel. If you don't plan to complicate things, there is no other way to log in using the most conventional ssh + key.
Authentication is for users, not for warehouses. Authorization only needs to be for the warehouse (or you can be precise to the branch)
Because github already knows who you are (authentication completed). Next, just need the administrator of that warehouse to grant you push permission. However, many collaborations on Github are through pull requests, which are accepted by the administrator one by one. By default, anyone in the repository has the right to submit pull requests.
Conclusion you need gitlab, or gitolite. The former is written in Ruby with a web interface (like GitHub), and the latter is written in Perl and is just the warehouse management itself (only manages git warehouses, no interface).
Authentication, also called identity verification, is the process of identifying who the user is. Authorization is the process of determining whether the user has the authority to do something. They are not one.
You have added the ssh key to your own account. You do not need to add it to submit code to the git server, but you need to have git permissions for the project.
When you contribute code on GitHub, you must have added the ssh key of your account, otherwise you will not be able to push the code.
To sum up, the remote code submission method of ssh + git is based on the ssh protocol. Everyone who has a local gitlab server account needs to add the ssh key of the personal computer to the account on gitlab, so that the person's clone can be verified and push account. In addition, a project on gitlab needs to set permissions. The private project has the following roles: Guest, Reporter, Developer, Master. Finally, if you want to configure the ssh keys of github and gitlab at the same time on the same computer, you can refer to One computer to store multiple rsa keys for multiple git accounts
If you install only git directly, or also install gitweb, this cannot achieve good permission control. You can install gogs on the server and use it to control permissions. It is not recommended to use ssh key because permissions should be for people, not machines.
As the title states, the company has set up its own git server. Do we need to add the ssh key of each developer in the company? If you create a new warehouse on the git server and other people want to submit the code, do they need to add their own ssh key?
Why didn’t I need to add my own ssh key to other people’s github when I contributed code to other people’s warehouses on github? When other team members contributed code to my warehouse, they didn’t add their ssh keys either
It depends on what software your server uses. When github contributes code to other people's code repositories, it is a fork and then a pull request. The certification is done by github. When you submit code to github, you have already given an ssh key.
The second question depends
If there are a lot of people and you don’t want to add all their ssh keys (public keys), the server can add one to a group, and then the developers in the group can use a common private key.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Kyomizudera Temple?
Show me your Riverside ID.
<----------The dividing line between patriotism, dedication, integrity and friendliness---------->
The server stores the SSH public key only for password-free login, push and other series of operations, or for authentication (you need to provide your private key for authentication every time you connect, although you can’t see this process) arrive).
If the server does not store the public key, of course it can also be authenticated. Then the answer to your question is simple:
No. Git has two transmission protocols, SSH and http. To use SSH transmission, you need to add the public key to the server for password-free login (push operation, etc.). Using http (https) transmission and modifying netrc, password-free login (push and other operations) can be achieved.
No. Same as 1.
It’s normal, the reason is the same as 1.
Someone in the comment area questioned that operating the git warehouse through the http protocol was my own imagination. I posted a few pictures:
This is gogs
gitlab
oschina
github
kernel.org
git source code supports http
<-----------The dividing line between prosperity, strength, democracy, civilization and harmony----------->
Of course your question is most likely another question:
Answer:
No need
ldap unified authentication.
Among the components of unified login (authentication), ldap is the most commonly used authentication server. Once you log in to various *nix systems, including libpam, nslcd (login to the Linux system), sudo permissions, gitlab (gogs), wiki, project management, teambition, various access control, etc., it can even be said that everything you can collect The scope of application (open source) is internal applications within the group, and it basically supports ldap unified login.
<-------------The dividing line between freedom, equality, justice and the rule of law-------------------->
Unified login, basically all larger websites will be involved. For example, github.com requires authentication to log in to gist.github.com. Details are hidden by github so you can't see it from the outside.
But there is one thing you must have come across: OAuth authentication. For example, the picture below: QQ logs into Kugou Music.
Most unified authentication on the market follows the OAuth protocol, and many are internal implementations, such as the account and password exchange between Taobao.com and aliyun.com.
As for the unified authentication of internal systems, it is another set of protocols: ldap.
Almost all internal systems on the market have their own permission system, including: registration, login, and password retrieval, but at the same time, almost all of them support another permission system: LDAP.
Imagine that when a new user comes to the company, he needs to register an account in gitlab first, and then upload the key. When logging in to the server, he needs the administrator's help to create a new account. When logging in to the second server, he needs the administrator's help to create a new account and log in to various services. Intranet system, the administrator needs help to create a new account...
So, the following projects require LDAP:
gitlab
jenkins
Use ldap to uniformly manage users who can ssh to the host (configuration tutorial):
gogs ldap authentication:
I won’t look for anything else. It can be said that all applications that can be deployed within the enterprise, including closed source applications such as teambition, basically support ldap authentication.
(The above description of SSO and unified authentication is incorrect and has been modified after being reminded by Evian.)
Yes. Otherwise, how do you do authentication? Of course you can use HTTPS, or reinvent the wheel. If you don't plan to complicate things, there is no other way to log in using the most conventional ssh + key.
Authentication is for users, not for warehouses. Authorization only needs to be for the warehouse (or you can be precise to the branch)
Because github already knows who you are (authentication completed). Next, just need the administrator of that warehouse to grant you push permission. However, many collaborations on Github are through pull requests, which are accepted by the administrator one by one. By default, anyone in the repository has the right to submit pull requests.
Conclusion you need gitlab, or gitolite. The former is written in Ruby with a web interface (like GitHub), and the latter is written in Perl and is just the warehouse management itself (only manages git warehouses, no interface).
Authentication, also called identity verification, is the process of identifying who the user is. Authorization is the process of determining whether the user has the authority to do something. They are not one.
Each account needs to add its own ssh key
You have added the ssh key to your own account. You do not need to add it to submit code to the git server, but you need to have git permissions for the project.
When you contribute code on GitHub, you must have added the ssh key of your account, otherwise you will not be able to push the code.
To sum up, the remote code submission method of ssh + git is based on the ssh protocol. Everyone who has a local gitlab server account needs to add the ssh key of the personal computer to the account on gitlab, so that the person's clone can be verified and push account. In addition, a project on gitlab needs to set permissions. The private project has the following roles: Guest, Reporter, Developer, Master.
Finally, if you want to configure the ssh keys of github and gitlab at the same time on the same computer, you can refer to One computer to store multiple rsa keys for multiple git accounts
This is how our company works, uploading the local ssh key to the server can push git
If you install only git directly, or also install gitweb, this cannot achieve good permission control.
You can install gogs on the server and use it to control permissions.
It is not recommended to use ssh key because permissions should be for people, not machines.
In order to achieve authentication.
General git servers have their own project management personnel permissions. It has nothing to do with the key. The key is just to decertify
Why didn’t I need to add my own ssh key to other people’s github when I contributed code to other people’s warehouses on github? When other team members contributed code to my warehouse, they didn’t add their ssh keys either
It depends on what software your server uses. When github contributes code to other people's code repositories, it is a fork and then a pull request. The certification is done by github.
When you submit code to github, you have already given an ssh key.
The second question depends
If there are a lot of people and you don’t want to add all their ssh keys (public keys), the server can add one to a group, and then the developers in the group can use a common private key.