Summary
For a self-hosted Git server, SSH_and_GPG/create_ssh_key.sh writes an SSH config
block whose Host line contains only the alias, while HostName holds the real
server hostname. As a result, any git remote that is cloned/configured with the
real hostname (rather than the alias) never matches the block, so the block's
IdentityFile is not applied. SSH then falls back to whatever default keys the
agent offers, and authentication fails with Permission denied (publickey) even
though the correct key exists on disk and is enrolled on the server.
Root cause
SSH_and_GPG/create_ssh_key.sh, self-hosted branch (around lines 159–168):
if [[ -n "$IS_SELF_HOSTED" ]]; then
{
echo ""
echo "Host $GIT_HOST" # <-- alias only
echo " HostName $GIT_HOSTNAME" # <-- real hostname lives here
...
echo " IdentityFile $KEY_PATH"
} >> "$CFG_PATH"
SSH matches config blocks against the connection target. Git remotes generated
against a self-hosted server typically use the real hostname in the URL
(ssh://git@<real-host>/...), not the alias. Since the Host line lists only the
alias, that connection doesn't match, the IdentityFile is skipped, and the wrong
key is offered.
Impact
git fetch/push/clone and git submodule update against the self-hosted
server fail with Permission denied (publickey).
- It looks like a key or server problem, but the key is fine — only the config
match is wrong. Connecting via the alias (ssh <alias>) succeeds while connecting
via the real hostname fails, which is the tell.
Reproduction (sanitized)
- Run the script, choose "Self-Hosted Git Server", give an alias and a distinct
real hostname.
- Add a remote using the real hostname:
git remote add origin ssh://git@<real-host>/<owner>/<repo>.git
ssh -T <alias> → authenticates.
ssh -T git@<real-host> → Permission denied (publickey).
Suggested fix
Include both the alias and the real hostname on the Host line so either target
matches the block:
echo "Host $GIT_HOST $GIT_HOSTNAME"
(When alias and hostname are equal, de-dupe so the token isn't repeated.)
Secondary note
Unlike add_remote_host.sh, the self-hosted block in create_ssh_key.sh omits
IdentitiesOnly yes. Adding it would keep the agent from offering unrelated keys
first and makes the intended key deterministic. Worth aligning the two scripts.
Summary
For a self-hosted Git server,
SSH_and_GPG/create_ssh_key.shwrites an SSH configblock whose
Hostline contains only the alias, whileHostNameholds the realserver hostname. As a result, any git remote that is cloned/configured with the
real hostname (rather than the alias) never matches the block, so the block's
IdentityFileis not applied. SSH then falls back to whatever default keys theagent offers, and authentication fails with
Permission denied (publickey)eventhough the correct key exists on disk and is enrolled on the server.
Root cause
SSH_and_GPG/create_ssh_key.sh, self-hosted branch (around lines 159–168):SSH matches config blocks against the connection target. Git remotes generated
against a self-hosted server typically use the real hostname in the URL
(
ssh://git@<real-host>/...), not the alias. Since theHostline lists only thealias, that connection doesn't match, the
IdentityFileis skipped, and the wrongkey is offered.
Impact
git fetch/push/cloneandgit submodule updateagainst the self-hostedserver fail with
Permission denied (publickey).match is wrong. Connecting via the alias (
ssh <alias>) succeeds while connectingvia the real hostname fails, which is the tell.
Reproduction (sanitized)
real hostname.
git remote add origin ssh://git@<real-host>/<owner>/<repo>.gitssh -T <alias>→ authenticates.ssh -T git@<real-host>→Permission denied (publickey).Suggested fix
Include both the alias and the real hostname on the
Hostline so either targetmatches the block:
(When alias and hostname are equal, de-dupe so the token isn't repeated.)
Secondary note
Unlike
add_remote_host.sh, the self-hosted block increate_ssh_key.shomitsIdentitiesOnly yes. Adding it would keep the agent from offering unrelated keysfirst and makes the intended key deterministic. Worth aligning the two scripts.