In real-world development scenarios, multiple Git accounts may need to be switched. For example, a company might use a GitLab enterprise account to develop internal projects, while personal projects are hosted on GitHub, and open-source projects might be participated in on Gitee. Using the same SSH key across all platforms, while simple, can lead to permission confusion and security issues. Configuring independent SSH public keys for different platforms allows for clear identity isolation and security control. The core principle of this method is to leverage the configuration capabilities of the SSH protocol, allowing the Git client to automatically select the corresponding private key for authentication based on the remote repository address being accessed. The entire process eliminates the need for frequent password entry and maintains the independence of each account environment.

Before starting the configuration, it's necessary to clarify the current state. Open a terminal and navigate to the user's SSH configuration directory, usually located at ~/.ssh. View existing key files using the command:

ls -al ~/.ssh

If you see files like `id_rsa` and `id_ed25519`, it means keys have already been generated. If configuring from scratch, this directory might be empty. The first step is to generate independent key pairs for each Git service that needs to be differentiated. A key pair consists of a public key and a private key. The public key can be publicly uploaded to the Git service platform, while the private key must be strictly kept confidential and stored locally. Generate a new key using the `ssh-keygen` command, specifying the key file name via the `-f` parameter to avoid overwriting the default key.

The command to generate a dedicated key for GitHub is as follows:

ssh-keygen -t ed25519 -C "your_email@example.com" -f ~/.ssh/id_ed25519_github

Here, `-t` specifies the key algorithm; ed25519 is more secure and faster than the traditional RSA. `-C` adds comments, usually identified by an email address. `-f` specifies the generated filename. After executing the command, you will be prompted to enter a key password, which can add an extra layer of protection to the key. Pressing Enter directly will not set a password. After successful generation, two files will appear in the `~/.ssh` directory: `id_ed25519_github` and `id_ed25519_github.pub`. The former is the private key, and the latter is the public key. Generate a key for your company's GitLab account using the same method, for example, naming it id_ed25519_company.

Generating the key is just the preparatory work; actual multi-account management relies on the SSH client's configuration file. Create or modify a config file in the ~/.ssh directory. This file tells the SSH client which private key to use when accessing different hosts. The configuration file uses a simple syntax structure, with each account configuration starting with a Host section followed by the corresponding configuration directives. Here's a typical configuration example:

# Personal GitHub Account

Host github.com

HostName github.com

User git

IdentityFile ~/.ssh/id_ed25519_github

IdentitiesOnly yes

# Company GitLab

Host gitlab.company.com

HostName gitlab.internal.com

User git

IdentityFile ~/.ssh/id_ed25519_company

Port 2222

IdentitiesOnly yes

# Alternate Gitee Account

Host gitee.com

HostName gitee.com

User git

IdentityFile ~/.ssh/id_ed25519_gitee

IdentitiesOnly yes

In this configuration, each Host defines an alias, which will be used for the remote address of the Git repository. The `IdentitiesOnly yes` directive ensures that SSH only uses the specified private key and will not attempt other keys. The `Port` directive allows you to specify a non-standard SSH port if needed. After configuration, you need to add each public key to the corresponding Git platform. Use the `cat` command to view the public key content and copy the complete output.

Adding to GitHub is as follows: Log in to GitHub, click your avatar, select Settings, find the SSH and GPG keys page, click New SSH key, paste the public key content, and name it. The operation is similar on other platforms; add it in the SSH key management section of your account settings. After adding, you need to test the connection. The test command uses `ssh -T` followed by the Host alias defined in the configuration, instead of directly using the domain name.

Test GitHub connection:

ssh -T github.com

On the first connection, you will be prompted to confirm the host key fingerprint; enter `yes` to continue. If you see the message "Hi username! You've successfully authenticated," the configuration is successful. Test other platforms using the same method. During verification, it is crucial to note that the SSH client matches the configuration based on the Host alias in the config file; therefore, the address in the test command must exactly match the Host field in the config file. In practical use, cloning and manipulating repositories requires special attention to the format of the remote address. The standard cloning command is `git clone git@github.com:username/repo.git`, which uses the default SSH configuration. With a multi-account configuration, if a specific key is configured for github.com in the config file, using this address will automatically match the configuration. However, for different accounts on the same platform, such as two different GitHub accounts, further processing is needed. One approach is to use different Host aliases in the config file pointing to the same platform, but using different keys.

Assuming you have two GitHub accounts, one personal and one work, you can configure them like this:

# Personal GitHub

Host github.com-personal

HostName github.com

User git

IdentityFile ~/.ssh/id_ed25519_github_personal

# Work GitHub

Host github.com-work

HostName github.com

User git

IdentityFile ~/.ssh/id_ed25519_github_work

When using this configuration, the clone repository address needs to be adjusted accordingly. The original `git@github.com:username/repo.git` needs to be changed to `git@github.com-personal:username/repo.git` or `git@github.com-work:username/repo.git`. While this increases address complexity, it achieves complete isolation between multiple accounts on the same platform. For convenience, you can directly use the configured alias address when adding remote repositories.

If a password is set for the key, having to enter it every time you use it can be cumbersome. You can add your private key to ssh-agent for management, allowing it to remember the decrypted key for a certain period.

The process for using ssh-agent is as follows: First, start ssh-agent with `eval "$(ssh-agent -s)"`; then add your private key with `ssh-add ~/.ssh/id_ed25519_github`. Multiple keys can be added; `ssh-add -l` lists the loaded keys. To avoid the hassle of re-adding keys every time you open a terminal, you can add these commands to your shell's startup configuration file, such as `.bashrc` or `.zshrc`. However, be aware of security risks, especially on shared computers. A more refined approach is to configure the `AddKeysToAgent` option in the config file for each host, allowing SSH to automatically add keys to the agent when needed.

After configuring multiple accounts, how do you verify which account is currently being used? Git configuration is divided into system-level, global-level, and project-level. The `git config --list` command can be used to view the currently active configurations. Global configurations are in `~/.gitconfig`, and project-level configurations are in `.git/config` in the project directory. In multi-account scenarios, it's recommended to avoid setting a global username and email address. Instead, configure them individually for each project to ensure accurate author information in commit history. You can set project-specific configurations by executing `git config user.name "Your Name"` and `git config user.email "your_email@example.com"` in the project directory. For easier management, you can prepare different configuration templates or use conditional configurations to automatically switch user information based on the repository's remote address.

There are some Git-related settings to be aware of. The `core.sshCommand` option specifies the SSH command used for Git operations, providing a way to override default behavior in special cases. For example, `git -c core.sshCommand="ssh -i ~/.ssh/custom_key" clone...` allows you to directly specify the key in the command. `credential.helper` configures the credential storage method, reducing repetitive input. In a multi-account environment, ensuring that credential storage doesn't confuse passwords for different accounts is also crucial.

When collaborating with teams or migrating projects, it may be necessary to update the remote addresses of repositories in batches. If you were previously using the platform's default address and now want to change it to an alias address in your multi-account configuration, you can use the command `git remote set-url`. For a large number of repositories, you can write a simple script to automate this process. Similarly, proper handling of keys is crucial when leaving a project or changing machines. Unused private keys should be removed from the ssh-agent and securely deleted, and their corresponding public keys should also be removed from your Git platform account—this is best practice for security.

Managing multiple Git accounts via SSH public keys essentially involves finding a balance between flexibility and security. Clear configuration not only makes daily work smoother but also reduces the risk of accidental errors. As the number of configurations increases, thorough documentation is essential, especially in team collaborations; a unified configuration standard can significantly reduce communication costs.