SSH连接远程服务器后Git Clone遇权限拒绝问题求助

Let’s walk through this step by step—SSH permission denied errors with GitLab usually boil down to a handful of common misconfigurations, even when you think you’ve checked all the boxes. Here’s how to narrow it down:

1. Verify SSH Key & Directory Permissions #

SSH is extremely strict about file permissions—even a slightly over-permissive key or directory will block authentication. Run these commands on your remote server to check:

# Check .ssh directory permissions
ls -ld ~/.ssh

# Check private/public key permissions
ls -l ~/.ssh/id_rsa ~/.ssh/id_rsa.pub

You should see:

• .ssh directory: drwx------ (700)
• Private key (id_rsa): -rw------- (600)
• Public key (id_rsa.pub): -rw-r--r-- (644)

If permissions are wrong, fix them with:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub

2. Test Direct SSH Connection to GitLab #

Skip Git entirely and test if your server can authenticate with GitLab directly. Run this command (replace gitlab.com with your self-hosted GitLab domain if applicable):

ssh -T git@gitlab.com

A successful authentication will return something like:

Welcome to GitLab, @your_username!

If you still get "Permission denied", this confirms the issue is with SSH authentication, not Git itself.

3. Double-Check Your GitLab Public Key #

Head to your GitLab profile > SSH Keys and verify:

• The public key matches exactly what’s on your server (run cat ~/.ssh/id_rsa.pub and compare line-for-line—no extra spaces, line breaks, or typos allowed).
• The key hasn’t expired (GitLab lets you set expiration dates; make sure yours is still valid).
• The key is associated with your account, not a group or project (unless you’re using a deploy key, which has separate permissions).

4. Ensure You’re Using the SSH Clone URL #

It’s easy to accidentally use the HTTPS URL instead of SSH. Confirm your clone command uses the SSH format:

# Correct SSH format
git clone git@gitlab.com:your_username/your_repo.git

# Wrong HTTPS format (will prompt for password, even with SSH keys)
git clone https://gitlab.com/your_username/your_repo.git

If you already cloned with HTTPS, update the remote URL:

git remote set-url origin git@gitlab.com:your_username/your_repo.git

5. Handle Multiple SSH Keys (If Applicable) #

If your server has multiple SSH keys (e.g., one for GitLab, one for GitHub), SSH might be trying the wrong key. Create or edit ~/.ssh/config to force GitLab to use your specific key:

Host gitlab.com
  Hostname gitlab.com
  User git
  IdentityFile ~/.ssh/your_gitlab_private_key
  IdentitiesOnly yes

The IdentitiesOnly yes line ensures SSH only uses the key you specify, ignoring other keys in your agent.

6. Check SSH Agent Status #

If you’re using an SSH agent to manage keys, make sure your key is added to the agent:

# List keys in agent
ssh-add -l

# If your key isn't listed, add it
ssh-add ~/.ssh/id_rsa

# If the agent isn't running, start it first
eval "$(ssh-agent -s)"

7. Debug with Verbose SSH Logs #

If none of the above works, run a verbose SSH connection to GitLab to see exactly where authentication fails:

ssh -vT git@gitlab.com

Look for lines like debug1: Offering public key: to confirm your key is being sent, and debug1: Server accepts key: to see if GitLab acknowledges it. Any error messages here will point you directly to the problem.

Final Checks #

If all else fails:

• Confirm you have clone permissions for the GitLab project (check project settings > Members).
• If you’re using a self-hosted GitLab instance, ensure the server allows outgoing SSH connections to GitLab’s port 22.
• Verify no firewall or security group on your remote server is blocking SSH traffic to GitLab.

内容的提问来源于stack exchange，提问作者R Lopez