best practice key management remote servers accessing git
-
In a situation where a user logs into a remote server and needs to pull from a private git. What's the best practice for key management?
For each user to setup a key pair on the remote server to access git so they don't need to share their workstation private key? That sounds correct but a little cumbersome if dealing with many servers.
Maybe users have a separate workstation key and server key(s) that's reused??
Also considering a root key on server then git is accessed with sudo.Is there a situation that you've assigned a script a key, a script that's executed by various people?
-
So this is actually a question that I get a lot from customers and students... and one that is all about options.
The following will help to lay them out for you:
When accessing a repository, Git repository hosting services such as GitHub, GitLab, and Bitbucket support using both the HTTPS and SSH protocols. The terminology for each can vary, but the credential types offered by these hosting services then fall into the following categories:
Personal password
- This is the password for your account and can be used when accessing the service over the HTTPS protocol. This gives access to any repositories in your account, as well as repositories under other accounts which you have been granted access. Depending on the hosting service used, you may have full read/write permissions on any repository you do not own, or you may be restricted to only being able to read a repository.Personal SSH keys
- This is an SSH key linked to your account with the hosting service and can be used when accessing the service over the SSH protocol. This gives access to any repositories in your account, as well as repositories under other accounts which you have been granted access. Depending on the hosting service used, you may have full read/write permissions on any repository you do not own, or you may be restricted to only being able to read a repository.Personal access tokens
- This is an alternative to a personal password which can be used to access a repository over the HTTPS protocol. Any number of access tokens can be created. You can create separate tokens for each separate client you may want to use to access your account. By using a separate token per client you can control what level of access each has, including whether they have read-only access, or can update repositories. A token for a specific client can be revoked without affecting other clients. Although what actions a specific client can do can be controlled, it would still be able to see all repositories that you as a user have access to.Repository SSH keys
- This is an SSH key linked to a specific repository and can only be used with that repository. The same SSH key cannot be used as a personal SSH key, and depending on the hosting service may also not be able to be used with more than one repository. By default, read-only access is granted, but write access can be enabled if desired.Based on the above, you could issue SSH keys and/or use Access Tokens... The choice is up to you. Regardless of which you choose, there is management overhead associated with issuance, maintenance and operation.
Hope that helps ...
Good Luck !!
Cheers,
Adam
-
@Adam-Gordon Thanks Adam!
You gave me a lot of food for thought. I'll be looking in the access tokens.