Could not read from remote repository

[gitNetw0rk]

I am experiencing a recurring issue Could not read from remote repository after rotating machine ssh key.

mise dot origin set <target-repo> --sync sync
mise bootstrap services apply

solves the problem, temporarily only.

I seems that mise false back to old ssh key and the later autosync does not run again, as it does not have permissions to the remote repo.

[jdx]

Thanks for the report. My guess is that the autosync watcher runs as a systemd/launchd user service, and that service doesn't pick up your shell's SSH_AUTH_SOCK. mise doesn't forward it either. After you rotate the key, the old agent socket or key goes away and the service keeps using what it saw when it started. mise bootstrap services apply restarts the service with a fresh environment, which would explain why it only works temporarily. I haven't reproduced this, so it's a hypothesis.

Could you tell us:

• your OS, and whether the watcher is a systemd or launchd service
• whether the new key is passphrase-protected and loaded into an agent, or a plain key file
• what ssh -T git@<host> prints from your shell
• what mise dot status and mise doctor show once it has stopped syncing

If that matches, the fix is probably some mix of documenting how to give the service a stable agent socket, and having mise dot status say clearly that sync is stuck on an auth failure instead of silently stopping.

AI-assisted — Tool: Claude Code; model: anthropic/claude-sonnet-5-5; version: 2.1.317.

[gitNetw0rk]

Thank @jdx for help with troubleshooting!

• Fedora Linux 43 (Workstation Edition)
• new SSH key is paraphrase-protected and loaded into an agent
• ssh -T git@gitlab.com reports: Welcome to GitLab ..
• mise dot status as well as doctor report: dotfiles syncing with the setup repository keeps failing (fetching git@: git@gitlab.com: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.; 2 attempt(s)). ...

So, yes, there is some misconfiguration on my side since ssh key rotation.
any ideas how to approach it?

[shoka-jp]

@gitNetw0rk On Fedora, I would test jdx's agent-socket hypothesis directly. A systemd user service inherits the user manager's environment, not the environment of your current terminal. Updating that environment also requires restarting an already-running watcher.

First identify your watcher unit:

mise bootstrap services status
systemctl --user list-units --all 'dev.mise.*.service'

Then, in the same terminal where SSH authentication works:

# Replace this documentation-example name with your actual history-watch unit.
watch_unit='dev.mise.mise-history.service'

printf 'shell SSH_AUTH_SOCK: %s\n' "${SSH_AUTH_SOCK:-<unset>}"
systemctl --user show-environment | sed -n '/^SSH_AUTH_SOCK=/p'
ssh-add -l

If the current socket exists and ssh-add -l lists the new key, import just that variable and restart the watcher:

if test -S "${SSH_AUTH_SOCK:-}"; then
  systemctl --user import-environment SSH_AUTH_SOCK &&
    systemctl --user restart "$watch_unit"
fi
mise dot status

There is one precedence caveat: an explicit SSH_AUTH_SOCK in the unit's Environment= or an EnvironmentFile= overrides the manager value. Inspect systemctl --user cat "$watch_unit" locally for that; don't paste any unrelated credentials. If mise generated a stale value, correct the original service configuration.

This is a recovery/check for the current session. If it works but fails after the next login or agent restart, the durable fix is to arrange agent/session startup to import the current socket before starting the watcher, or use a stable socket actually provided by your agent. Hard-coding a temporary socket path would reproduce the problem.

References: systemd environment inheritance and precedence, import-environment, mise user services. I checked the docs and current mise source; I have not reproduced this on Fedora 43.

AI-assisted — Tool: ChatGPT (Codex); model: openai/unavailable; version: unavailable.

[gitNetw0rk]

thanks @shoka-jp for the tips!

.. meanwhile I have simply dnf remove mise , dnf install mise and mise bootstrap and the issue got solved!

For records, here is what I forget to mention. I did not only rotate ssh key, but also added suffix to my id_ed25519 file, technically changing the filename/path and then set it on gitlab.com side. However, I did not remove the old one file, nor removed it from ssh agent yet (compatibility period). This is when my mise dotfiles sync issue started.

A thought to consider: would it be helpful to track changes in ssh key files? Also note that mise docker does not report initialized ssh keys/files paths. Perhaps it could detect changes like I made and report clearly with hints to debug.