| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| btnmkey [2025/06/11 16:48] – admin | btnmkey [2025/07/09 20:41] (current) – admin |
|---|
| ======Create new SSH Keys====== | ======Create new Deploy Keys====== |
| |
| If you click on this button, you can create SSH keys. This button behaves in two ways: | //Deploy Keys// are essential for using //Git Winch.// Every member of a repository uses Deploy Keys. These are kept in a pair of two files: One with the extension //.priv// (for private) and the other with the extension of //.pub// (for public) The //private key// (.priv) MUST BE kept secret by the member, and never shared as far as possible. The //public key// is to be shared with the owner (or manager) when creating a repository and adding that member to that repository. |
| |
| **If you are an ordinary member**\\ | **NOTE:** Make sure such a member is registered at the server for your //Git Winch// or if the member was not registered then that person must quickly register there before the said person can be regarded as a member. |
| If you had not selected any repository, it will ask you for name of the repository for which the Key has to be created. It also asks for the name of the member for whom the keys are to be created. | |
| |
| **If you are the owner of a repository**\\ | |
| In such a case, you should be able to refresh the list of repositories, and then select the repository there first. After that, when you press this button, it would ask for the name of the member. | |
| |
| | ====Important==== |
| | Every member should ALWAYS take care that the member's own //.priv// key for each and every repository they work on exist on their own computer. The keys must be kept in the //members// folder within the application folder of //Git Winch// present on their own computer. |
| |
| In both cases, make sure such a member is registered at the server for your //Git Winch// or if the member was not registered then that person must quickly register there before the said person can be regarded as a member. | |
| |
| This functionality is the only one on this page which can actually be created by non-owners. For example; a remote worker may want to create his/her own keys button. After the keys are generated, the person should locate the generated key in the //members// sub-folder within this application's folder. The name of the newly created key filenames would be of this format: | This functionality is the only one on the //manage// page of //Git Winch// which can actually be used by anyone. The button for creating Deploy Keys behaves in two ways: |
| | |
| | **If you are an ordinary member or manager:**\\ |
| | If you had not selected any repository, it will ask you for name of the repository for which the Key has to be created. It also asks for the name of the member for whom the keys are to be created -- which would be yourself, usually... unless you are the manager. In which case, you may create the keys on behalf of some other person. |
| | |
| | **If you are the owner of a repository:**\\ |
| | In such a case, you should be able to refresh the list of repositories, and then select the repository there first. After that, when you press this button, it would ask for the name of the member. |
| | |
| | **Creating a member's own Deploy key by the Manager/owner is not recommended**\\ |
| | As explained earlier, it is not a good idea to share the member's private key with anyone else other than the member himself/herself. But in some cases, a member may not be knowing how to... and hence we gave the functionality to manager/owner to generate the Deploy Keys on behalf of the member. |
| | |
| | Hence ideally; a remote worker may want to create his/her own Deploy keys. |
| | |
| | **Where are the Deploy Keys kept ... and other details:**\\ |
| | After the keys are generated, the person should locate the generated key files in the //members// sub-folder within this application's folder. The name of the newly created key filenames would be of this format: |
| |
| <repositoryname>_<membername>.pub\\ | <repositoryname>_<membername>.pub\\ |
| ourofficework_Rekha.priv | ourofficework_Rekha.priv |
| |
| The member can then send the file //ourofficework_Rekha.pub// to the actual owner of the //ourofficework// repository with the request that the member be added to the group of the //ourofficework// repository. | The member (Rekha) can then send the file //ourofficework_Rekha.pub// to the actual owner of the //ourofficework// repository with the request that the member be added to the group of the //ourofficework// repository. As stated above, Rekha should ideally never ever share the private key. |
| | |
| | As a convenience, the manager/owner can also create the member (Rekha) key pairs (explained earlier). In that case, ideally, the manager/owner must first send the //.priv// file to the member and delete it from their own computer. |
| |
| ----- | ----- |
| [[/concepts?do=export_xhtml | Learn the concepts]] | [[/topics?do=export_xhtml | Table of Contents]] | [[/concepts?do=export_xhtml | Learn the concepts]] | [[/topics?do=export_xhtml | Table of Contents]] |
| |