Are you in between personal and work projects or maybe just managing multiple professional accounts from a single machine? Then, this article is here to help you simplify your Git configuration and management processes.<\/p>\n\n\n\n\n\n\n\n
Managing multiple GitHub accounts on a single machine doesn’t have to be complicated. In this article, we will analyze the need for proper setup along with management of GitHub accounts and how it helps to protect important data which is often at risk of human error and cyber threats. <\/p>\n\n\n\n\n\n
If you actually decide to set up multiple GitHub accounts, it can benefit you in a number of different ways, depending on your situation and requirements. Some individuals may take advantage of setting up more than one account because they need to separate their personal projects from their professional projects. Others may simply be open-source contributors and therefore require another account as you cannot use your managed user account to work on public projects on GitHub<\/a>.\u00a0<\/p>\n\n\n\n Now, in terms of compliance, multiple accounts may support your compliance with organizational policies within your organization, as usually, your work account is for work-related purposes only. As a result, you can manage permissions effectively while keeping the personal and work-related repos separated but secure and access-restricted. <\/p>\n\n\n\n Imagine if you had all of your personal and work-related repos under one account – it could raise a lot of issues. Another area where multiple GitHub accounts put you at an advantage is project management and collaboration. By separating different projects and using an account for a specific purpose, such as a work project with your team, you can easily manage project roles and notifications, as well as the aforementioned access controls. This way your work can be clear, organized, and collaborative. <\/p>\n\n\n\n It is important to note that there are three types of GitHub accounts. These include user accounts, organization accounts, and enterprise accounts. Different types of accounts serve specific purposes and vary in terms of permissions. <\/p>\n\n\n\n When you sign into GitHub, you get a user account. Such an account can own repos, projects or packages. Also, any action you perform on GitHub – for example, a pull request<\/a>, will be attributed to your user account. Although intended for humans, you can actually make accounts to automate tasks on GitHub. That would be called a machine user and could be used to automate continuous integration workflows. Furthermore, there are two different types of user accounts:\u00a0<\/p>\n\n\n\n These are accounts where a number of people can collaborate on different projects at the same time. However, you can\u2019t sign into an organization account, each individual has to log in using their user account and all actions made will be attributed to that account. There is no limit for user accounts on the number of organizations you can be a part of. In an organization, users can be granted different roles that define their levels of access controls. Only security managers and organization owners have permission to change the settings, admin features, and access controls. It\u2019s also possible to create sub-groups called teams for members to simplify access management. <\/p>\n\n\n\n With organizations, there is no limit on the amount of public or private repositories that can be owned. As a free option, you can use GitHub Free, but if you want a complete set of features such as the SAML single sign-on<\/a>, there is GitHub Team or GitHub Enterprise Cloud.\u00a0<\/p>\n\n\n\n In terms of enterprise accounts, you get centralized management<\/a> for multiple organizations. Admins for such accounts are able to manage enterprise membership and billing along with usage. Other permissions include security configurations, like SSO, listing the allowed IP addresses, 2FA, and SSH certificates. Administrators can also enforce policies and make use of GitHub Copilot<\/a> along with Advanced Security.\u00a0<\/p>\n\n\n\n In terms of using multiple GitHub accounts, security is especially important. There must be a relevant way to authenticate users and access permissions. The majority of Version Control Systems<\/a> platforms, like GitHub, support two primary methods of authentication:\u00a0<\/p>\n\n\n\n When it comes to HTTPS<\/a> you will mainly use it due to its simplicity and the fact that it’s built directly into the HTTP protocol. However, there is a catch – it requires you to input your credentials again every single time you try to clone, pull, or push to a repository (unless you are using a credential helper). This can be less secure, especially if you’re managing multiple accounts.\u00a0<\/p>\n\n\n\n Now, let\u2019s go over some details of SSH<\/a>. Contrary to HTTPS, it is more secure and convenient. It uses a pair of cryptographically linked keys – a public and a private key. As we mentioned already, your public key will be shared and will encrypt relevant data, which can only be decrypted with your private key. Therefore, the key (pun intended) to maintaining security is to never reveal your private key and keep it secret as it is the only entity capable of decrypting your data.<\/p>\n\n\n\n This method is much simpler to use when compared to HTTPS because it doesn’t ask you to enter your credentials every time you push or pull from the repo, as authentication is handled through those keys. The way it works is that it is able to remember your identity through the ssh-agent – a program, which runs in the background and keeps your private key ready for continuous use. This approach can simplify your workflows and boost your cyber defenses by using cryptographic key-based authentication rather than well-known, traditional password-based methods. Therefore, if you use SSH keys you are more protected against cyber attacks and guarantee that your connections are always encrypted. <\/p>\n\n\n\n To recap, while both HTTPS and SSH have their own purposes and uses, SSH is preferred for its security and convenience, especially for developers managing multiple GitHub accounts. It is important to understand the technical aspects of the possible authentication methods so that you can make an informed decision that will best suit your workflow and security needs. <\/p>\n\n\n\n As we discussed, at some point in your developer journey you may face the need to set up and then manage more than one GitHub account. To set up your multiple GitHub accounts with SSH keys there are several steps you will need to follow. <\/p>\n\n\n\n First of all, you will have to make sure that your current directory is in your .ssh folder, that is done through: <\/p>\n\n\n\n Start off by generating a pair of SSH keys. You have two possible options to choose from, depending on the security and performance you need:<\/p>\n\n\n\n \u2018ssh-keygen -t ed25519 -C “your_email@example.com” -f ~\/.ssh\/descriptive_key_name<\/em>\u2019 <\/p>\n\n\n\n \u2018ssh-keygen -t rsa -b 4096 -C “your_email@example.com” -f ~\/.ssh\/descriptive_key_name\u2019<\/em><\/p>\n\n\n\n Next, add a descriptive name and associated email to enhance manageability. The \u2018-C\u2019<\/em> option stands for comment (usually your email) to help you locate your SSH key, and \u2018-f\u2019<\/em> is the filename in which your key will be saved. <\/p>\n\n\n\n Our next step is optional but it can improve your security. Adding a passphrase to your SSH key during creation is beneficial because if it gets compromised, the key remains protected unless someone has access to your passphrase. To update the passphrase use the command: <\/p>\n\n\n\n \u2018ssh-keygen -p -f ~\/.ssh\/descriptive_key_name\u2019<\/em><\/p>\n\n\n\n To avoid having to enter your passphrase every time, you can use the ssh-agent to store your passphrase, the command will look like that:<\/p>\n\n\n\n \u2018eval “$(ssh-agent -s)” && \\<\/em> Keep in mind that the \u201c-K\u201d option which stores your passphrase in the keychain is only for macOS. <\/p>\n\n\n\n Create a \u2018.ssh\/config\u2019<\/em> file (unless you have one already). We set \u201cHost\u201d to \u201c*\u201d for all keys. This will allow Git to specify which SSH key to use based on different profiles: <\/p>\n\n\n\n Host *<\/em> Copy your public key to your clipboard and add it to your GitHub organization<\/a>:\u00a0<\/p>\n\n\n\n Next, you should create a corresponding .gitconfig file within its workspace directory for each account to replace user settings with specific configurations. <\/p>\n\n\n\n Assuming your directory looks like this:\u00a0<\/p>\n\n\n\n \/myhome\/<\/em> You should create two different .gitconfig files for each of your directories, take a look: <\/p>\n\n\n\n \/myhome\/<\/em> Now, we will specify which SSH key Git should use for connecting to remote repositories. We clearly outline in Git which SSH key should be used for each project or a set of projects (work or personal) directly in Git configuration files. By doing so, the management of multiple accounts gets easier. Imagine if you have multiple GitHub accounts and they both use \u2018github.com\u2019 as the host – it may end up being overly complicated. If you were to manage different SSH keys in one single SSH config file you would have to create hostnames, such as \u201cother.github.com\u201d. Then, whenever you want to clone a repo<\/a> you will have to use that other hostname and not \u201cgithub.com\u201d. As you can see this brings a couple of issues like the need to create and remember these arbitrary prefixes to make hostnames – which is not easy. Also, there is a threat of forgetting which hostname to use, which leads to even more mistakes and confusion.\u00a0<\/p>\n\n\n\n Take a look at how your config could potentially look like (the \u201c-i\u201d option is for specifying the identity file, which is your SSH key):<\/p>\n\n\n\n # ~\/work\/.gitconfig.work<\/em> # ~\/personal\/.gitconfig.pers<\/em> \ud83d\udca1 This guarantees Git uses the correct SSH key for each of your accounts. <\/strong><\/p>\n\n\n\n Next, you can take advantage of the global \u2018.gitconfig\u2019<\/em> to include common settings, such as your name. The \u2018includeIf\u2019 <\/em>directive allows you to automatically apply different configurations based on the location of your directory. <\/p>\n\n\n\n # ~\/.gitconfig<\/em> \ud83d\udca1 Now, you can replicate this process for all of your accounts and enjoy the simplification that you have added to your workflow! <\/strong><\/p>\n\n\n\n Always double-check your configurations with \u2018git config –list\u2019<\/em> to guarantee that the correct settings are applied. <\/p>\n\n\n\n Use the \u2018ssh-keygen -l -f ~\/.ssh\/descriptive_key_name.pub\u2019<\/em> command in order to verify if your public key has been correctly generated and added. <\/p>\n\n\n\n As an option, you can use GitHub CLI for multiple account management. You need to download and install GitHub CLI on your device. Once that is done, you can set up and switch between multiple accounts in a streamlined way. Thus, you should:<\/p>\n\n\n\n One more thing – you should never forget about the security of your GitHub account. There are a lot of threats that your GitHub may face – cyber and ransomware attacks, vulnerabilities, outages, accidental deletions – you may learn about them in the State of DevOps Threats Report<\/a>. How to secure your GitHub<\/a> repository and metadata? Follow GitHub security best practices<\/u><\/a>, including shifting security left, continuous vulnerability testing and scanning, and back up your GitHub account, etc.<\/p>\n\n\n\n GitProtect.io will provide you with backup best practices<\/u><\/a>, including complete coverage of all your repos and metadata. Moreover, thanks to point-in-time restore and granular restore<\/a> features, if you are affected by ransomware, hardware failures or unauthorized access leading to data loss, the downtime will be minimal and you will be able to quickly recover data to continue your workflow. Additionally, if your organization is in one of the regulated industries such as healthcare, government or financial services, then you are most likely obligated to keep backups (usually with long or even unlimited retention<\/a>) of critical data for compliance purposes, for example for archiving.\u00a0<\/p>\n\n\n\n Well, now you can take advantage of this simplified method to manage different GitHub accounts on one machine. Use the SSH keys to set up your multiple accounts, customize your configs and as a result, save yourself time and guarantee that you will not have to scratch your head to remember your hostnames every time you clone a repo. We advise you to complement your workflow with a robust backup solution to secure your GitHub environments, repos, accounts, and metadata for complete security!<\/p>\n\n\n\n [FREE TRIAL] Ensure compliant DevOps backup and recovery with a 14-day trial<\/strong><\/a>\u00a0\ud83d\ude80<\/strong> Are you in between personal and work projects or maybe just managing multiple professional accounts from a single machine? Then, this article is here to help you simplify your Git configuration and management processes.<\/p>\n","protected":false},"author":12,"featured_media":5755,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-5754","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-github","post--single"],"yoast_head":"\nTypes of GitHub accounts <\/h2>\n\n\n\n
User accounts<\/h3>\n\n\n\n
\n
Organization accounts <\/h3>\n\n\n\n
Enterprise accounts <\/h3>\n\n\n\n
Authentication methods for GitHub accounts <\/h2>\n\n\n\n
\n
A few words about HTTPS <\/h3>\n\n\n\n
Prioritize SSH for security and simplicity <\/h3>\n\n\n\n
Set up multiple GitHub accounts with SSH for easier management<\/h2>\n\n\n\n
#1 Generating your SSH key<\/h3>\n\n\n\n
\n
\n
\n
#2 Securing your key with a passphrase <\/h3>\n\n\n\n
#3 Saving keys with ssh-agent <\/h3>\n\n\n\n
ssh-add -K ~\/.ssh\/descriptive_key_name\u2019\u00a0<\/em><\/p>\n\n\n\n#4 Craft your SSH config<\/h3>\n\n\n\n
AddKeysToAgent yes<\/em>
UseKeychain yes<\/em>
IdentityFile ~\/.ssh\/<created_key>\u00a0<\/em><\/p>\n\n\n\n#5 Distributing your public key <\/h3>\n\n\n\n
\n
#6 Organizing your workspace <\/h3>\n\n\n\n
\u00a0\u00a0\u00a0\u00a0|__.gitconfig<\/em>
\u00a0\u00a0\u00a0\u00a0|__work\/<\/em>
\u00a0\u00a0\u00a0\u00a0|__personal\/<\/em><\/p>\n\n\n\n
\u00a0\u00a0\u00a0\u00a0|__.gitconfig<\/em>
\u00a0\u00a0\u00a0\u00a0|__work\/<\/em>
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0|__.gitconfig.work<\/em>
\u00a0\u00a0\u00a0\u00a0|__personal\/<\/em>
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0|__.gitconfig.pers\u00a0<\/em><\/p>\n\n\n\n#7 Customizing your Git configs <\/h3>\n\n\n\n
\n
[user]<\/em>
email = work_email@google.com<\/em>
name = Your Name<\/em>
[github]<\/em>
user = “work_name”<\/em>
[core]<\/em>
sshCommand = “ssh -i ~\/.ssh\/<professional_key>”<\/em><\/p>\n\n\n\n\n
[user]<\/em>
email = personal_email@example.com<\/em>
name = Your Name<\/em>
[github]<\/em>
user = “myusername”<\/em>
[core]<\/em>
sshCommand = “ssh -i ~\/.ssh\/<personal_key>”<\/em><\/p>\n\n\n\n#8 Implementing global configurations <\/h3>\n\n\n\n
[includeIf “gitdir:~\/personal\/”] # include for all .git projects under personnal\/\u00a0<\/em>
path = ~\/personal\/.gitconfig-pers<\/em>
[includeIf “gitdir:~\/work\/”]<\/em>
path = ~\/work\/.gitconfig-work\u00a0<\/em>
[core]<\/em>
excludesfile = ~\/.gitignore\u00a0 \u00a0 \u00a0 # valid everywhere\u00a0<\/em><\/p>\n\n\n\nAdditional tips<\/h3>\n\n\n\n
What about multiple GitHub account management using CLI<\/h2>\n\n\n\n
\n
Secure your GitHub accounts with automated backups <\/h2>\n\n\n\n
Summary <\/h2>\n\n\n\n
[CUSTOM DEMO] Let\u2019s talk about how backup & DR software for DevOps can help you mitigate the risks<\/strong><\/a><\/p>\n","protected":false},"excerpt":{"rendered":"