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

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)

Most upvoted comments

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.