MSYS2-packages: SSH failing to find config and identities in user home
Description / Steps to reproduce the issue
SSH is unable to load identities and config stored in the usual ~/.ssh
directory at all for me. Changing ~/.ssh/config
is making no difference even when not using tokens in the path and instead using the system username. When running ssh-keygen
it expands the default directory to //.ssh/
, and for a few other commands it’s pointing up to /.ssh/
where I can confirm the expected modifications to e.g. known_hosts
are happening. Some stat
calls into looking around, it seems to be caused by some update after 2022-09-05 (creation and modification dates listed for stat ~/.ssh/known_hosts{,.old}
) and it took me until now to notice because I’m only now setting up a new host for which I needed new keys (the others are local network hosts that take password auth)
Expected behavior
the SSH family of tools working from ~/.ssh/
Actual behavior
the same tools modifying files in the msys root directory.
Running ssh -G .
to dump the config lists one notable entry - ~
is being considered an escape char. I wonder if that causes issues…
Considering it’s checking the wrong directory, these are the defaults for the current package version.
ssh_-G.log
Verification
- I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)
Windows Version
MSYS_NT-10.0-19045
Are you willing to submit a PR?
If I can figure out why things break, sure
About this issue
- Original URL
- State: closed
- Created 2 months ago
- Comments: 16 (3 by maintainers)
I don’t know if it’s breaking for push and pull ops actually - I’m facing this problem trying to SSH into a machine on the network. Using keys that I know are valid, and they work when I add
-i /home/riven/.ssh/id_ed25519
. I’ll try and see if git over SSH works on my end.I’m certain I’m not using the Windows ssh distribution as I can reproduce this without inherited paths, with
which ssh
returning/usr/bin/ssh
.I can confirm that a quick
cp ~/.ssh/id_* /.ssh/ && ssh user@host
indeed makes it cease the credentials request so it’s definitely picking up the keys from there.