122 lines
5.8 KiB
Markdown
122 lines
5.8 KiB
Markdown
---
|
|
title: JetBrains IDE Prompting for the Git User's Password When Cloning over SSH
|
|
tags:
|
|
- jetbrains
|
|
- git
|
|
- ssh
|
|
- windows
|
|
author:
|
|
name: Zihlu Wang
|
|
email: real@zihluwang.me
|
|
---
|
|
|
|
When you develop on Windows with a JetBrains IDE — IntelliJ IDEA, PyCharm, WebStorm, GoLand and friends — and your local Windows username contains non-ASCII characters such as Chinese, cloning a repository over SSH can behave rather oddly:
|
|
|
|
> The remote is configured as an SSH URL, yet you are repeatedly prompted for the Git user's password.
|
|
|
|
Take a repository address such as:
|
|
|
|
```text
|
|
git@git.example.com:project/demo.git
|
|
```
|
|
|
|
Normally Git authenticates over SSH with a key pair and should never ask for the Git user's own login password.
|
|
|
|
The problem may be invisible in command-line Git, but it can surface in a JetBrains IDE when you clone, pull or push.
|
|
|
|
## Symptoms
|
|
|
|
Suppose the Windows username is:
|
|
|
|
```text
|
|
张三
|
|
```
|
|
|
|
Its home directory will be:
|
|
|
|
```text
|
|
C:\Users\张三
|
|
```
|
|
|
|
In the IDE, choose:
|
|
|
|
```text
|
|
Git → Clone → Repository URL
|
|
```
|
|
|
|
and enter:
|
|
|
|
```text
|
|
git@git.example.com:project/demo.git
|
|
```
|
|
|
|
After you click Clone, you may see something like:
|
|
|
|
```text
|
|
git@git.example.com's password:
|
|
```
|
|
|
|
or the IDE may pop up a password dialog asking for the Git user's password. Even entering the correct password may fail to complete the clone.
|
|
|
|
## Why does an SSH URL ask for a password?
|
|
|
|
To make sense of this, you first need to understand how SSH falls back between authentication methods.
|
|
|
|
SSH tries authentication methods in order:
|
|
|
|
1. **Public key authentication** — the client presents a local private key, and the server checks whether the matching public key appears in `~/.ssh/authorized_keys` (on a Git server, among the SSH keys you have uploaded);
|
|
2. **Password / keyboard-interactive authentication** — if public key authentication does not succeed, the server carries on and asks for a password.
|
|
|
|
So when `git@git.example.com's password:` appears in the IDE, **the problem is not that SSH was bypassed — it is that public key authentication failed**: the SSH client could not produce the right private key, so the server fell back to password authentication and is now asking for the password of the `git` account on the server — the `git` account, note, not your own. And because mainstream Git servers (GitLab, Gitea and the like) disable password login for `git` by default, supplying the correct password still gets you nowhere.
|
|
|
|
The root of the problem is that **the client cannot find the private key**.
|
|
|
|
On Windows with a Chinese username, this is usually down to path encoding. By default the private key lives at:
|
|
|
|
```text
|
|
C:\Users\张三\.ssh\id_rsa
|
|
```
|
|
|
|
The SSH client — whether it is the OpenSSH bundled with Git for Windows or the SSH implementation built into the JetBrains IDE — locates this directory through the `%USERPROFILE%` or `HOME` environment variable. When the username contains non-ASCII characters, that path is liable to be mangled as it crosses process boundaries (shuttled back and forth between UTF-8, GBK and ANSI), so the `~/.ssh` path the client resolves no longer matches the real one — neither `config` nor the private key can be read, and password authentication is all that is left.
|
|
|
|
A handy way to tell: **run `ssh -T git@git.example.com` in a terminal and it greets you normally, yet the IDE still demands a password when cloning.** That tells you the key itself is fine, and the fault lies purely in the IDE's path resolution.
|
|
|
|
## How to confirm
|
|
|
|
1. Check that the remote really is an SSH URL (`git@host:path` or `ssh://git@host/path`) and not an HTTP one.
|
|
2. Run `ssh -T git@git.example.com` in a terminal:
|
|
- Everything works → the key and the server configuration are fine, and the problem lies with the IDE;
|
|
- It fails too → work through the usual suspects first: the private key file, `~/.ssh/config`, and whether the public key has been uploaded to the server.
|
|
3. In the IDE, check which SSH implementation Git is using: `Settings → Version Control → Git → SSH executable`.
|
|
4. Check that `C:\Users\张三\.ssh` really exists, and that whatever is in `config` is being read.
|
|
|
|
## Temporary workarounds
|
|
|
|
Before you rearrange your username, try one of the following to sidestep the non-ASCII path.
|
|
|
|
### Option 1: use the ssh.exe bundled with Git
|
|
|
|
A JetBrains IDE may default to its own built-in SSH implementation. Change `Settings → Version Control → Git → SSH executable` to `Native`, which makes it use the `ssh.exe` shipped with Git for Windows, then retry the clone. The two implementations resolve paths differently, and switching is often enough to sidestep the issue entirely.
|
|
|
|
### Option 2: move the keys to a pure-ASCII path and point at them explicitly
|
|
|
|
Copy the key directory from `C:\Users\张三\.ssh` to `C:\ssh`, then tell Git explicitly which private key and known_hosts file to use:
|
|
|
|
```shell
|
|
git config --global core.sshCommand "ssh -i C:/ssh/id_rsa -o UserKnownHostsFile=C:/ssh/known_hosts"
|
|
```
|
|
|
|
Once configured, command-line Git — and any IDE that shells out to the system Git — will use this command, and nothing depends on guessing `~/.ssh` any more.
|
|
|
|
### Option 3: give the IDE its own HOME
|
|
|
|
Create a pure-ASCII home directory (say `C:\ssh-home`), place your keys in `C:\ssh-home\.ssh\`, and set the following in the environment the IDE runs with:
|
|
|
|
```text
|
|
HOME=C:\ssh-home
|
|
```
|
|
|
|
SSH will then look for its configuration and private keys under `C:\ssh-home\.ssh\`, avoiding the Chinese path altogether.
|
|
|
|
> All three options relieve the symptom, but they are patches, not cures. As long as the username remains Chinese, other tools — Node, Python, Docker and any number of CLI utilities — can still trip over exactly the same problem. **The proper fix is to change the Windows username to English**, and the steps are in [Renaming a Windows User Account and Profile Folder to English](./rename-windows-user-profile-to-english.mdx).
|